Skip to content

ci: rust-cache was caching nothing, it needs workspaces - #7

Merged
MattJackson merged 3 commits into
mainfrom
ci/rust-cache-workspaces
Aug 12, 2026
Merged

ci: rust-cache was caching nothing, it needs workspaces#7
MattJackson merged 3 commits into
mainfrom
ci/rust-cache-workspaces

Conversation

@MattJackson

Copy link
Copy Markdown
Contributor

rust-cache was caching nothing here

Swatinem/rust-cache@v2 was used with no workspaces: input. The action looks for one Cargo workspace at $GITHUB_WORKSPACE, and nothing is checked out there: every actions/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. That is the worst shape a cache misconfiguration can take: it costs full build time on every run and reports success.

Every Cargo workspace the job actually builds is now named. Where the job also builds the sibling busbar checkout, that is listed too, and it matters more than the plugin's own: busbar-plugin-pack plus a full release build of busbar is by far the larger of the two.

Deliberately left alone

Checked every workflow in this repo that uses Swatinem/rust-cache, not just the ones changed. A job whose Cargo workspace genuinely is at the checkout root needs nothing and got nothing, rather than a workspaces: . that would be pure noise. headroom-hook/.github/workflows/docker.yml is one such case (its checkout has no path:), and headroom-hook/.github/workflows/docker-bundle.yml already carried a correct workspaces: busbarAI.

Part of a fleet sweep

Same fix applied across the first-party plugin repos, and to the reusable plugin-ci.yml in core (GetBusbar/busbar#58), which had the same defect and reaches every plugin repo at once.

MattJackson and others added 3 commits August 8, 2026 16:06
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.
`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.
@MattJackson
MattJackson merged commit 2854f5c into main Aug 12, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant