Skip to content

Commit

Permalink
Merge pull request #20 from timja/clean-docs
Browse files Browse the repository at this point in the history
Move docs to jenkins.io
  • Loading branch information
jglick committed May 21, 2021
2 parents 2494781 + e5c199a commit 724ec51
Showing 1 changed file with 1 addition and 146 deletions.
147 changes: 1 addition & 146 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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 @@
<extension>
<groupId>io.jenkins.tools.incrementals</groupId>
<artifactId>git-changelist-maven-extension</artifactId>
- <version>1.0-beta-7</version>
+ <version>1.1</version>
</extension>
</extensions>
--- 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 @@
- <version>${revision}${changelist}</version>
+ <version>${changelist}</version>
<packaging>hpi</packaging>
@@ -26,8 +26,7 @@
<properties>
- <revision>1.23</revision>
- <changelist>-SNAPSHOT</changelist>
+ <changelist>999999-SNAPSHOT</changelist>
<jenkins.version>2.176.4</jenkins.version>
<java.level>8</java.level>
</properties>
```

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 @@
<extension>
<groupId>io.jenkins.tools.incrementals</groupId>
<artifactId>git-changelist-maven-extension</artifactId>
- <version>1.0-beta-7</version>
+ <version>1.1</version>
</extension>
</extensions>
--- 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 @@
<artifactId>some-library-wrapper</artifactId>
- <version>${revision}${changelist}</version>
+ <version>${revision}-${changelist}</version>
<packaging>hpi</packaging>
<properties>
- <revision>4.0.0-1.3</revision>
- <changelist>-SNAPSHOT</changelist>
+ <revision>4.0.0</revision>
+ <changelist>999999-SNAPSHOT</changelist>
<jenkins.version>2.176.4</jenkins.version>
<java.level>8</java.level>
```

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
<version>${revision}</version>
```

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

Expand Down

0 comments on commit 724ec51

Please sign in to comment.