Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update RELEASING.md #4590

Merged
merged 4 commits into from
Oct 22, 2021
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
21 changes: 12 additions & 9 deletions RELEASING.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,18 +6,21 @@ Testcontainers' release process is semi-automated through GitHub Actions. This d

1. Ensure that the master branch is building and that tests are passing.
1. Create a new release on GitHub. **The tag name is used as the version**, so please keep the tag name plain (e.g. 1.2.3).
1. The release triggers a GitHub Action workflow, but it gets mostly build using results from the Gradle remote-cache. Therefore, this should be fairly fast.
1. Login to Sonatype to check the staging repository.
1. Get the staging url after GitHub Action workflow finished.
1. Manually test the release with the staging url as maven repository url (e.g. critical issues and features).
1. Run [TinSalver](https://github.com/bsideup/tinsalver) from GitHub using `npx` to sign artifact (see [TinsSalver README](https://github.com/bsideup/tinsalver/blob/main/README.md)).
1. Close the release in Sonatype. This will evaluate the release based on given Sontaype rules and afterwards automatically sync to Maven Central.
1. Handcraft and polish some of the release notes (e.g. substitute combinded dependency PRs and highlight certain features).
1. When available through Maven Central, poke [Richard North](https://github.com/rnorth) to announce the release on Twitter!
1. The release triggers a GitHub Action workflow.
1. Log in to [Sonatype](https://oss.sonatype.org/) to check the staging repository.
* Getting access to Sonatype requires a Sonatype JIRA account and [raising an issue](https://issues.sonatype.org/browse/OSSRH-74229), requesting access.
3. Get the staging URL from Sonatype after GitHub Action workflow finished. The general URL format should be `https://oss.sonatype.org/service/local/repositories/$staging-repo-id/content/`
4. Manually test the release with the staging URL as maven repository URL (e.g. critical issues and features).
5. Run [TinSalver](https://github.com/bsideup/tinsalver) from GitHub using `npx` to sign artifact (see [TinSalver README](https://github.com/bsideup/tinsalver/blob/main/README.md)).
* For TinSalver to correctly work with keybase on WSL on Windows, you might need to disable pinentry: `keybase config set -b pinentry.disabled true`.
7. Close the release in Sonatype. This will evaluate the release based on given Sonatype rules.
8. After successful closing, the release button needs to be clicked and afterwards it is automatically synced to Maven Central.
9. Handcraft and polish some of the release notes (e.g. substitute combinded dependency PRs and highlight certain features).
10. When available through Maven Central, poke [Richard North](https://github.com/rnorth) to announce the release on Twitter!

## Internal details

* The process is done with GitHub Actions, TinSalver and Sonatype.
* Sonatype will automatically promote the staging release to Maven Central.
* Keybase needs to be installed on the developer machine.
* GPG key of signing developer needs to be uplodaed to the Ubuntu keyserver (or other server supported by Sonatype).
* GPG key of signing developer needs to be uplodaed to the [Ubuntu keyserver](https://keyserver.ubuntu.com/) (or other server supported by Sonatype).