ci(release): smoke-test packaged binaries' --version before attaching#59
ci(release): smoke-test packaged binaries' --version before attaching#59FrozenRaspberry wants to merge 1 commit into
Conversation
The release-binaries job packaged gl, git-remote-gitlawb, and gitlawb-node into the release tarball but never ran them, so a broken artifact could ship. This is the follow-up promised in Gitlawb#30 and the gap noted in OSS-READINESS-AUDIT ("release binaries are not smoke-tested after packaging"), now unblocked by git-remote-gitlawb gaining --version. Run each binary's --version after build and assert the released version string is present. Skipped for aarch64-unknown-linux-musl, which is cross-compiled and can't execute on the x86_64 runner. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughA new "Smoke test binaries" step is added to the release workflow's "Build & Attach Binaries" job. After building each target, the step executes each binary with ChangesBinary Smoke Test in Release Workflow
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
What
Smoke-tests the packaged release binaries (
gl,git-remote-gitlawb,gitlawb-node) by running each one's--versionin therelease-binariesjob before they're attached to the release.Why
This is the follow-up I flagged in #30 ("wiring
--versionchecks for all three binaries intorelease.yml"), now unblocked bygit-remote-gitlawbgaining--versionin that PR.docs/OSS-READINESS-AUDIT.mdnotes:The
release-binariesjob builds and tars up all three binaries but never executes them, so a broken artifact (bad build, missing runtime symbol) would ship to a release unnoticed. Thedockerjob only smoke-tests the image'sgitlawb-node --version, not the standalone binaries in the tarball.How
Build, a newSmoke test binariesstep runs--versionon each of the three binaries and asserts the released version string is present in the output (they print<name> <version>, matching the convention feat(git-remote-gitlawb): add --version and --help flags #30 alignedgit-remote-gitlawbto).::error::annotation.aarch64-unknown-linux-musl, which is cross-compiled and can't execute on the x86_64 runner. The other three targets (x86_64-linux-musl,x86_64-apple-darwin,aarch64-apple-darwin) run natively on their matrix runners.No protocol, API, or release-artifact changes — purely an added verification gate.
Testing
release.ymlvalidated as well-formed YAML.main:gl --version→gl 0.3.9git-remote-gitlawb --version→git-remote-gitlawb 0.3.9gitlawb-node --version→gitlawb-node 0.3.9Summary by CodeRabbit