ci: pin dtolnay/rust-toolchain action, keep channels via toolchain input - #450
Closed
arcaven wants to merge 7 commits into
Closed
ci: pin dtolnay/rust-toolchain action, keep channels via toolchain input#450arcaven wants to merge 7 commits into
arcaven wants to merge 7 commits into
Conversation
…ream sync) Port the ArcavenAE/jira-cli fork-friendly release-ops pipeline (docs/specs/fork-friendly-release-ops.md there) to the wirerust fork: - sign-and-publish.yml: five channels — develop push → alpha (wirerust-a, builds from source), v*-dev.* → wirerust-d, v*-beta.* → wirerust-b, v*-rc.* → wirerust-rc, v*.*.* → wirerust. Apple codesign + notarize + staple, .pkg/.dmg packaging, Homebrew tap formula publish. All jobs gated on SIGNING_ENABLED / HOMEBREW_TAP_REPO repository variables. - sync-upstream.yml: scheduled merge from Zious11/wirerust (main/develop/factory-artifacts) with protected-file auto-resolution via .github/local-workflows.txt. Gated on SYNC_UPSTREAM_REPO. - backfill-release.yml: manual-dispatch build+release+sign for an existing tag. No scheduled gap-fill automation is installed. - signing-guard.yml: fork-local CI job running scripts/check-signing-workflow-injection.sh (CWE-77 YAML-aware scanner) — hosted as a separate workflow instead of a ci.yml job so the upstream-shared ci.yml stays conflict-free. - Formula templates (wirerust, -a, -b, -d, -rc) for parallel channel installs; packaging/Info.plist + create-app/dmg/pkg scripts adapted to the wirerust binary and com.arcavenae.wirerust bundle id. Differences from the jira-cli original: no embedded-OAuth build env or smoke checks (wirerust has none), backfill matrix matches upstream release.yml targets (no aarch64-linux cross build).
The SHA-pinned dtolnay/rust-toolchain ref cannot infer the toolchain from the ref name and defaulted to rustc 1.85.0; wirerust requires 1.91. jira-cli masks this via rust-toolchain.toml (channel = stable), which wirerust does not carry. Applies to sign-and-publish alpha-build and backfill-release build. Refs: run 29458958576
The previous SHA is a snapshot of the action's 1.85.0 versioned branch,
which hardcodes its toolchain and rejects the toolchain input
('Unexpected input(s) toolchain'). Pin master, which requires and
honors an explicit toolchain spec.
Refs: run 29459130005
Homebrew's desc cop caps the description at 80 characters. The channel-suffix pattern makes long base descriptions a latent audit failure (jr-a sits at 79/80 today). Drop the redundant 'tool written in Rust' and use short channel suffixes so every variant stays under 55 characters.
These templates are the copy source for the next repo's release ops; the comment travels with the copy so the 80-char desc cap (including channel suffix) is visible at authoring time.
The stable and nightly refs were the repo's two documented pin-gate exemptions because the ref name carried the channel. Pinning the action commit (2c7215f, master 2026-08-04) and selecting the channel through the explicit toolchain input keeps rolling-channel semantics while closing the mutable-ref surface. The action-pin-gate allowlist is now empty and the gate validates every remote ref. Prepares for org-level sha_pinning_required, which has no allowlist mechanism.
Contributor
Author
|
Apologies for the noise: this was meant for our fork's own org policy change and gh resolved the default base to your repo. Closing. If SHA-pinning the toolchain action while keeping channel semantics is of interest here, happy to file a properly motivated version. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Org-level sha_pinning_required is being enabled on ArcavenAE, and it has no allowlist, so the repo's two documented pin-gate exemptions (dtolnay stable and nightly channel refs) would fail workflow startup. The exemption's premise was that the ref name carries the channel; pinning the action commit (2c7215f, master 2026-08-04) and selecting the channel through the explicit toolchain input keeps rolling stable/nightly semantics while closing the mutable-ref surface. The dated-nightly job already passed an explicit toolchain, so only its ref changes. The action-pin-gate allowlist is now empty; the gate validates every remote ref. YAML parse-checked; five stable sites gain toolchain: stable.