ci: auto-tag releases from the CHANGELOG — merging this PR cuts v1.81.6#46
Merged
Merged
Conversation
Merging a release PR now ships the release with no manual tag push: on every push to main, autotag.yml reads the newest '## vX.Y.Z' heading from internal/ui/assets/CHANGELOG.md (the same source release.yml renders the release notes from), tags the pushed commit if that version is untagged, and dispatches the Release pipeline on the tag ref. The explicit dispatch exists because refs pushed with a workflow's own GITHUB_TOKEN never trigger other workflows (GitHub's recursion guard) — a pushed tag alone would sit unbuilt. workflow_dispatch on the tag ref sets github.ref to refs/tags/<ver>, satisfying release.yml's publish gate and --verify-tag. Manual tag pushes keep working unchanged; the workflow is idempotent (existing tag = no-op). Merging this commit itself tags v1.81.6 (the current CHANGELOG head, still untagged) and cuts that release.
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.
What this does
Adds
.github/workflows/autotag.yml: on every push tomainit reads the newest## vX.Y.Zheading frominternal/ui/assets/CHANGELOG.md(the exact filerelease.ymlalready renders release notes from), and if that version has no tag yet it:Releasing becomes: add the new CHANGELOG section in your PR (already the convention), merge, done. No manual
git push origin vX.Y.Zever again.Merging this PR ships v1.81.6
The CHANGELOG's current head is
## v1.81.6(the idle-disconnect fix from #45, already onmain) and that tag doesn't exist yet — so the merge of this PR fires the workflow, tagsv1.81.6, and starts the full multi-platform release build automatically. Watch it under Actions → Release; the published notes will be the v1.81.6 CHANGELOG section.Why the explicit dispatch
Tags pushed with a workflow's own
GITHUB_TOKENdeliberately never trigger other workflows (GitHub's recursive-workflow guard), so a pushed tag alone would sit unbuilt. An APIworkflow_dispatchis allowed, and dispatching with--ref <tag>runsrelease.ymlwithgithub.ref = refs/tags/<ver>— exactly what its publish gate (startsWith(github.ref, 'refs/tags/')) andgh release create --verify-tagrequire.Safety properties
mainbetween releases do nothing, and re-runs are always safe.release.ymldirectly; the workflow then just sees the tag exists and exits.v1.82.0-test.1) flows through torelease.yml's existing--prereleasedetection untouched.contents: write(tag push) +actions: write(dispatch) only.Generated by Claude Code