ci(release): cut a GitHub Release once npm + Docker artifacts exist - #49
Merged
Conversation
The releases page currently shows two orphan tags cut on 2026-08-26 (v0.19.1, v0.19.2) while npm ships 0.40.1 — it understates the project by 21 minor versions. That reads as "barely released" to anyone assessing maturity, and after a listing lands, curated lists like awesome-selfhosted read `current_release` from that page and flag live projects as unmaintained. This is a third workflow rather than a step at the end of publish-npm.yml because `Publish npm` and `Docker` are independent workflows with different path filters — a commit under apps/busabase-cli/** runs only the first. Appending a release to either would announce artifacts that do not exist yet. Instead it runs after EITHER completes and gates on the artifacts themselves: the release is created only once busabase@<version> is on npm AND the matching Docker Hub tag exists. Whichever workflow finishes last finds both and cuts the release; the earlier one no-ops. No barrier, so a single-workflow commit still releases. Idempotent like the rest of this repo's publishing: an existing release exits 0. Tags the commit the triggering run actually built, not the branch tip. Nothing is backfilled — GitHub cannot backdate published_at, so backfilled releases would all claim today's date and misrepresent the history more than their absence does. Co-Authored-By: Claude Opus 5 <[email protected]>
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
1 participant
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.
The problem
The releases page shows two orphan tags, both cut 2026-08-26 (
v0.19.1,v0.19.2), while npm already ships0.40.1. It understates the project by 21 minor versions.Two costs:
awesome-selfhostedreadcurrent_releasefrom that page and theircheck-unmaintained-projectsjob files issues against stale entries. A live project would be flagged as abandoned.Why a third workflow, not a step in
publish-npm.ymlPublish npmandDockerare independent workflows with different path filters. A commit underapps/busabase-cli/**runs only the first; a commit underapps/busabase/**runs both. Tacking a release onto either one would cut a release announcing artifacts that do not exist yet.So this runs after either completes and gates on the artifacts themselves:
npm view busabase@<version>must succeed, andhub.docker.com/v2/repositories/busabase/busabase/tags/<version>must return 200.Whichever workflow finishes last finds both present and cuts the release; the earlier one finds one missing and exits 0. No barrier — so a commit that only triggers one of the two still releases, instead of deadlocking waiting for a run that never happens.
Properties
publish-npm.yml'snpm view ... && skipphilosophy. Re-running is always safe.workflow_run,github.shais the branch tip, which may have moved; it usesworkflow_run.head_sha.workflow_runalso fires on failure.workflow_dispatchfor manual runs and for the first one.Release body
Install commands, a table of the five published packages with their versions, the multi-arch image tags on Docker Hub and GHCR, then GitHub's own "What's Changed" from the PRs since the previous release (via the
releases/generate-notesAPI — verified to produce clean output on this repo's PR history).Not backfilled, deliberately
GitHub cannot backdate
published_at. Backfilling the ~20 missing versions would create twenty releases all claiming today's date, which misrepresents the history more than their absence does. The next release will jump fromv0.19.2tov0.40.x— odd-looking, but true.🤖 Generated with Claude Code