Auto-publish releases at the end of the release workflow#61
Merged
Conversation
The release workflow created a draft GitHub Release and left publishing to a human. Add a final step that flips the draft to published so a tagged release goes live without manual intervention. The release is still created as a draft first, so GitHub generates its notes and attaches every asset to a fully-formed release before it is visible; the new `gh release edit --draft=false` step then publishes it. A consumer never sees a release with missing notes or half its assets, and a `workflow_dispatch` dry run still skips publishing. Update the release summary and the AGENTS.md and CONTRIBUTING.md runbooks to describe the release as auto-published rather than a draft awaiting a human. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Bastion reviewPassed. All 3 gate(s) passed. 4 reviewer(s) ran, 75s, 696065 in / 10240 out / 511360 cached tokens.
Posted by Bastion. Full transcripts are attached to the workflow run as an artifact. These checks were posted under the shared GitHub Actions app, so with other workflows on the commit they can cluster under one of those; set up a dedicated app to give them their own group. |
Address the Bastion review on the release-workflow change: - prose-anti-slop (blocking): recast the literal `--` dashes in the edited header comment as a parenthetical aside, matching the repo's no-dash prose rule. - shell-script-footguns (advisory): give the new Publish step and the rewritten release-summary step an explicit `shell: bash` with `set -euo pipefail`, so they fail closed rather than relying on the runner's implicit `-e`-only bash. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.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.
Why
The release workflow built the platform matrix, created a draft GitHub Release, and then left publishing to a human. That manual step is the only thing standing between pushing a
vX.Y.Ztag and a live release, so it may as well be automated.What changed
Publish GitHub releasestep to.github/workflows/release.ymlthat runsgh release edit "$TAG" --draft=false, flipping the release live at the end of the workflow..tar.gzarchives pluschecksums.txt) to a fully-formed release before it is visible. Only then does the publish step flip it, so a consumer never catches a release with missing notes or half its assets.if: ${{ !inputs.dry_run }}guard, so aworkflow_dispatchdry run still builds and packages without publishing.Write release summarystep to report the release as published and link to the release tag, dropping the old "review the draft, publish when ready" next-steps list.AGENTS.mdandCONTRIBUTING.mdto describe the release as auto-published rather than a draft awaiting a human.The
--prerelease/--latestselection is unchanged, so a pre-release tag (v0.2.0-rc.1) still publishes as a prerelease. The release job already carriespermissions: contents: writeandGH_TOKEN: ${{ github.token }}, which coversgh release edit, so no permissions change was needed.Testing
nudge check(clean: 64 files, no Unicode dashes).actionlintis not installed on this machine, so the workflow YAML was not machine-linted. The change is an added step plus a--draftto--draft=falseedit mirroring the existingghusage in the same job.This only touches the release workflow and its docs, which are not a downstream user surface, so per AGENTS.md the blast radius is limited to Bastion's own CI.
Schema or governance impact
None. No changes to the reviewer schema, the verdict/event schema, local/GitHub surface parity, or the governance model.