You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplify Gradle build logic for making releases. (#684)
Release and release candidate builds require a clean working directory and a matching tag: Create a tag for the release version first, then execute whatever build target you need with the corresponding version specified as project property (`-PpublishVersion=A.B.C` or `-PpublishVersion=A.B.C-rcN`). Release builds additionally enforce signing of the generated artifacts.
Ad hoc builds from branches (including `master`) or arbitrary "version" designators always result in SNAPSHOT builds and don't require a clean working directory or a matching tag: Specify the desired "version" as project property (`-PpublishVersion=A-B-C-SNAPSHOT`) or simply omit it (will then use the current branch name).
Copy file name to clipboardExpand all lines: MAINTAINING.md
+34-52Lines changed: 34 additions & 52 deletions
Original file line number
Diff line number
Diff line change
@@ -54,67 +54,59 @@ sonatypePassword=$token
54
54
55
55
These are done more often, in irregular intervals. They are not considered stable and may break your application, so be cautious when using them.
56
56
57
-
The process is equal to the making of a release candidate, but without making any tags:
57
+
The process is identical to making a release candidate, but without making any tags:
58
58
59
-
1.build and upload the `master-SNAPSHOT`:
59
+
1.Switch to the `master` branch:
60
60
```
61
-
git pull; git checkout master;
61
+
git switch master
62
62
```
63
-
1. proceed as described in [Release candidate - Upload to Sonatype](#upload-to-sonatype)
63
+
1. Proceed as described in [Release candidate - Upload to Sonatype](#upload-to-sonatype), but omit the `publishVersion` parameter in order to build and upload the `master-SNAPSHOT`.
64
64
65
65
## Release candidate
66
66
67
67
*Release candidates should be tested by different people before releasing!*
68
68
69
69
### Prepare your release candidate
70
70
71
-
1. Make an rc-branch (necessary for Gradle to pick up the proper name):
71
+
1. Make an annotated signed tag for the release candidate (necessary for Gradle to pick up the proper name):
72
72
```
73
-
git checkout -b A.B.C-rcN
73
+
git tag -s metafacture-core-A.B.C-rcN
74
+
```
75
+
1. When prompted, add a sensible commit message. For instance, something like:
76
+
```
77
+
Release candidate 5.7.0
74
78
```
75
-
(leave out the ` metafacture-core-` to avoid later the git "error: src refspec ... matches more than one" when you push the annotated git tag for having a tag named the same as the branch is not possible)
76
79
1. Optionally, you can now test the build locally by invoking a Gradle target:
77
80
```
78
-
./gradlew assemble
81
+
./gradlew assemble -PpublishVersion=A.B.C-rcN
79
82
```
80
83
81
84
### Upload to Sonatype
82
85
83
-
1. Now you can build and upload the release candidate to Sonatype (note that `./gradlew` should inform you to make a "snapshot build". If the version doesn't end with `-SNAPSHOT` the artifacts will not be uploaded to Sonatype's snapshot repository!):
1. Go to [Sonatype's snapshot repository](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture) and type in the correct `Version` to see if it is already available there (can take some minutes). [Example for `5.5.1-rc1-SNAPSHOT`](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture~~5.5.1*~~)(if you don't see a `5.5.1-rc1-SNAPSHOT.jar` there check it at https://oss.sonatype.org/content/repositories/snapshots/org/metafacture/metafacture-biblio/5.5.1-rc1-SNAPSHOT/).
88
-
1. Make an annotated signed tag (it's important to do that _after_ uploading to Sonatype's snapshot repository because otherwise the `-SNAPSHOT` will not be appended to the release candidate thus will not land in `snapshot repository`):
86
+
1. Make sure to have a *clean* Git directory (otherwise the build will fail with the error message `Working copy has modifications`):
89
87
```
90
-
git tag -s metafacture-core-A.B.C-rcN
88
+
git status
91
89
```
92
-
1. Push the annotated signed tag to GitHub:
90
+
1. Now you can build and upload the release candidate to Sonatype (note that `./gradlew` should inform you to make a "snapshot build". If the version doesn't end with `-SNAPSHOT` the artifacts will not be uploaded to Sonatype's snapshot repository!):
1. Go to [Sonatype's snapshot repository](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture) and type in the correct `Version` to see if it is already available there (can take some minutes). [Example for `5.5.1-rc1-SNAPSHOT`](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture~~5.5.1*~~)(if you don't see a `5.5.1-rc1-SNAPSHOT.jar` there check it at https://oss.sonatype.org/content/repositories/snapshots/org/metafacture/metafacture-biblio/5.5.1-rc1-SNAPSHOT/).
96
95
97
96
### Publish to [GitHub Packages](https://github.com/orgs/metafacture/packages?repo_name=metafacture-core)
98
97
99
-
1. Push your properly named branch to GitHub. Notice the `-rc` part of the branch's name:
98
+
1. Push the annotated signed tag to GitHub:
100
99
```
101
-
git push origin A.B.C-rcN
100
+
git push origin tag metafacture-core-A.B.C-rcN
102
101
```
103
-
Because there is `fetch --no-tags` in `actions/checkout@v2` the `-SNAPSHOT` suffix will always be appended (in comparison to doing `./gradlew publishAllPublicationsToGitHubPackagesRepository` locally, which will find the `SCM tag`). The publishing to GitHub packages is triggered then.
104
-
105
-
If we don't want `-SNAPSHOT` we may want to remove the `-SNAPSHOT` in `build.gradle`:
106
-
```
107
-
if (grgit.branch.current().name.contains('-rc')) { ...
108
-
return "${grgit.branch.current().name}-SNAPSHOT"
109
-
}
110
-
```
102
+
The publishing to GitHub packages is triggered then via the GitHub Actions workflow.
111
103
112
104
Note that `Packages` is not the same as [`Releases`](https://github.com/metafacture/metafacture-core/releases).
113
105
114
106
### Consume the SNAPSHOT
115
107
116
-
1. See e.g. [Example for 5.5.1-rc1-SNAPSHOT](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture~~5.5.1*~~) how to configure the dependency.
117
-
1. Configure your build system to use Sonatype's Snapshot Repository to be able to load the dependencies of the release candidate (or master-SNAPSHOT).
108
+
1. See e.g. [5.5.1-rc1-SNAPSHOT](https://oss.sonatype.org/index.html#nexus-search;gav~org.metafacture~~5.5.1*~~) for how to configure the dependency.
109
+
1. Configure your build system to use Sonatype's Snapshot Repository to be able to load the dependencies of the release candidate (or `master-SNAPSHOT`).
118
110
For Maven update your `pom.xml` (after `</dependencies>`):
119
111
```xml
120
112
<repositories>
@@ -149,43 +141,33 @@ Note that `Packages` is not the same as [`Releases`](https://github.com/metafact
149
141
150
142
a) It's going from your local Git repository to Sonatype to Maven Central. Each station requires some manual actions so you can double check that everything is ok. b) A release should also be published to GitHub.
151
143
152
-
1. Switch to `master` branch. Merge the approved `rc` into master:
1. When prompted, add a sensible commit message. For instance, something like:
166
153
```
167
154
Release 5.7.0
168
155
```
169
-
1. Make sure you have that signed tag pushed to GitHub:
170
-
```
171
-
git ls-remote --tags origin
172
-
```
173
-
If it is missing, push it with:
156
+
1. Push the annotated signed tag to GitHub:
174
157
```
175
-
git push origin metafacture-core-A.B.C
158
+
git push origin metafacture-core-A.B.C
176
159
```
177
-
1. Now the tag is available at GitHub. You can manually choose to [draft a new release on GitHub](https://github.com/metafacture/metafacture-core/releases/new). The signed `*dist*` files must be uploaded manually. They are produced like this:
160
+
1. Make sure to have a *clean* Git directory (otherwise the build will fail with the error message `Working copy has modifications`):
178
161
```
179
-
./gradlew metafacture-runner:signArchive
162
+
git status
180
163
```
181
-
and can be found in `metafacture-core/metafacture-runner/build/distributions/` (don't mind the `Source code` for that is created by GitHub automatically).
182
-
1. Make sure to have a *clean* Git directory (otherwise only a SNAPSHOT will be built):
164
+
1. Now the tag is available on GitHub. You can manually choose to [draft a new release on GitHub](https://github.com/metafacture/metafacture-core/releases/new). The signed `*-dist.*` files must be uploaded manually. They are produced like this:
1. Finally, go to [oss.sonatype.org](https://oss.sonatype.org), log in, check the [Staging Repositories](https://oss.sonatype.org/#stagingRepositories) and when it's finished, click on `Close`. If everything is good publish with clicking on `Release` - attention, because once published it can't be removed. The artifacts are uploaded to Maven Central (which may take some time. Have a look e.g. [metafacture-biblio](https://repo1.maven.org/maven2/org/metafacture/metafacture-biblio/) ). You can check that it's actually in the publishing pipeline by clicking on `Views/Repositories->Releases`, then type in the `Path lookup` field `org/metafacture/` and click on version.
191
-
173
+
1. Finally, go to [oss.sonatype.org](https://oss.sonatype.org), log in, check the [Staging Repositories](https://oss.sonatype.org/#stagingRepositories) and when it's finished, click on `Close`. If everything is good, publish with clicking on `Release` - attention, because once published it can't be removed. The artifacts are uploaded to Maven Central (which may take some time; have a look at e.g. [metafacture-biblio](https://repo1.maven.org/maven2/org/metafacture/metafacture-biblio/)). You can check that it's actually in the publishing pipeline by clicking on `Views/Repositories->Releases`, then type in the `Path lookup` field `org/metafacture/` and click on version.
0 commit comments