Extract linux-x64 archive by exact name in release-notes step (unblocks v0.37 release)#345
Merged
Merged
Conversation
…release-notes step The step added in #314 globbed artifacts/basilisk-*-linux-x64.tar.gz, but the build matrix names archives by target triple (basilisk-x86_64-unknown-linux-gnu.tar.gz), so the glob matched nothing. The step had never executed before v0.37.1 — the v0.36.0/v0.37.0 runs failed earlier — and it broke the first release run that reached it.
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.
TLDR
Fixes the last blocker in the v0.37.1 release run: the release-notes step extracted the linux-x64 archive with a glob (
basilisk-*-linux-x64.tar.gz) that never matches the build matrix's target-triple archive name (basilisk-x86_64-unknown-linux-gnu.tar.gz).What Was Changed or Deleted?
One line in
.github/workflows/release.yml("Generate release-notes component block", added in #314): extractartifacts/basilisk-x86_64-unknown-linux-gnu.tar.gzby its exact name, matching every other archive reference in the workflow. The step had never executed before — the v0.36.0/v0.37.0 runs died earlier (fixed in #344) — so v0.37.1 was its first run, and it failed with "Cannot open: No such file or directory". All build, attribution, and both conformance-gate jobs in the v0.37.1 run passed; only this publish step failed.How Do The Automated Tests Prove It Works?
archive:value for linux-x64 in this same workflow's build matrix, and the identical exact-name convention the Homebrew/Scoop jobs already use for the same files.python3 scripts/gen_release_notes.py ./target/release/basilisk v0.37.1runs clean locally against a release-built binary, so the step's remaining commands are sound (the notes block itself is drift-tested bycrates/basilisk-cli/tests/e2e_release_notes_block.rs).Breaking Changes