ci: automated releases via release-please (modeled on R2X) - #31
Open
micahpw wants to merge 1 commit into
Open
Conversation
Adopts the same release-please pattern used by NatLabRockies/R2X: merges to main with Conventional Commit messages are what drive releases now, instead of a human running `git tag` by hand. ## Flow 1. Every push to main: release-please parses commits since the last release and keeps a standing "chore: release vX.Y.Z" PR open, auto-updating docs/source/CHANGELOG.md as more commits land. 2. The moment that PR is merged, release-please creates the tag + GitHub Release automatically. 3. release.yml's build/publish-pypi jobs then run exactly as before (uv build, PyPI trusted publishing), gated on release_created instead of a tag-push event. workflow_dispatch remains as a manual escape hatch (publish-pypi's new skip-existing: true makes re-runs safe). ## Adapted from R2X, not copied - release-type "simple", not "python": GAT's pyproject.toml has `dynamic = ["version"]` — setuptools_scm derives the version entirely from git tags at build time, so there's no static `version = "x.y.z"` string anywhere for release-please to edit. "simple" only manages the changelog + tag/release, which is exactly what's needed here. - bump-minor-pre-major: false, bump-patch-for-minor-pre-major: true — R2X is already past 1.0 so this doesn't apply to their config, but it matters for GAT: without it, any feat: commit could auto-advance to v0.2.0, which is meant to stay a deliberate, human-triggered milestone (the H5PLEXOS.jl removal — see the README warning box). With this config, feat/fix land as patch bumps (0.1.0 -> 0.1.1 -> ...) until someone explicitly overrides the next version via release-please's release-as mechanism. - changelog-path points at docs/source/CHANGELOG.md, matching where GAT's changelog actually lives (R2X's is at the repo root). ## Also added - commit-lint.yml — Conventional Commit message + PR title linting (commitizen + amannn/action-semantic-pull-request), matching R2X's commit.yaml. This is what makes release-please's version/changelog computation reliable — an unprefixed commit is silently invisible to it, not an error, so catching the format early matters. Informational only for now (not in the branch-protection required checks), since making it a hard block is a separate decision. - README: one-line Conventional Commits note in Contributing. ## One-time manual note for the first release-please PR The CHANGELOG already has a hand-written "## [v0.1.1] - Unreleased" section (from #29, before this automation existed). release-please's first generated PR will likely add its own auto-generated v0.1.1 section without knowing about that one, since it only tracks state via .release-please-manifest.json (baselined at 0.1.0, the last real tag). Expect to manually reconcile the two sections once, when reviewing that first PR — a one-time cleanup, not an ongoing issue. Co-Authored-By: Claude Opus 5 <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
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.
Adopts NatLabRockies/R2X's release-please pattern — verified by reading their actual
.github/workflows/release.yaml,commit.yaml, and.release-please-config.json, not guessed.Flow going forward
mainwith Conventional Commit messages (feat:,fix:,docs:, ...) are what drive releases — no more manualgit tag.docs/source/CHANGELOG.mdfrom commits since the last release. It updates itself as more commits land.release.yml's existing build/publish-pypi jobs run unchanged (sameuv build, same trusted-publishing PyPI step), just re-gated onrelease_createdinstead of a tag-push event.Two deliberate departures from R2X's config (not oversights)
release-type: "simple", not"python". GAT'spyproject.tomlhasdynamic = ["version"]— setuptools_scm derives the version from git tags at build time, so there's no staticversion = "x.y.z"string anywhere for release-please to bump. "simple" only manages the changelog + tag/release, which is the correct fit.bump-minor-pre-major: false,bump-patch-for-minor-pre-major: true. R2X is already2.1.0so this setting doesn't come up for them. It matters for GAT: without it, anyfeat:commit could auto-advance tov0.2.0— which the README's H5PLEXOS.jl warning box deliberately reserves for the actual removal, not an accidental side effect of an unrelated feature landing. With this set,feat/fixland as patch bumps (0.1.0 → 0.1.1 → ...) until someone explicitly calls a minor bump via release-please'srelease-asoverride.Also included
commit-lint.yml— Conventional Commit + PR-title linting (commitizen +amannn/action-semantic-pull-request), matching R2X'scommit.yaml. This is the prerequisite that makes release-please's version/changelog computation reliable — an unprefixed commit is silently invisible to it, not an error. Informational only for now (not wired into the branch-protection required checks) — flagging that as a separate decision if you want it to hard-block instead.Known one-time cleanup
docs/source/CHANGELOG.mdalready has a hand-written## [v0.1.1] - Unreleasedsection from #29 (written before this automation existed). release-please's manifest is baselined at0.1.0(the last real tag), so its first generated PR will likely add its own auto-generated v0.1.1 section without knowing about the hand-written one. Expect to manually reconcile the two once, reviewing that first PR — not an ongoing problem after that.🤖 Generated with Claude Code