From 1b2ac2d88a96ac4b80681163b0158035aad1260d Mon Sep 17 00:00:00 2001 From: Simon Koudijs Date: Mon, 27 Jul 2026 18:20:04 +0000 Subject: [PATCH 1/2] fix(release): give the analyzer job the bash it was written for MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The publish-analyzer job declares `container:`, and a container job's default shell is `sh`, not the `bash` a runner-hosted job gets. Its build step opens with `set -euo pipefail`, which dash rejects: the 0.40.0 release died on that first line with "Illegal option -o pipefail", 59 seconds in, having compiled nothing. The job is gated on `release_created`, so it had never once run before that release — cancelled in the run that added it, skipped in the next. Its first execution was also its first failure, and it fails every time, not intermittently. Declaring the shell for the whole job rather than the one broken step keeps a later step from silently inheriting dash again. publish-helm is the other container job and carries the same trap, but it uses no bash-only syntax, so it stays untouched here. Co-Authored-By: Claude Opus 5 (1M context) --- .github/workflows/release.yml | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index a6cd4c76..101a1725 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -412,6 +412,13 @@ jobs: credentials: username: ${{ github.actor }} password: ${{ secrets.GITHUB_TOKEN }} + # A container job defaults to `sh`, not the `bash` a runner-hosted job gets, and dash + # rejects `set -o pipefail` outright: the build step below died on its own first line + # with "Illegal option -o pipefail", before compiling anything. Declaring the shell for + # the whole job keeps a later step from silently inheriting dash again. + defaults: + run: + shell: bash steps: - name: Checkout code uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1 From 98b7ad1593b7cd86c03938e63c4d1fd70c203dcb Mon Sep 17 00:00:00 2001 From: Simon Koudijs Date: Tue, 28 Jul 2026 05:50:32 +0000 Subject: [PATCH 2/2] docs(release): write down the orphaned-anchor recovery A failed publish job strands the GitHub Release as a draft, and a draft is invisible to release-please twice over: it is skipped in the release search and it creates no tag. The manifest still names the version, so the next run has a version it cannot anchor and proposes the entire history as one release. It has now happened twice, and both times the recovery was rediscovered from scratch rather than looked up. The fix is a lightweight tag at the release commit, which the troubleshooting section now spells out alongside the log line that identifies the case, so the next person matches the symptom instead of deriving it. Co-Authored-By: Claude Opus 5 (1M context) --- .github/RELEASES.md | 42 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/.github/RELEASES.md b/.github/RELEASES.md index d6e2f5e5..a9c043dd 100644 --- a/.github/RELEASES.md +++ b/.github/RELEASES.md @@ -217,6 +217,48 @@ git push origin main **Solution:** Edit Release PR version or close it and retrigger. +### Release PR Contains the Entire History + +**Symptom:** the release PR proposes an unexpectedly large bump and a changelog that +re-announces releases that already shipped. The Release Please job log names the cause: + +```text +✔ No latest release found for path: ., component: , but a previous version (0.40.0) + was specified in the manifest. +``` + +**Cause:** release-please anchors on published GitHub Releases and falls back to git +tags. `release-please-config.json` sets `draft: true`, which the publish jobs need so +they can attach assets before immutable releases freeze the release. So a publish job +that fails leaves the release as a **draft**, and a draft is skipped by the release +search *and* creates no tag. `.release-please-manifest.json` still names the version, +leaving release-please with a version it cannot anchor, so it collects every commit in +the repository. + +Do not merge that PR: it burns a version number on a changelog of already-released work. + +**Solution:** supply the missing anchor. A bare lightweight tag is enough: release-please +falls back to tags, so no GitHub Release is required. + +```bash +# The SHA is the "chore(main): release X.Y.Z" merge commit for the stranded version. +git tag vX.Y.Z +git push origin vX.Y.Z + +# Close the oversized PR and drop its branch so a fresh one is generated, not amended. +gh pr close --delete-branch + +# Re-run the Release Please job, then confirm the new PR is the expected patch bump. +gh run rerun --job +``` + +Then resolve the stranded draft. Delete it with `gh release delete vX.Y.Z --yes` (which +leaves the tag in place) when the assets it is missing should ship in the next release. +Publishing it instead freezes a release whose own notes link to assets it does not carry. + +`last-release-sha` does not rescue this: release-please reads it only as a top-level key, +and this repo's copy sits under `packages["."]`, where it is ignored. + ### Docker Build Failed **Check:**