From 791511c132463640c27061c8ac12e08f872e6041 Mon Sep 17 00:00:00 2001
From: Matthew Jackson <1085847+MattJackson@users.noreply.github.com>
Date: Sat, 8 Aug 2026 16:06:44 -0700
Subject: [PATCH 1/2] ci: rust-cache was caching nothing, it needs workspaces

Swatinem/rust-cache@v2 was used with no workspaces input. The action looks for
one Cargo workspace at the checkout root, and nothing is checked out there:
every checkout in these jobs uses path:. The action logged "could not find
Cargo.toml" and carried on WITHOUT failing, so the job rebuilt everything from
scratch on every run while the log said the cache step succeeded.

Every workspace the job actually builds is now named. Where the job also builds
the sibling busbar checkout, that is listed too: it is by far the larger of the
two builds and the one worth caching most.
---
 .github/workflows/release.yml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index df0fb0b..c0afaaf 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -108,6 +108,15 @@ jobs:
         with:
           targets: ${{ matrix.target }}
       - uses: Swatinem/rust-cache@v2
+        with:
+          # REQUIRED. Without `workspaces:` this action looks for ONE Cargo workspace at the
+          # checkout root, and nothing is checked out there: every checkout above uses `path:`.
+          # It logged "could not find Cargo.toml" and carried on WITHOUT failing, so this job
+          # rebuilt everything from scratch on every run while the log said the cache step
+          # succeeded. Each workspace this job actually builds must be named.
+          workspaces: |
+            webrequest-hook
+            busbarAI
 
       - name: Build the webrequest-hook plugin cdylib
         working-directory: webrequest-hook

From 4aefa7bf5673be63368df53990b012a0cf21b721 Mon Sep 17 00:00:00 2001
From: matthew <dev@getbusbar.com>
Date: Sat, 8 Aug 2026 19:42:09 -0700
Subject: [PATCH 2/2] release: stop `create || view` uploading onto a stale
 Release

`gh release create ... || gh release view ...` cannot tell the two reasons
`create` fails apart. The intended one is the benign race: two runs of this job
fire for the same tag, the loser gets "a release already exists", and reusing it
is right. But EVERY other failure -- a `--verify-tag` rejection after a tag was
force-moved, an auth error, a `--generate-notes` error -- also falls through to
`view`, and if a stale draft Release from a prior aborted run happens to be
sitting there, `view` SUCCEEDS. The step goes green and the matrix then signs,
attests and uploads artefacts onto that stale Release.

Now only "already exists" is swallowed; anything else re-raises the original
exit status. Verified in all three states with a stubbed `gh`:

  create succeeds        -> exit 0
  create says "already exists" -> reuses via view, exit 0
  create fails otherwise -> exit 1   (previously: exit 0, onto the stale release)

Six of the ten sibling plugin repos already do exactly this -- canonical form in
auth-oidc's release.yml -- and it is what fixed hashicorp-vault. This repo was one
of the three stragglers, which is the same "fixed here, missed there" drift that
produced the aarch64 pubkey defect.
---
 .github/workflows/release.yml | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
index c0afaaf..16ebd73 100644
--- a/.github/workflows/release.yml
+++ b/.github/workflows/release.yml
@@ -46,11 +46,29 @@ jobs:
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
         run: |
-          gh release create "${GITHUB_REF_NAME}" \
+          set +e
+          create_out=$(gh release create "${GITHUB_REF_NAME}" \
             --repo "${GITHUB_REPOSITORY}" \
             --title "busbar-webrequest ${GITHUB_REF_NAME}" \
-            --draft --verify-tag --generate-notes \
-          || gh release view "${GITHUB_REF_NAME}" --repo "${GITHUB_REPOSITORY}"
+            --draft --verify-tag --generate-notes 2>&1)
+          status=$?
+          set -e
+          echo "$create_out"
+          if [ "$status" -eq 0 ]; then
+            exit 0
+          fi
+          # Only swallow the specific "a release already exists for this tag" race (two runs of this
+          # job triggered for the same tag) — any other failure (auth error, --verify-tag rejection,
+          # --generate-notes error, etc.) must fail the job, not be silently papered over by falling
+          # through to `gh release view`. A bare `create || view` cannot tell those apart: when a
+          # STALE Release from a prior aborted run exists, `view` succeeds and the step goes green,
+          # and the matrix then signs, attests and uploads onto that stale Release.
+          if echo "$create_out" | grep -qi "already exists"; then
+            echo "Release ${GITHUB_REF_NAME} already exists — reusing it (parallel/retried run)."
+            gh release view "${GITHUB_REF_NAME}" --repo "${GITHUB_REPOSITORY}"
+          else
+            exit "$status"
+          fi
 
   # One signed .tar.gz per target: {cdylib + manifest.json}, packed by busbar-plugin-pack and
   # signed with the busbar release PRIVATE key (BUSBAR_SIGN_KEY secret) so it verifies as