From c2246b125029fcd3f61164cc84407766616f359a Mon Sep 17 00:00:00 2001 From: Marc Nuri Date: Sun, 1 Nov 2026 12:05:24 +0100 Subject: [PATCH 1/2] chore(ci): create the GitHub Release from the release workflow release.yml only published to Maven Central, and the GitHub Release had to be created by hand. That step was missed for v0.0.22. Add a final step that creates it with gh after a successful deploy: title is the tag, notes are generated, and it is marked latest, matching earlier releases. It skips if the release already exists. Document the automatic step and a manual fallback in AGENTS.md and the README. Co-authored-by: Claude Opus 5.5 Signed-off-by: Marc Nuri --- .github/workflows/release.yml | 12 ++++++++++++ AGENTS.md | 4 ++-- README.md | 3 ++- 3 files changed, 16 insertions(+), 3 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 44f0ea8..9efbcc9 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -12,6 +12,8 @@ jobs: release: name: Release runs-on: ubuntu-latest + permissions: + contents: write # gh release create steps: - name: Checkout uses: actions/checkout@v7 @@ -40,3 +42,13 @@ jobs: MAVEN_CENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }} MAVEN_CENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_PASSWORD }} SIGNINGPASSWORD: ${{ secrets.SIGNINGPASSWORD }} + - name: Create GitHub Release + run: | + if gh release view "$GITHUB_REF_NAME" > /dev/null 2>&1; then + echo "::notice::GitHub Release $GITHUB_REF_NAME already exists, skipping" + else + gh release create "$GITHUB_REF_NAME" --verify-tag --title "$GITHUB_REF_NAME" --generate-notes --latest + fi + env: + GH_TOKEN: ${{ github.token }} + GH_REPO: ${{ github.repository }} diff --git a/AGENTS.md b/AGENTS.md index 6f48b93..b228dc1 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -65,7 +65,7 @@ make maven-deploy # mvn -Prelease clean deploy (CI only; needs CI: - `.github/workflows/build.yml`: Linux job runs `make test-go` + `make build-all` on Java 8. Matrix jobs run `make build-current-platform` on Windows/macOS with Java 11. -- `.github/workflows/release.yml` and `snapshots.yml`: Linux Java 8; run `make build-all` then `make maven-deploy`. +- `.github/workflows/release.yml` and `snapshots.yml`: Linux Java 8; run `make build-all` then `make maven-deploy`. `release.yml` then creates the GitHub Release for the tag. - Shared CI infra: `.github/actions/free-disk-space` (composite action) reclaims runner disk space before Ubuntu builds. ## Releasing (maintainer only) @@ -75,7 +75,7 @@ Versioning is `0.0.X` patch-only; `main` always sits on `0.0-SNAPSHOT` (so `VS=0 1. **Pre-flight**: be on `main`, clean tree, in sync with `origin`. Skim `git log v0.0...HEAD --oneline` to confirm the scope is patch-worthy. 2. **Cut the release**: `make release V=0.0.X VS=0.0`. This sets the pom to `0.0.X`, commits, tags `v0.0.X`, **pushes the tag** (which triggers `release.yml`), then sets the pom back to `0.0-SNAPSHOT`, commits, and pushes `main`. Two commits land on `main` plus one tag. 3. **Wait for `release.yml`**: ~20 min. `gh run watch --exit-status` until it's green. It builds all 5 native binaries and runs `make maven-deploy` to Maven Central. If it fails partway, artifacts may be partially staged — don't re-run blindly, inspect first. -4. **Create the GitHub Release manually**: `release.yml` only publishes to Maven Central; it does NOT cut a GitHub Release. On https://github.com/manusa/helm-java/releases/new pick the `v0.0.X` tag and click **Generate release notes** (this is what every prior release used — a PR list plus the `compare/v0.0....v0.0.X` link). Publish. +4. **GitHub Release (automatic)**: once the Maven deploy succeeds, the `Create GitHub Release` step in `release.yml` runs `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. That gives the same format as every earlier release: a PR list plus the `compare/v0.0....v0.0.X` link. If the release already exists, the step skips. Check https://github.com/manusa/helm-java/releases. **Fallback** (the step failed or the deploy was finished by hand): on https://github.com/manusa/helm-java/releases/new pick the `v0.0.X` tag, click **Generate release notes**, and publish, or run `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. Don't re-run the whole job just to get the release: that would also redeploy to Maven Central, which rejects a version that already exists. 5. **Verify on Maven Central**: artifacts appear under https://central.sonatype.com/artifact/com.marcnuri.helm-java/helm-java within ~30 min of step 3 finishing. **Don't cancel running tests** that hit Kubernetes — they leak cluster resources. diff --git a/README.md b/README.md index e491f07..0025f71 100644 --- a/README.md +++ b/README.md @@ -888,7 +888,8 @@ To release a new version manually: #### Create GitHub Release -Once the release is published to Maven Central, create a new [GitHub release](https://github.com/manusa/helm-java/releases/new) for the released tag. +The `Release to Maven Central` workflow creates the GitHub release for the pushed tag, with generated release notes, after the Maven Central deployment succeeds. +If that step fails, create a new [GitHub release](https://github.com/manusa/helm-java/releases/new) for the released tag manually and use "Generate release notes". ### License Headers From 59468033e40c47eae178d982cc1bb2a4eae082ee Mon Sep 17 00:00:00 2001 From: Marc Nuri Date: Sun, 1 Nov 2026 18:21:51 +0100 Subject: [PATCH 2/2] chore(ci): create the GitHub Release in a separate job Raising the release job to contents: write gave that write token to every step, including the third-party build and deploy code run by make build-all and make maven-deploy, through the credentials checkout persists. Move the release creation into its own github-release job (needs: release) that alone gets contents: write, and pin the build job to contents: read. A failed GitHub Release can now be retried with "Re-run failed jobs" without redeploying to Maven Central, so update AGENTS.md and the README to match. Co-authored-by: Claude Opus 5.5 Signed-off-by: Marc Nuri --- .github/workflows/release.yml | 9 ++++++++- AGENTS.md | 4 ++-- README.md | 9 +++++++-- 3 files changed, 17 insertions(+), 5 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 9efbcc9..9997ecb 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -13,7 +13,7 @@ jobs: name: Release runs-on: ubuntu-latest permissions: - contents: write # gh release create + contents: read steps: - name: Checkout uses: actions/checkout@v7 @@ -42,6 +42,13 @@ jobs: MAVEN_CENTRAL_USERNAME: ${{ secrets.MAVEN_CENTRAL_USERNAME }} MAVEN_CENTRAL_PASSWORD: ${{ secrets.MAVEN_CENTRAL_PASSWORD }} SIGNINGPASSWORD: ${{ secrets.SIGNINGPASSWORD }} + github-release: + name: GitHub Release + needs: release + runs-on: ubuntu-latest + permissions: + contents: write # gh release create + steps: - name: Create GitHub Release run: | if gh release view "$GITHUB_REF_NAME" > /dev/null 2>&1; then diff --git a/AGENTS.md b/AGENTS.md index b228dc1..2bbd8f8 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -65,7 +65,7 @@ make maven-deploy # mvn -Prelease clean deploy (CI only; needs CI: - `.github/workflows/build.yml`: Linux job runs `make test-go` + `make build-all` on Java 8. Matrix jobs run `make build-current-platform` on Windows/macOS with Java 11. -- `.github/workflows/release.yml` and `snapshots.yml`: Linux Java 8; run `make build-all` then `make maven-deploy`. `release.yml` then creates the GitHub Release for the tag. +- `.github/workflows/release.yml` and `snapshots.yml`: Linux Java 8; run `make build-all` then `make maven-deploy`. `release.yml` then creates the GitHub Release for the tag in a separate `github-release` job. - Shared CI infra: `.github/actions/free-disk-space` (composite action) reclaims runner disk space before Ubuntu builds. ## Releasing (maintainer only) @@ -75,7 +75,7 @@ Versioning is `0.0.X` patch-only; `main` always sits on `0.0-SNAPSHOT` (so `VS=0 1. **Pre-flight**: be on `main`, clean tree, in sync with `origin`. Skim `git log v0.0...HEAD --oneline` to confirm the scope is patch-worthy. 2. **Cut the release**: `make release V=0.0.X VS=0.0`. This sets the pom to `0.0.X`, commits, tags `v0.0.X`, **pushes the tag** (which triggers `release.yml`), then sets the pom back to `0.0-SNAPSHOT`, commits, and pushes `main`. Two commits land on `main` plus one tag. 3. **Wait for `release.yml`**: ~20 min. `gh run watch --exit-status` until it's green. It builds all 5 native binaries and runs `make maven-deploy` to Maven Central. If it fails partway, artifacts may be partially staged — don't re-run blindly, inspect first. -4. **GitHub Release (automatic)**: once the Maven deploy succeeds, the `Create GitHub Release` step in `release.yml` runs `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. That gives the same format as every earlier release: a PR list plus the `compare/v0.0....v0.0.X` link. If the release already exists, the step skips. Check https://github.com/manusa/helm-java/releases. **Fallback** (the step failed or the deploy was finished by hand): on https://github.com/manusa/helm-java/releases/new pick the `v0.0.X` tag, click **Generate release notes**, and publish, or run `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. Don't re-run the whole job just to get the release: that would also redeploy to Maven Central, which rejects a version that already exists. +4. **GitHub Release (automatic)**: once the `release` job's Maven deploy succeeds, the separate `github-release` job in `release.yml` (`needs: release`, the only job with `contents: write`) runs `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. That gives the same format as every earlier release: a PR list plus the `compare/v0.0....v0.0.X` link. If the release already exists, the job skips. Check https://github.com/manusa/helm-java/releases. If only `github-release` failed, **Re-run failed jobs** re-runs just that job; it doesn't redeploy to Maven Central. **Fallback** (the re-run fails too, or the deploy was finished by hand): on https://github.com/manusa/helm-java/releases/new pick the `v0.0.X` tag, click **Generate release notes**, and publish, or run `gh release create v0.0.X --verify-tag --title v0.0.X --generate-notes --latest`. 5. **Verify on Maven Central**: artifacts appear under https://central.sonatype.com/artifact/com.marcnuri.helm-java/helm-java within ~30 min of step 3 finishing. **Don't cancel running tests** that hit Kubernetes — they leak cluster resources. diff --git a/README.md b/README.md index 0025f71..24c8346 100644 --- a/README.md +++ b/README.md @@ -888,8 +888,13 @@ To release a new version manually: #### Create GitHub Release -The `Release to Maven Central` workflow creates the GitHub release for the pushed tag, with generated release notes, after the Maven Central deployment succeeds. -If that step fails, create a new [GitHub release](https://github.com/manusa/helm-java/releases/new) for the released tag manually and use "Generate release notes". +The `Release to Maven Central` workflow creates the GitHub release for the pushed tag after the Maven Central deployment succeeds. A separate `GitHub Release` job does this, with the tag as title, generated release notes, and the release marked latest. If the release already exists, the job skips. +If only that job failed, use "Re-run failed jobs"; this re-runs just the GitHub Release job and does not redeploy to Maven Central. +If the re-run fails too, or the deployment was finished by hand, create a new [GitHub release](https://github.com/manusa/helm-java/releases/new) for the released tag manually with "Generate release notes", or run: + +```shell +gh release create vX.Y.Z --verify-tag --title vX.Y.Z --generate-notes --latest +``` ### License Headers