The plugin bill of materials rotates release lead responsibilities between different volunteers as listed in BOM release leads. Release leads serve for two weeks, then the release lead assignment is rotated to another person. Release leads resolve dependency update failures during their release lead assignment. Details are described in a week in the life of a BOM release manager with some additional information in the plugin compatibility tester (PCT) section of the contributing guide.
| Release Date | Lead |
|---|---|
| 2026-04-24 | Mark Waite |
| 2026-05-01 | Mark Waite |
| 2026-05-08 | Adrien Lecharpentier |
| 2026-05-15 | Adrien Lecharpentier |
| 2026-05-22 | Kris Stern |
| 2026-05-29 | Kris Stern |
| 2026-06-05 | Darin Pope |
| 2026-06-12 | Darin Pope |
You can cut a release using JEP-229.
To save resources, master is built only on demand, so use Re-run checks in https://github.com/jenkinsci/bom/commits/master if you wish to start.
If that build passes, a release should be published automatically when PRs matching certain label patterns are merged.
For the common case that only lots of dependencies PRs have been merged,
the release can be triggered manually from the Actions tab after a master build has succeeded.
If a master build succeeds but does not notify GitHub of the success, the release process will not run.
In one case where that happened, we were able to replay the Pipeline on the master branch to show the failing test was passing.
The Pipeline replay was:
publishChecks(name: 'pct-git-plugin-weekly')
echo 'OK'
This repository is integrated with “Incrementals” JEP-305:
- Individual BOM builds, including from pull requests, are deployed and may be imported on an experimental basis by plugins.
(The plugin’s POM must use the
gitHubRepoproperty as shown in workflow-step-api-plugin #58.) - Pull requests to the BOM may specify incremental versions of plugins, including unmerged PRs. (These should be resolved to formal release versions before the PR is merged.)
Together these behaviors should make it easier to verify compatibility of code changes still under review.
This repository uses Renovate to be notified automatically of available updates, mainly to plugins. (It is not currently possible for Jenkins core updates to be tracked this way.)
Release Drafter is also used to prepare changelogs for the releases page.
A BOM release manager is in charge of BOM releases for 2 weeks.
As a BOM release manager, you'll be working directly with the jenkinsci/bom repository. Said differently, think hard before using your fork of the bom repository.
This will probably be the majority of work you'll do.
In a perfect world, a Renovate PR will just auto-merge into master and you won't have to do anything.
In a not so perfect world, a Renovate PR will fail to build. Most of the time, it's because a plugin is too new for older LTS lines. The way you'll resolve this issue is to pin the older version to the correct LTS line.
Tip
When resolving an issue with a PR, assign the PR to yourself so others can see that you are actively looking at the PR.
The easiest way to work on the PR is to use the gh CLI to checkout the PR:
gh pr checkout <PR id>
Then you can work on the PR. Once done, push your changes back to the PR. If everything is successful, the PR will auto-merge. At this point, you can delete the local branch:
git branch -D <branchName>
There are some known issues that commonly need to be addressed by the BOM release manager.
Sometimes a dependency update that was merged and released causes compatibility issues or test failures that are discovered before the BOM release. When this happens, a rollback process is needed to temporarily revert the problematic change while the issue is investigated and resolved.
A dependency update should be reverted when it results in persistent test failures in the plugin BOM. It is even better if the persistent test failure can be fixed by updating to a newer version of the dependency that fixes the test failure.
When a problematic dependency update needs to be rolled back, follow these steps:
- Notify the Author
Notify the author of the problematic change as close as possible to the actual problem area. Leave a comment on the original PR or commit that introduced the issue, explaining the specific problems encountered.
Where possible, provide an example that the plugin developer can use to see the problem from within the plugin repository. Most plugin developers are not familiar with maintaining the plugin BOM, so they will struggle with using the plugin BOM repository to duplicate the problem. A plugin developer is more likely to resolve a problem when they can see it with mvn clean verify in their plugin repository.
Example:
Looks like these changes are causing issues with doing a BOM release
this week. For reference:
tl;dr...two plugins that passed on the Tuesday weekly-test (foo-plugin
and bar-plugin) are now failing.
For the moment so I can get the BOM release out today, I'm going to
revert the PR that put in github-branch-source 1844.v4a_9883d49126.
The local BOM commands I'm running that are failing are:
- `LINE=weekly PLUGINS=bar-plugin bash local-test.sh`
- `LINE=weekly PLUGINS=foo-plugin bash local-test.sh`
As noted, when I locally go back to github-branch-source
1834.v857721ea_74c6 both tests are passing.
Reference: See this example notification to the plugin author.
- Revert the Change
Create a revert commit that rolls back the problematic dependency update. In the commit message and the pull request description, include a link to the notification that was sent to the author.
Example commit message:
Revert "chore(deps): bump github-branch-source to 1844.v4a_9883d49126 in /bom-weekly"
Rolling back due to compatibility issues with downstream plugins.
See notification to author: https://github.com/jenkinsci/github-branch-source-plugin/pull/822#issuecomment-3238052920
- Trigger Renovate
Click the If you want to rebase/retry this PR, check this boxon the reverted PR to trigger Renovate to reprocess the change.
- Disable Automerge
Disable automerge for the PR to prevent it from being automatically merged again while the issue is being investigated.
- Request Changes Review
- Click on "Files changed" tab in the PR
- Click "Review changes"
- Select "Request changes"
- Add a comment explaining why changes are requested (reference the compatibility issues)
- Click "Submit review"
- Add
weekly-testLabel
Add the weekly-test label to the PR to ensure it gets additional testing before being considered for merge again.
- Leave the PR Open
Do not close the PR. Leave it open so that:
- The issue remains visible and can be tracked
- The author can address the compatibility issues
- Testing can be re-run once fixes are implemented
- Convert to Draft
Convert the PR to draft status by clicking the "Convert to draft" link at the bottom of the Reviewers block. This signals that the PR is not ready for merge.
For a complete example of this rollback process in action, see BOM PR #5611, which demonstrates:
- Author notification with specific failure details
- Revert commit with reference to the notification
- PR converted to draft status
- Changes requested with clear explanation
weekly-testlabel applied- Automerge disabled
Once the rollback is complete:
- Monitor the Issue: Keep track of whether the author addresses the compatibility problems
- Re-test When Ready: Once fixes are implemented, the PR can be converted back from draft and re-tested
- Coordinate Release: Ensure the fixed version is properly tested before including it in the next BOM release
When performing rollbacks:
- Be clear and specific about the issues encountered
- Provide helpful details like failing tests or error messages
- Reference specific versions that work vs. versions that fail
- Be respectful and collaborative - rollbacks are about maintaining stability, not blame
This message shows that a plugin requires a newer Jenkins LTS than one or more of the LTS lines supported by the BOM. Pin the older version to the correct LTS line to resolve the issue. Some pull requests that pin older plugin versions include:
This message usually shows that an optional dependency of a plugin is not being updated by the Plugin Compatibility Tester (PCT) and that update is needed by another plugin. This is a known issue in PCT. Workarounds include:
- Add the optional dependency in test scope to the affected plugin. The workaround leaves an unnecessary test dependency in the affected plugin in order to avoid the issue
- Pin an older version of the optional plugin on older LTS lines if the issue is not visible in the weekly line. This only works if the specific issue is not visible on the weekly line.
Some pull requests that add the optional dependency in test scope include:
- Customer folder icon add test dependency on config-file-provider and issue 280
- Mark trilead API as test even if not needed, followed by remove trilead
A pull request that pins an older version of the optional plugin is:
Sometimes a plugin update introduces a test failure but the test failure does not justify a rollback of the plugin update in the BOM.
In that case, individual test failures can be ignored by adding entries to the excludes.txt file.
The excludes.txt file format is described in the Maven surefire plugin documentation.
If a test only fails on a specific line of the BOM, it can be listed in an exclusion file that is specific to the line, as in bom-2.541.x/excludes.txt.
If an exclusions file exists for a specific line of the plugin BOM it is merged with the general excludes.txt file.
When there is a manually generated PR, there's probably a pretty good chance as the BOM release manager you won't have to do anything. The person opening the PR should open the PR as draft. As a BOM release manager, feel free to look at a draft PR, but don't spend much time on it.
On the other hand, if the person reaches out for help, be sure to help them.
This section goes over the expectations and work items for the BOM release manager during their on-call cycle.
The scripts that are referenced are in the release-manager-scripts directory.
Open a terminal and cd to that directory before running the scripts.
Alternatively, you can call them from wherever you want, just know that they are located in the release-manager-scripts directory.
- run
./bom-release-issue-create.sh <yyyy-MM-dd>- Example:
./bom-release-issue-create.sh 2024-10-14 - use the desired date of the release, not the date when you create the ticket
- Example:
- on the newly created issue, manually set
TypetoTask- at the time of writing (2024-10-14), there is no
ghoption to set the Type
- at the time of writing (2024-10-14), there is no
- check the CRON expression to see if the pre-release build will be executed at a time suited for you
- this can also be used to change when the release happened if you prefer the release to be made on Thursday
- run
./bom-release-issue-complete-task.sh 1
- Locally run tests for
warnings-ngfor all current LINEs and weekly./bom-test-all-lines.sh warnings-ng
- run
./bom-lock-master.shbefore the job runs- currently, the job is scheduled to run at 11:HH am UTC (actual 11:26am)
- verify that the branch is locked
- wait to verify that job started at ci.jenkins.io
- run
./bom-release-issue-job-running.sh <buildNumber>- Example:
./bom-release-issue-job-running.sh 1234
- Example:
- wait for build to make it through the
prepstage then (typically) take a 1.5-2 hr break - [LOOP] if there are any failures, fix until everything is successful
- run
./bom-run-cd-workflow.sh - wait for the release process to complete
- this takes 7-8 minutes
- manually edit the auto-generated release notes
- remove
<!-- Optional: add a release summary here --> - remove
<details> - remove
<summary>XYZ changes</summary> - remove
</details>
- remove
- run
./bom-release-issue-add-release-comment.sh - run
./bom-unlock-master.sh - verify that the branch is unlocked
- run
./bom-release-issue-close.sh
For tasks that don't have a specific script, i.e. tasks 1, 5, 6, 8 and 11, you can run ./bom-release-issue-complete-task.sh <task number> to check the box off without having to manually edit the issue.
- business as usual tasks
- run the Renovate dependency graph checks
- open Dependency Dashboard
- click the checkbox for "Check this box to trigger a request for Renovate to run again on this repository" to check for all dependency updates
- wait for the Renovate dependency graph checks to complete
- click the checkboxes for any new PRs in the Dependency Dashboard. If there were any entries, make sure they clear and merge before continuing.
- Open the pinned Dependency Dashboard issue
- Once the weekly build has completed, you will see a line that says "Update dependency org.jenkins-ci.main:jenkins-war to v2.
XYZ", whereXYZis the weekly build number. Click the checkbox next to that line to start the weekly test. - Once the box is checked, a new PR will be created by renovate named "Update dependency org.jenkins-ci.main:jenkins-war to v2.
XYZ" whereXYZis the weekly build number. This will fire off a fullweeklybuild that will take about 1 hour to complete. - If everything succeeds, the PR will auto-merge.
- Once the auto-merge completes, go back to the Dependency Dashboard issue and check the box for "Check this box to trigger a request for Renovate to run again on this repository". This will remove the "Update dependency..." line from the issue.
- business as usual tasks
As someone that is "on-call" for managing BOM, there are a few helpful aliases/scripts that you can create to make your life easier.
These aliases use git, sed and gh. If you haven't installed gh yet, do that and go ahead and login using:
gh auth login
You'll answer the questions:
- Where do you use GitHub?
- GitHub.com
- What is your preferred protocol for Git operations on this host?
- HTTPS
- Authenticate Git with your GitHub credentials?
- Y
- How would you like to authenticate GitHub CLI?
- Login with a web browser
- Copy your one time code from the command line then press
Enter - Depending on if you are already logged into GitHub with the browser that opened, you may have a few different steps. Eventually, you should get to a "Device Activation" screen. Click on the
Continuebutton beside your avatar. - Enter the code you copied from the command line and click
Continue - Now you'll be on the "Authorize GitHub CLI" screen. Click on the "Authorize github" button at the bottom of the page.
- You may be asked to confirm access in various forms. Just follow the instructions.
- Once you complete the web login, look back at your command prompt. You should see that the login process has completed.
Once you are logged in, you can use the scripts in release-manager-scripts.
This script creates the boilerplate GitHub issue for the weekly BOM release, as well as pinning the issue.
This script updates the body of the GitHub issue by checking the Trigger task item.
This script adds a comment to the GitHub issue with the latest release number.
This script unpins and closes the GitHub issue.
This script:
- locks the
masterbranch - updates the GitHub issue body by checking the
Lock branchtask item.
This script:
- unlocks the
masterbranch - updates the GitHub issue body by checking the
Unlock branchtask item.
This script returns the lock state of the master branch.
This is a helper script to test a plugin against a specific Jenkins line.
This is a helper script that calls bom-line-test.sh for all active Jenkins lines.