Repository navigation
ci: gate releases on CI, and bump the deprecated action versions - #5
Merged
Merged
Conversation
The Release workflow triggers on a tag push, CI on a branch push — two independent paths. Release ran no checks of its own, so a tag on a red commit built and published signed binaries regardless, with a shipped release as the first sign of trouble. That nearly happened at v0.4.0: the tagged commit failed `cargo fmt --check` and the release build was only stopped by hand. Release now runs CI as a gate before it builds anything. It calls the CI workflow rather than restating its steps, so the gate can't check less than CI does as CI grows. Chain is checks → build → publish. Also bump actions/checkout and actions/setup-node v4 → v7. Both were being force-migrated off the deprecated Node 20 actions runtime. The v5/v6 setup-node break — automatic caching driven by the packageManager field — doesn't reach us: both workflows already ask for `cache: npm` explicitly, and an explicit value still wins. Left alone deliberately: Swatinem/rust-cache, already on the current major, and tauri-apps/tauri-action, where @v0 → v1 is a major bump in the signing and notarization path and wants a deliberate test, not a drive-by. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
Why
Two independent trigger paths: CI runs on branch push, Release runs on tag push. Release ran no checks of its own — so a tag on a red commit builds and publishes signed binaries anyway, and the first sign of trouble is a release that already shipped.
That nearly happened at v0.4.0. The tagged commit failed
cargo fmt --check, and the release build was only stopped by cancelling it by hand.What
Gate. Release now runs CI before it builds anything:
checks → build → publish. It calls the CI workflow rather than restating its steps, so the gate can't check less than CI does as CI grows.Action bumps.
actions/checkoutandactions/setup-nodev4 → v7. Both were being force-migrated off the deprecated Node 20 actions runtime. The v5/v6 setup-node breaking change — automatic caching driven by thepackageManagerfield — doesn't reach us, since both workflows already passcache: npmexplicitly and an explicit value still wins.Left alone deliberately.
Swatinem/rust-cacheis already on the current major.tauri-apps/tauri-action@v0 → v1is a major bump straight through the signing and notarization path — that wants a deliberate test, not a drive-by.Verification
This PR exercises the bumped actions via its own CI run. The release gate itself is only fully exercisable on a tag push, so it gets its real test at the next release — the failure mode if the reusable-workflow wiring is wrong is a release that refuses to build, not one that ships unchecked.
🤖 Generated with Claude Code