Skip to content

chore(ci): pin dtolnay/rust-toolchain to SHA#237

Merged
tylergraydev merged 1 commit into
mainfrom
chore/pin-rust-toolchain-action
May 16, 2026
Merged

chore(ci): pin dtolnay/rust-toolchain to SHA#237
tylergraydev merged 1 commit into
mainfrom
chore/pin-rust-toolchain-action

Conversation

@tylergraydev
Copy link
Copy Markdown
Owner

Replaces all 5 @stable refs across build.yml, release.yml, and rust-tests.yml with a SHA pin to 29eef336d9b2848a0b548edc03f92a220660cdb8 (@stable head as of 2026-03-27).

Why

@stable is a floating ref — any regression dtolnay ships breaks every PR in flight at once, and we have no signal until a build fails. Pinning to SHA freezes our action surface so toolchain changes become explicit lockfile-style updates we choose to take.

What this does NOT fix

The recent macOS cargo metadatarustup-init flake hitting several open PRs (#226, #228, #231, #232, #234) is runner-side, not action-side: this SHA was already what @stable resolved to before and during the flake window. Reruns of failed jobs are passing on the same SHA, confirming it's transient runner state, not the action.

So this PR is hygiene, not the fix for the current symptom. If the flake persists we'll need to either:

  • work around in the workflow (retry on the rust-toolchain step), or
  • switch to actions-rust-lang/setup-rust-toolchain

Updating later

When we want a newer toolchain or action behavior, bump the SHA and update the trailing comment. Worth pointing Dependabot at github-actions to get auto-proposed bumps for these.

🤖 Generated with Claude Code

Replaces all 5 `@stable` refs across build.yml, release.yml, and
rust-tests.yml with a SHA pin to 29eef336d9b2848a0b548edc03f92a220660cdb8
(`@stable` head as of 2026-03-27).

## Why

`@stable` is a floating ref — any regression dtolnay ships breaks
every PR in flight at once, and we have no signal until a build fails.
Pinning to SHA freezes our action surface so toolchain changes become
explicit lockfile-style updates we choose to take.

## What this does NOT fix

The recent macOS `cargo metadata` -> `rustup-init` flake hitting
several open PRs (#226, #228, #231, #232, #234) is runner-side, not
action-side: this SHA was already what `@stable` resolved to before
and during the flake window. Reruns of failed jobs are passing on the
same SHA, confirming it's transient runner state, not the action.

So this PR is hygiene, not the fix for the current symptom. If the
flake persists we'll need to either work around in the workflow
(retry on the rust-toolchain step) or switch to
`actions-rust-lang/setup-rust-toolchain`.

## Updating later

When we want a newer toolchain or action behavior, bump the SHA and
update the trailing comment. Dependabot can be configured to track
github-actions and propose the bumps.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@tylergraydev tylergraydev merged commit 78e8006 into main May 16, 2026
10 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