ci: attach the release binaries to the GitHub Release (release-v2.0.18) - #209
Conversation
Claude review status
✅ Review clean Last reviewed: New this round: 0 finding(s), 0 question(s) · Resolved this round: 0 · Open questions: 0 |
on-release.yml builds stateless-validator and debug-trace-server at the released tag and attaches them, with SHA256SUMS, to the Release page via the shared release-assets action. A workflow_dispatch on a tag ref with dry_run=true rehearses the build and checksums without attaching. The Artifact Registry archive stays in release.yaml / release-tracing.yaml. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013eLFMaDpEwgDzyDBzCQzLH (cherry picked from commit 88d5ca6)
![mega-maxwell[bot]](https://avatars.githubusercontent.com/u/138558126?s=60&v=4){kind=small}
There was a problem hiding this comment.
❓ Review complete — 1 open question(s)
Reviewed head ec93fd25.
Reviewed the new .github/workflows/on-release.yml, which builds and attaches the two release binaries to the GitHub Release on publish (and on-demand dispatch).
Open questions — answer them in a reply on this PR. Each one is marked answered here once a later review round confirms the answer, so this list stays current:
✅ **Answered** — Troublor confirmed release-assets@main's Checksums step runs sha256sum on the listed files and its Attach step uploads SHA256SUMS with --clobber, matching the header comment's promise.
- Does the megaeth-labs/.github/.github/actions/release-assets@main composite action itself compute and upload the SHA256SUMS file promised by the header comment at .github/workflows/on-release.yml:4 and the dispatch input description at line 19? The workflow passes only the two raw binary paths to it (lines 68-70) and runs no local sha256sum step, so a checksum ends up on the Release only if the composite action generates one.
- Why it matters: If the composite action does not emit SHA256SUMS, the Release ships binaries with no checksum manifest, silently breaking the promise the header comment makes to downstream verifiers; nothing in this workflow would surface that gap.
- How to verify: Open megaeth-labs/.github/.github/actions/release-assets/action.yml at the current main and confirm it computes and uploads SHA256SUMS alongside the files: input; if not, add an explicit sha256sum step here (or fix the composite action) so the Release matches the comment.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Review follow-ups on the on-release workflow: - Verify the built stateless-validator reports the tag's version (it carries a clap version; the old comment claimed otherwise) — warning on a dry run, hard stop on a release, as mega-evme does. Run debug-trace-server --help so a binary that cannot load fails the step instead of printing "<no --version>" and shipping. - Add a per-tag concurrency group (cancel-in-progress: false) so a release run and a same-tag dispatch cannot race on the --clobber asset upload. - Document that the file must exist on the release branch: a release event resolves the workflow at the tagged commit, so a branch cut before this file landed needs it cherry-picked first. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> (cherry picked from commit 89aedf4)
|
Answer to the open question: yes, |
1 participant
Cherry-pick of #207 onto
release-v2.0.18, so thev2.0.18Release gets its binaries:on-release.ymlruns from the tag, and the release branch was cut before #207 existed.Order: merge #207 (main) → merge this → I re-run
release-settle(the existing settle PR #208 goes stale by design — the tip moves — and gets refreshed) → merge the settle PR → tag + Release + assets.🤖 Generated with Claude Code