The plugin parent POM is decoupled from the core Jenkins project, both from a Maven perspective and a repository perspective. It provides a common build configuration for all Jenkins plugins.
Since version 5.0, the plugin parent POM requires Jenkins 2.479 or newer and JDK 17 or newer. Since version 4.52, the plugin parent POM requires Jenkins 2.361 or newer and JDK 11 or newer. Since version 4.40, the plugin parent POM supports Java 17.
To use the plugin parent POM, change the parent POM of your plugin:
<parent>
<groupId>org.jenkins-ci.plugins</groupId>
<artifactId>plugin</artifactId>
<version>VERSION</version> <!-- See https://github.com/jenkinsci/plugin-pom/releases for available versions-->
<relativePath />
</parent>
Then override the needed properties, e.g.:
<properties>
<!--
Take a look the developer documentation for the baseline version to use
https://www.jenkins.io/doc/developer/plugin-development/choosing-jenkins-baseline/#currently-recommended-versions
-->
<jenkins.version>2.361.4</jenkins.version>
</properties>
If you have a jar:test-jar
execution, delete it and add the following to <properties>
:
<no-test-jar>false</no-test-jar>
The following properties are overridable:
jenkins.version
: The Jenkins version required by the plugin. Mandatory. See Requirements for more info. Being able to specify thejenkins.version
simplifies testing the plugin with different core versions, which is important (among other reasons) for Plugin Compatibility Testing (PCT).jenkins-test-harness.version
: The JTH version used to test plugin. Uses split test-harness (see JENKINS-32478).hpi-plugin.version
: The HPI Maven Plugin version used by the plugin. (Generally you should not set this to a version lower than that specified in the plugin parent POM.)stapler-maven-plugin.version
: The Stapler Maven plugin version required by the plugin.- In order to make their versions the same as the used core version,
node.version
andnpm.version
properties are provided.
You can configure your plugin to treat every commit as a release candidate. See Incrementals for details.
To opt in to code formatting of your Java sources and Maven POM with Spotless,
define the spotless.check.skip
property to false
and remove any existing
Spotless configuration from your POM.
To format existing code, run:
mvn spotless:apply
After formatting an existing repository, squash merge the PR and create a
.git-blame-ignore-revs
file to hide the formatting commit from blame tools.
You can set up mvn spotless:apply
to run automatically (in validate
phase) for projects which enabled spotless by adding the following to your settings.xml
:
<settings>
[...]
<activeProfiles>
[...]
<activeProfile>may-spotless-apply</activeProfile>
</activeProfiles>
</settings>
To run JMH benchmarks from JUnit tests, you must run you must activate the benchmark
profile. For example:
mvn -P jmh-benchmark test
When the jmh-benchmark
profile is enabled, no tests apart from JMH benchmarks will be run.
The names of the classes containing the benchmark runners should either begin with or
end with the word Benchmark
. For example, FooBenchmark
and BenchmarkFoo
will
be detected when using -Dbenchmark
, however, FooBar
will be ignored.
See also: documentation for JMH benchmarks
Javadoc has been set to quiet by default in 2.20+, which means it will only log errors and warnings.
If you really want it verbose, set quiet
property to false
for the plugin.
Tests are skipped during the perform
phase of a release. This can be overridden by setting release.skipTests
to false.
By default, the setup wizard (Jenkins >= 2.0) is skipped when using hpi:run
. If you want the wizard to be enabled just run:
mvn -Dhudson.Main.development=false hpi:run
If you want to add npm
or yarn
to your plugin, you can do so by creating a marker file:
For npm:
touch .mvn_exec_node
For yarn:
touch .mvn_exec_yarn
You need to add corresponding properties to your pom.xml
and set them to valid values:
For npm:
<properties>
<node.version>set this to the latest node lts version</node.version>
<npm.version>set this to the latest npm version</npm.version>
</properties>
For yarn:
<properties>
<node.version>set this to the latest node lts version</node.version>
<yarn.version>set this to the latest yarn version</yarn.version>
</properties>
Our pipeline-library configures the Maven build to not fail the build when there is test failures so that Jenkins is able to report on the test failures itself.
This requires the tests to be configured to output a JUnit report in a supported location.
To do this you can install jest-junit
:
npm install --dev jest-junit
yarn add --dev jest-junit
Then configure jest-junit by modifying the package.json
:
{
"scripts": {
"mvntest": "npm test",
"test": "jest --ci --reporters=default --reporters=jest-junit"
},
"jest-junit": {
"outputDirectory": "target/surefire-reports",
"outputName": "jest-junit.xml"
}
}
Then set the following properties in your pom.xml
to configure the Maven build to let Jenkins report the results:
<properties>
<maven.test.failure.ignore>false</maven.test.failure.ignore>
<frontend.testFailureIgnore>${maven.test.failure.ignore}</frontend.testFailureIgnore>
</properties>
To configure the Maven build to report the eslint results to Jenkins you will need to setup the eslint-formatter-checkstyle
formatter.
First install it:
npm install --dev eslint-formatter-checkstyle
yarn add --dev eslint-formatter-checkstyle
Then configure eslint, depending on your configuration it should look something like this:
{
"scripts": {
"mvntest": "eslint src/main/js -f checkstyle -o target/eslint-warnings.xml --ext js"
}
}
Then set the following properties in your pom.xml
to configure the Maven build to let Jenkins report the results:
<properties>
<maven.test.failure.ignore>false</maven.test.failure.ignore>
<frontend.testFailureIgnore>${maven.test.failure.ignore}</frontend.testFailureIgnore>
</properties>
Since version 2.195, Jenkins provides a Maven Bill Of Materials (BOM) that centrally defines versions of various libraries used by Jenkins Core and should make it easier to update to newer Jenkins Core versions
For more information, see the Dependency Management section of the plugin development guide.