Skip to content

ci: automate releases via release-please + PR title lint#59

Merged
DataGomes merged 1 commit into
mainfrom
feat/release-please-automation
May 17, 2026
Merged

ci: automate releases via release-please + PR title lint#59
DataGomes merged 1 commit into
mainfrom
feat/release-please-automation

Conversation

@DataGomes
Copy link
Copy Markdown
Contributor

Summary

Replaces the manual "remember to run make release" flow with two GitHub Actions that together make releases impossible to forget or mislabel:

  • release-please — watches main; when unreleased `feat:` / `fix:` commits exist, opens a "Release PR" with auto-computed version + auto-generated CHANGELOG. Merging that PR creates the `v*` tag → existing `publish.yml` ships to PyPI.
  • PR title lint — blocks PR merges whose titles don't follow Conventional Commits (`feat: ...`, `fix: ...`, etc.).

Why

This session alone surfaced the "remember to release" failure mode multiple times. After merging PR #54, PR #55, PR #56 we kept needing to manually decide whether and how to release. With release-please, you can't forget — there's a visible Release PR on the repo asking to be merged.

What's in this PR

File Purpose
`.github/workflows/release-please.yml` Runs the bot on push to main. ~23 lines.
`.github/workflows/lint-pr-title.yml` Lints PR titles via `amannn/action-semantic-pull-request`. ~38 lines.
`release-please-config.json` Tells release-please: single-package, release-type=simple, tag format `vX.Y.Z`, which commit types appear in CHANGELOG.
`.release-please-manifest.json` Tracks current released version (0.3.5) so the bot picks up from where we are.
`AGENTS.md` Documents the new flow (PR with conventional title → merge → bot opens Release PR → merge Release PR → published).

Tradeoffs

  • The setuptools-scm migration in build: derive version from git tags via setuptools-scm #56 was the prerequisite — release-please uses `release-type: simple` because it doesn't need to bump any source file. The version is derived from the tag at build time.
  • `make release` stays as a manual escape hatch for urgent out-of-band releases.
  • No breaking changes to the existing publish flow — `publish.yml` is unchanged. The bot just creates the tag instead of you.

After merge

Two follow-up steps for you to do manually (one-time):

  1. Enable branch protection on `main` → `Settings → Branches → Add rule` → require the `Lint PR title` check to pass before merging.
  2. Enable "Automatically delete head branches" on `Settings → General → Pull Requests` so merged branches are cleaned up automatically.

Then the next PR you open with a `feat:` or `fix:` title will demonstrate the new flow end-to-end.

Test plan

  • All files validate as syntactically correct (YAML / JSON)
  • release-please config schema URL resolves; manifest file is valid JSON
  • Post-merge: on the next `feat:` / `fix:` PR merge, verify release-please opens a Release PR with the correct version
  • Post-merge: verify the Lint PR title check appears on PRs and fails on unprefixed titles

Replaces the manual "remember to run make release" flow with two
GitHub Actions that together guarantee releases can't be forgotten or
mislabeled:

- release-please.yml watches main; whenever there are unreleased
  commits with conventional-commit prefixes, it opens (or updates) a
  "Release PR" with auto-computed version + auto-generated CHANGELOG.
  Merging that PR creates the v* tag, which publish.yml already
  consumes to ship to PyPI. The version bump is deterministic from
  semver rules on the commit prefixes (feat = minor, fix = patch,
  BREAKING CHANGE = major), so it can't be picked wrong.
- lint-pr-title.yml runs amannn/action-semantic-pull-request against
  every PR title. Titles without a conventional prefix get a red
  check; combined with branch protection (enable later in repo
  settings → Branches), this blocks merging until the title is fixed.
  Important specifically because release-please reads PR titles under
  squash-merge, and a missing prefix would silently miss a release.

The setuptools-scm migration from PR #56 was the prerequisite — with
the version derived from tags rather than a source field,
release-please doesn't need to edit any source files (uses
release-type: simple). The manifest file tracks the current released
version (0.3.5) so the bot's first run picks up from where we are.

`make release` and friends stay as a manual escape hatch for the rare
case where the release-please flow can't be used (e.g. urgent security
fix that shouldn't wait for the normal Release PR cycle). AGENTS.md
updated to describe the new flow.

After merge:
- The next PR with a `feat:` or `fix:` will trigger a Release PR
- Enable branch protection on main → require lint-pr-title check
- Stop running make release; let the bot do it
@DataGomes DataGomes merged commit 6cc51a8 into main May 17, 2026
5 checks passed
@DataGomes DataGomes deleted the feat/release-please-automation branch May 17, 2026 23:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant