diff --git a/README.md b/README.md index e45b148..751ea99 100644 --- a/README.md +++ b/README.md @@ -263,152 +263,7 @@ to fix it up. ### Superseding Maven releases -If you want to use Incrementals _instead_ of MRP, -you can override `changelist.format` in your project (the default value is `-rc%d.%s`). - -For a regular component whose version number is not intrinsically meaningful: - -```diff ---- a/.mvn/extensions.xml -+++ b/.mvn/extensions.xml -@@ -2,6 +2,6 @@ - - io.jenkins.tools.incrementals - git-changelist-maven-extension -- 1.0-beta-7 -+ 1.1 - - ---- a/.mvn/maven.config -+++ b/.mvn/maven.config -@@ -1,2 +1,3 @@ - -Pconsume-incrementals - -Pmight-produce-incrementals -+-Dchangelist.format=%d.v%s ---- a/pom.xml -+++ b/pom.xml -@@ -7,7 +7,7 @@ -- ${revision}${changelist} -+ ${changelist} - hpi -@@ -26,8 +26,7 @@ - -- 1.23 -- -SNAPSHOT -+ 999999-SNAPSHOT - 2.176.4 - 8 - -``` - -Here a CI/release build (`-Dset.changelist` specified) will be of the form `123.vabcdef456789`. -A snapshot build will be `999999-SNAPSHOT`: arbitrary but treated as a snapshot by Maven and newer than any release. - -For a component whose version number ought to reflect a release version of some wrapped component: - -```diff ---- a/.mvn/extensions.xml -+++ b/.mvn/extensions.xml -@@ -2,6 +2,6 @@ - - io.jenkins.tools.incrementals - git-changelist-maven-extension -- 1.0-beta-7 -+ 1.1 - - ---- a/.mvn/maven.config -+++ b/.mvn/maven.config -@@ -1,2 +1,3 @@ - -Pconsume-incrementals - -Pmight-produce-incrementals -+-Dchangelist.format=%d.v%s ---- a/pom.xml -+++ b/pom.xml -@@ -10,12 +10,12 @@ - some-library-wrapper -- ${revision}${changelist} -+ ${revision}-${changelist} - hpi - -- 4.0.0-1.3 -- -SNAPSHOT -+ 4.0.0 -+ 999999-SNAPSHOT - 2.176.4 - 8 -``` - -Here the version numbers will look like `4.0.0-123.vabcdef456789` or `4.0.0-999999-SNAPSHOT`, respectively. -When you pick up a new third-party component like `4.0.1`, your version numbers will match; -to refer to the third-party component, just use - -```xml -${revision} -``` - -Since inadvertently running MRP on such a project would result in a mess, -it is best to explicitly prevent that. -This is done automatically by the plugin and general component parent POMs -when you define the `changelist.format` property. - -#### Automatic deployment - -If you have configured `changelist.format` as above, -using [JEP-229](https://jenkins.io/jep/229) you can then set up automatic publishing of artifacts. - -First, file a patch to your component’s entry(ies) in [RPU](https://github.com/jenkins-infra/repository-permissions-updater/tree/master/permissions) to add - -```yaml -cd: - enabled: true -``` - -Once that has been merged, start checking `https://github.com/jenkinsci/your-plugin/settings/secrets/actions` -and you should soon see `MAVEN_TOKEN` and `MAVEN_USERNAME` appear under **Repository secrets**. - -Next, if you already have Release Drafter configured, -remove any `tag-template` override in `.github/release-drafter.yml`, -and delete `.github/workflows/release-drafter.yml` if using GitHub Actions (or remove the app from the repo otherwise). -If you have not yet configured Release Drafter, just create `.github/release-drafter.yml` containing only - -```yaml -_extends: .github -``` - -If you have a `.github/dependabot.yml`, it is a good idea to add - -```yaml -- package-ecosystem: github-actions - directory: / - schedule: - interval: daily -``` - -Finally create `.github/workflows/cd.yaml` as a copy of [this template](https://github.com/jenkinsci/.github/blob/master/workflow-templates/cd.yaml). - -Now whenever Jenkins reports a successful build of your default branch, -and at least one pull request had a label indicating it was of interest to users (e.g. `enhancement` rather than `chore`), -your component will be released to Artifactory and release notes published in GitHub. -You do not need any special credentials or local checkout; -just merge pull requests with suitable titles and [labels](https://github.com/jenkinsci/.github/blob/7baf6188c5dbe8f872bd7f4e13e1aaeee0b2e279/.github/release-drafter.yml#L9-L49). - -You can also trigger a deployment explicitly, if the current commit has a passing check from Jenkins. -Visit `https://github.com/jenkinsci/your-plugin/actions?query=workflow%3Acd` and click **Run workflow**. -If you prefer to only deploy explicitly, not on every push, just comment out the `check_run` section above. - -(Do not be alarmed to see numerous failed `cd` workflows besides the passing ones that actually deployed: -every check posted other than the top-level `Jenkins` check triggers a workflow which should quickly fail.) - -As a fallback, you can also release manually if you have -[personal deployment credentials](https://github.com/jenkins-infra/repository-permissions-updater). -To cut a release: - -```bash -git checkout master -git pull --ff-only -mvn -Dset.changelist -DaltDeploymentRepository=maven.jenkins-ci.org::default::https://repo.jenkins-ci.org/releases/ clean deploy -``` +See [Setting up automated plugin release](https://www.jenkins.io/redirect/continuous-delivery-of-plugins) ## Usage in other POMs