fix(release): draft releases until assets are attached - #201
Open
Swaagie wants to merge 3 commits into
Open
Conversation
release-please published each GitHub Release as non-draft immediately on merge, so releases/latest/download/... began redirecting to the new tag before the build+attach jobs uploaded any assets. During that multi-minute window every asset URL 404'd — including install.sh itself, which the install one-liner fetches — so a fresh install could fail. Create the release as a draft (release-please 'draft: true') and publish it (gh release edit --draft=false --latest) only after all assets are attached. A draft is never served as 'latest', so the pointer stays on the previous, fully-populated release until the new one is complete. If build/attach fail, the release stays a draft and is never exposed to users.
Contributor
There was a problem hiding this comment.
Pull request overview
This PR addresses a release-time race condition where releases/latest/download/... can temporarily point at a new tag before its assets are uploaded, causing install scripts (and other assets) to 404 during the build/attach window. It does so by ensuring GitHub Releases are created as drafts until all assets are uploaded, then publishing and marking the release as latest only at the end of the workflow.
Changes:
- Configure
release-pleaseto create therustpackage GitHub Release as a draft. - Update the release workflow to publish (
--draft=false) and mark--latestonly after uploading all release assets.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| release-please-config.json | Sets draft: true for the rust release so new releases aren’t publicly “latest” until explicitly published. |
| .github/workflows/release.yml | Publishes the release after assets upload to avoid latest/download redirecting to an incomplete release. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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.
Summary
Fixes a race where
curl -fsSL https://github.com/godaddy/cli/releases/latest/download/install.sh | bashreturns 404 during a release.release-pleasepublished each GitHub Release as non-draft immediately on merge, soreleases/latest/download/…began redirecting to the new tag before thebuild+attachjobs finished. For that multi-minute window, every asset URL 404'd — includinginstall.shitself, which the one-liner fetches — so a fresh install could hard-fail. This was hit live during thev0.2.4release.Fix
release-please-config.json— set"draft": trueon therustpackage so each Release is created as a draft..github/workflows/release.yml— aftergh release upload …, publish withgh release edit "$TAG" --draft=false --latest, i.e. only once all assets are attached.How draft releases close the race
Per GitHub's docs on creating a release:
A draft release is not public and is never served as
latest— GitHub only resolvesreleases/latest/download/…to published releases. So while the new draft is being built and its assets uploaded, thelatestpointer keeps resolving to the previous, fully-populated release (a brief "installs previous version", never a 404). Publishing with--draft=false --latestthen flips the pointer atomically to a release that is already complete.Fail-safe bonus: if
build/attachfail, the release stays a draft and is never exposed to users. Re-run the upload/publish via the existingpublish_onlyworkflow_dispatchinput.Test plan
release-please-config.jsonis valid JSON;release.ymlparses as YAML.build, flips to Latest only afterattach, and the install one-liner never 404s mid-release.