release.yml: fail fast if the pushed tag doesn't match Cargo.toml's version - #561
Merged
Conversation
…ersion Nothing verified that the git tag triggering a release (e.g. "v1.2.3") actually matches Cargo.toml's package version. A mismatched tag would still build, push, and attest a full release -- the registry tag would just disagree with what the binary and SBOM internally report as their own version, discovered only after the fact (if at all). Add a verify-version job that runs before the (expensive, ~11-16 min per arch) build job and fails immediately with a clear message on a mismatch, instead of burning CI time on a release that has to be thrown away anyway. build now depends on it via needs:. Extracts the version with a small awk script scoped to the [package] section specifically (not a bare "version = " grep), since dependency entries can also contain "version = ..." fields -- scoping to [package] means those can never cause a false match regardless of where they appear in the file. Verified against the current Cargo.toml, both the matching and mismatching cases. cargo metadata would also work, but this repo pins an exact Rust toolchain via rust-toolchain.toml, so running any `cargo` subcommand here would make rustup download and install that whole toolchain first, just to read one string -- not worth it for what should be an near-instant pre-flight check.
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.
Follow-up from the release-process review.
Nothing verified that the git tag triggering a release (e.g. `v1.2.3`) actually matches `Cargo.toml`'s package version. A mismatched tag would still build, push, and attest a full release -- the registry tag would just disagree with what the binary and SBOM internally report as their own version, discovered only after the fact (if at all).
Adds a `verify-version` job that runs before the expensive (~11-16 min per arch) `build` job and fails immediately with a clear error message on a mismatch, instead of burning CI time on a release that would have to be thrown away anyway. `build` now `needs: [verify-version]`.
Extracts the version with a small `awk` script scoped specifically to the `[package]` section, not a bare `version = ` grep -- dependency entries also contain `version = ...` fields, so scoping to `[package]` means those can never cause a false match regardless of where they appear in the file. Verified against the current `Cargo.toml`, both the matching and mismatching cases.
(`cargo metadata` would also work, but this repo pins an exact Rust toolchain via `rust-toolchain.toml`, so running any `cargo` subcommand here would make rustup download and install that whole toolchain first just to read one string -- not worth it for what should be a near-instant pre-flight check.)
🤖 Generated with Claude Code