Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/jenkinsci/plugin-pom
Parent POM for Jenkins Plugins
https://github.com/jenkinsci/plugin-pom
jenkins jenkins-plugin parent-pom
Last synced: 2 days ago
JSON representation
Parent POM for Jenkins Plugins
- Host: GitHub
- URL: https://github.com/jenkinsci/plugin-pom
- Owner: jenkinsci
- License: mit
- Created: 2016-01-20T22:12:42.000Z (almost 9 years ago)
- Default Branch: master
- Last Pushed: 2024-12-12T21:18:10.000Z (10 days ago)
- Last Synced: 2024-12-12T22:25:19.201Z (10 days ago)
- Topics: jenkins, jenkins-plugin, parent-pom
- Language: Java
- Homepage: https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial
- Size: 1.49 MB
- Stars: 70
- Watchers: 104
- Forks: 77
- Open Issues: 14
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: CONTRIBUTING.adoc
- Funding: .github/FUNDING.yml
- License: LICENSE
Awesome Lists containing this project
README
# Parent POM for Jenkins Plugins
[](https://github.com/jenkinsci/plugin-pom/releases/latest)
[](https://github.com/jenkinsci/plugin-pom/blob/master/LICENSE)
## Introduction
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.
## Requirements
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.
## Usage
To use the plugin parent POM, change the parent POM of your plugin:
```xml
org.jenkins-ci.plugins
plugin
VERSION
```
Then override the needed properties, e.g.:
```xml
2.361.4
```
If you have a `jar:test-jar` execution, delete it and add the following to ``:
```xml
false
```
## Overridable properties
The following properties are overridable:
* `jenkins.version`: The Jenkins version required by the plugin. **Mandatory.** See [Requirements](#requirements) for more info. Being able to specify the `jenkins.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](https://github.com/jenkinsci/jenkins-test-harness/releases) used to test plugin. Uses split test-harness (see [JENKINS-32478](https://issues.jenkins-ci.org/browse/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` and `npm.version` properties are provided.
## Incrementals
You can configure your plugin to treat every commit as a release candidate.
See [Incrementals](https://github.com/jenkinsci/incrementals-tools) for details.
## Formatting
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:
```bash
mvn spotless:apply
```
After formatting an existing repository, squash merge the PR and create a
[`.git-blame-ignore-revs`](https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#ignore-commits-in-the-blame-view)
file to hide the formatting commit from blame tools.
### Format as you build
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`:
```xml
[...]
[...]
may-spotless-apply
```
## Running Benchmarks
To run JMH benchmarks from JUnit tests, you must run you must activate the `benchmark`
profile. For example:
```bash
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](https://github.com/jenkinsci/jenkins-test-harness/blob/master/docs/jmh-benchmarks.adoc)
## Javadoc
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.
## Releasing
Tests are skipped during the `perform` phase of a release. This can be overridden by setting `release.skipTests` to false.
## Setup Wizard
By default, the setup wizard (Jenkins >= 2.0) is skipped when using `hpi:run`. If you want the wizard to be enabled just run:
```bash
mvn -Dhudson.Main.development=false hpi:run
```
## npm or yarn
If you want to add `npm` or `yarn` to your plugin, you can do so by creating a marker file:
For npm:
```bash
touch .mvn_exec_node
```
For yarn:
```bash
touch .mvn_exec_yarn
```
You need to add corresponding properties to your `pom.xml` and set them to valid values:
For npm:
```xml
set this to the latest node lts version
set this to the latest npm version
```
For yarn:
```xml
set this to the latest node lts version
set this to the latest yarn version
```
### Configuring Jest to report results to Jenkins
Our [pipeline-library](https://github.com/jenkins-infra/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`:
```bash
npm install --dev jest-junit
```
```bash
yarn add --dev jest-junit
```
Then configure jest-junit by modifying the `package.json`:
```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:
```xml
false
${maven.test.failure.ignore}
```
### Configuring eslint to report results to Jenkins
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:
```bash
npm install --dev eslint-formatter-checkstyle
```
```bash
yarn add --dev eslint-formatter-checkstyle
```
Then configure eslint, depending on your configuration it should look something like this:
```json
{
"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:
```xml
false
${maven.test.failure.ignore}
```
## Jenkins Core BOM
Since version 2.195, Jenkins provides a [Maven Bill Of Materials (BOM)](https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies)
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](https://jenkins.io/doc/developer/plugin-development/dependency-management/) section of the
[plugin development guide](https://jenkins.io/doc/developer/plugin-development/).