Skip to content

ci: guard releases against missing binary assets#13

Open
PLNech wants to merge 1 commit intomainfrom
fix/release-asset-guard
Open

ci: guard releases against missing binary assets#13
PLNech wants to merge 1 commit intomainfrom
fix/release-asset-guard

Conversation

@PLNech
Copy link
Copy Markdown
Member

@PLNech PLNech commented Apr 20, 2026

Summary

Two recent release tags (v0.33.0-rc.54.algolia.1, v0.34.2-algolia.1) shipped with zero binary assets, so GitHub's /releases/latest points at a tag whose .tar.gz downloads 404. A colleague just hit this via the documented curl | sh install.

Root cause, twofold:

  • CD never fired on this fork. cd.yml triggers on [develop, master], but our default branch is main. Release-please → build-release never ran.
  • No release-time verification. A manual gh release create (or a partial run) can leave a tag with zero assets, and nothing catches it.

Changes

  • cd.yml: add main to the push-trigger branch list, and wire the release-please + pre-release dispatch guards to treat main as the stable lane.
  • release.yml: add two steps after Upload Release Assets:
    • Verify release assets — assert every required target binary and checksums.txt is present on the tag; fail otherwise with a clear error.
    • Smoke test release download — pull the Linux musl tarball from the exact tag URL and run rtk --version. Uses the tag (not /releases/latest) so prereleases are covered.

With these, a release where any builder silently dropped its artifact fails the workflow instead of landing broken.

Test plan

  • Merge, cut a prerelease on develop, confirm the verify + smoke steps execute and pass.
  • (Negative) Temporarily remove one target from the build matrix, confirm the verify step fails with a clear missing-asset error.

Two recent release tags (v0.33.0-rc.54.algolia.1 and v0.34.2-algolia.1)
shipped with zero binary assets, making the GitHub /releases/latest
response resolve to a tag that install.sh cannot download (404). The CD
workflow also never fired for these because it only triggered on develop
and master, but our default branch is main.

- cd.yml: add main to the push-trigger branch list so release-please and
  build-release run automatically on this fork.
- release.yml: after Upload Release Assets, verify every required binary
  and checksums.txt actually landed on the tag, and smoke-test the Linux
  musl tarball end-to-end by downloading it and running rtk --version.
  Either check failing now fails the workflow, surfacing the regression
  at release time instead of in user terminals.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant