ci: draft release until assets upload, then publish atomically#282
Merged
Conversation
Signed-off-by: Logan Nguyen <lg.131.dev@gmail.com>
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.
Overview
Closes the window where
curl -fsSL https://thuki.app/install.sh | shreturns 404 right after a release is cut.The install script downloads from
https://github.com/quiet-node/thuki/releases/latest/download/Thuki.dmg, which follows GitHub's "latest release" pointer. release-please publishes the GitHub Release the moment the release PR merges (a fast ubuntu job), but the DMG, its signature, andlatest.jsonare built and uploaded minutes later by the macOS job. During that gap,releases/latestalready points at the new tag while its assets do not exist yet, so the installer (and the in-app auto-updater, which readslatest.jsonthe same way) 404s.What changed
release-please-config.json: create the GitHub Release as a draft (draft: true) and create its git tag immediately (force-tag-creation: true)..github/workflows/release-please.yml: add a finalPublish releasestep that runsgh release edit "$TAG" --draft=falseafter the asset upload.How it works
GitHub excludes draft (and prerelease) releases from
releases/latest, the public API, and thelatest/downloadasset redirect. So while the macOS job builds, the new release stays hidden andreleases/latestkeeps serving the previous good version. Only once every asset is uploaded does the publish step flip the draft to public, making go-live atomic: the release becomes "latest" and its DMG is already in place.force-tag-creationexists because GitHub does not create a git tag for a draft release until it is published. Without it, an abandoned draft (a failed build that never publishes) would leave release-please unable to find the previous tag on the next run, producing a changelog spanning the entire history. Both options are supported by the release-please version bundled in the pinned action (v5.0.0shipsrelease-please ^17.6.0; the options landed in17.2.0).The publish step intentionally has no
if: always(). A failed build or upload leaves an unpublished draft andreleases/lateststays on the last good version; a re-run targets the existing draft.The
nightly-release.ymlworkflow is unaffected: it already publishes with--prerelease, which is likewise excluded fromreleases/latest.Testing
release-please-config.jsonvalidated as JSON;release-please.ymlvalidated as YAML.draftandforce-tag-creationconfirmed present in thev17.6.0config schema (the version bundled by the pinnedrelease-please-action@v5.0.0).releases/latestnever pointing at an assetless release.Note
This PR is typed
ci:so it does not trigger a release-please version bump; there is no associated release to merge.