As proposed in JENKINS-47498, this repository implements a Maven BOM which can be used in a plugin POM to more easily manage dependencies on other common plugins. This is important because version management is a common annoyance.
After selecting your plugin’s LTS baseline:
<jenkins.version>2.138.4</jenkins.version>
just import the latest BOM from that line:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>io.jenkins.tools.bom</groupId>
<artifactId>bom</artifactId>
<version>2.138.1</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
(The patch component of the BOM version is unrelated to the patch component of the Jenkins LTS version. The major and minor components should match.)
Now you can declare dependencies on many plugins without needing to specify a version:
<dependency>
<groupId>org.jenkins-ci.plugins.workflow</groupId>
<artifactId>workflow-cps</artifactId>
<scope>test</scope>
</dependency>
You can always override a version managed by the BOM if you wish, but if you find the need to use a newer version, first try just updating the version in the BOM and cutting a new release of it.
For people potentially working on the BOM itself, not just consuming it.
You can try just incrementing plugin versions in bom/pom.xml
.
If CI passes, great!
Dependabot will try doing this as well.
Insert a new dependency
in sorted order to bom/pom.xml
.
Make sure it is used (perhaps transitively) in sample-plugin/pom.xml
.
Ideally also update the sample plugin’s tests to actually exercise it,
as a sanity check.
You can also add a <classifier>tests</classifier>
entry,
for a plugin which specifies <no-test-jar>false</no-test-jar>
.
You should introduce a POM property so that the version is not repeated.
The build will enforce that all transitive plugin dependencies are also managed.
The CI build tries running the Plugin Compatibility Tester (PCT)
on the particular combination of plugins being managed by the BOM.
This catches mutual incompatibilities between plugins
(as revealed by their JenkinsRule
tests)
and the specified Jenkins LTS version.
If there is a PCT failure, fix it in the plugin with the failing test, and when that fix is released, try updating the BOM again.
TODO could use a script to run the full build locally with just a single plugin and a single test.
The master
branch should track the current LTS line.
A few historical lines are also tracked by branches,
for use from plugins which are not yet ready to depend on the latest.
The CI build (or just mvn test
) will fail if some managed plugins are too new for the LTS line.
This script
is a handy way to find the most recently released plugin version compatible with a given line,
according to the jenkins-infra/update-center2
(which currently maintains releases for the past five lines).
Commits from master
should be merged into the next older LTS branch,
and from there into the branch one older, and so on.
This ensures that CI-related changes propagate to all branches without manual copy-and-paste.
Merge conflicts should be resolved in favor of the HEAD
,
so that the branches differ from master
only in POMs (and perhaps in sample plugin code).