gh-release-push command
Apply this command workflow. Treat any text after its invocation as the command input.
Tag and push a release from green main.
Precondition — main branch, no worktree
A release tags a green main. It produces no code change and never runs on a
worktree branch. Stop immediately if the current branch is not main:
branch=$(git branch --show-current)
[ "$branch" = "main" ] || { echo "Release must run on main (currently on '$branch'). Abort."; exit 1; }
Steps
Run the repo's full release gate set. Where mage -l lists targets, mage tag is the entry point — it re-runs every declared gate (audit, test,
integration, conformance, and anything else the repo registers) and creates
the tag on success. Where no mage target exists, run the repo's own check
and test commands.
If any gate fails, stop the release. Do not fix, retry, or waive the
failure inline. File a PRD-backed bug via /gh-issue-push, implement and
merge the fix through the normal issue/PR flow, then re-run the release
against the now-green main.
Record the previous release tag: git describe --tags --abbrev=0 (or empty
if no tags exist yet).
If mage tag already created the tag, capture its name from the output or
via git describe --tags --abbrev=0. Otherwise create a v0.YYYYMMDD.N
tag manually.
Generate a changelog: git log --oneline <previous-tag>..<new-tag> (or all
commits if no previous tag). Summarize changes grouped by category
(features, fixes, docs, etc.).
Replace the lightweight tag with an annotated tag carrying the summary:
git tag -d <new-tag> && git tag -a <new-tag> -m "<summary>". Print the
summary.
Push the branch and tags to origin. If git remote | grep -q release
succeeds, also push to release.
git push origin main
git push origin --tags
# if release remote exists:
git push release main
git push release --tags
If the repo is a Go module, resolve the module path with go list -m and
run go get <module>@<new-tag> to warm the Go module proxy. Report errors
but do not fail the release.
Report the tag name, branch, which remotes received the push, and the
change summary.
1---2name: gh-release-push3description: Tag and push a release from green `main`.4---56# gh-release-push command78Apply this command workflow. Treat any text after its invocation as the command input.910Tag and push a release from green `main`.1112## Precondition — main branch, no worktree1314A release tags a green `main`. It produces no code change and never runs on a15worktree branch. Stop immediately if the current branch is not `main`:1617```bash18branch=$(git branch --show-current)19[ "$branch" = "main" ] || { echo "Release must run on main (currently on '$branch'). Abort."; exit 1; }20```2122## Steps23241. Run the repo's full release gate set. Where `mage -l` lists targets, `mage25 tag` is the entry point — it re-runs every declared gate (audit, test,26 integration, conformance, and anything else the repo registers) and creates27 the tag on success. Where no mage target exists, run the repo's own check28 and test commands.2930 If any gate fails, **stop the release**. Do not fix, retry, or waive the31 failure inline. File a PRD-backed bug via `/gh-issue-push`, implement and32 merge the fix through the normal issue/PR flow, then re-run the release33 against the now-green `main`.34352. Record the previous release tag: `git describe --tags --abbrev=0` (or empty36 if no tags exist yet).37383. If `mage tag` already created the tag, capture its name from the output or39 via `git describe --tags --abbrev=0`. Otherwise create a `v0.YYYYMMDD.N`40 tag manually.41424. Generate a changelog: `git log --oneline <previous-tag>..<new-tag>` (or all43 commits if no previous tag). Summarize changes grouped by category44 (features, fixes, docs, etc.).45465. Replace the lightweight tag with an annotated tag carrying the summary:47 `git tag -d <new-tag> && git tag -a <new-tag> -m "<summary>"`. Print the48 summary.49506. Push the branch and tags to `origin`. If `git remote | grep -q release`51 succeeds, also push to `release`.5253 ```bash54 git push origin main55 git push origin --tags56 # if release remote exists:57 git push release main58 git push release --tags59 ```60617. If the repo is a Go module, resolve the module path with `go list -m` and62 run `go get <module>@<new-tag>` to warm the Go module proxy. Report errors63 but do not fail the release.64658. Report the tag name, branch, which remotes received the push, and the66 change summary.
petar-djukic