Merge pull request #59 from awslabs/feat/release-please-automation

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

Author: DataGomes

.github/workflows/lint-pr-title.yml

@@ -0,0 +1,38 @@
+name: Lint PR title
+
+# Rejects PR titles that don't follow Conventional Commits format. The
+# title is what release-please reads (under squash-merge) to compute the
+# next version bump, so a wrong/missing prefix would silently miss a
+# release. This check turns that silent failure into a visible block.
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize, reopened]
+
+permissions:
+  pull-requests: read
+
+jobs:
+  lint:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          types: |
+            feat
+            fix
+            docs
+            chore
+            refactor
+            test
+            build
+            ci
+            perf
+            style
+            revert
+          requireScope: false
+          # Subject can be lowercase (matches existing repo convention).
+          # No regex constraint on subject content.
+          validateSingleCommit: false

.github/workflows/release-please.yml

@@ -0,0 +1,23 @@
+name: Release Please
+
+# Watches main and opens (or updates) a "Release PR" whenever there are
+# unreleased commits with conventional-commit prefixes (feat:, fix:, etc.).
+# Merging that Release PR creates a vX.Y.Z tag, which the existing
+# publish.yml workflow consumes to build and upload to PyPI.
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: googleapis/release-please-action@v4
+        with:
+          config-file: release-please-config.json
+          manifest-file: .release-please-manifest.json

.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "0.3.5"
+}

AGENTS.md

@@ -25,24 +25,36 @@ Update both files:
 
 ## Releasing
 
-The version lives in git tags. `pyproject.toml` has no `version` field —
-`setuptools-scm` derives it from the latest `v*` tag at build time.
-
-After merging a PR with user-visible changes, publish to PyPI from main:
-
-```bash
-git checkout main && git pull
-make release         # patch bump (0.3.4 → 0.3.5) — bug fixes only
-make release-minor   # minor bump (0.3.4 → 0.4.0) — new features, backwards-compat
-make release-major   # major bump (0.3.4 → 1.0.0) — breaking changes
-```
-
-Each target reads the latest tag, computes the next, tags it, and pushes
-the tag. No source file is bumped; no "Release vX.Y.Z" commits land on
-main. The `publish.yml` workflow runs on tag push and publishes to PyPI
-via trusted publisher (setuptools-scm bakes the tag's version into the
-built artifacts).
-
-Pick the bump from semver: new public API = minor, only bug fixes =
-patch, backwards-incompatible = major. Don't tag manually outside the
-Makefile — the targets enforce clean tree + on main + up-to-date.
+Releases are automated by [release-please](https://github.com/googleapis/release-please).
+You do not run `make release` in normal flow — the bot does it for you.
+
+**Normal flow:**
+
+1. Open a PR with a Conventional Commits title (`feat: ...`, `fix: ...`, `docs: ...`).
+   The PR title lint blocks merge if the prefix is missing.
+2. Merge the PR to main.
+3. `release-please` reads commits since the last release tag and, if any
+   `feat:` / `fix:` are present, opens (or updates) a "Release PR"
+   titled `chore(main): release X.Y.Z` with an auto-generated
+   `CHANGELOG.md` entry and a new version computed via semver:
+   - `feat:` → minor bump
+   - `fix:` / `perf:` → patch bump
+   - any `BREAKING CHANGE:` footer → major bump
+4. Merge the Release PR when you're ready to ship. The bot creates the
+   `vX.Y.Z` tag, which triggers `publish.yml` → build → PyPI upload.
+
+The version itself lives in git tags. `pyproject.toml` has no `version`
+field — `setuptools-scm` derives it from the tag at build time. The
+`.release-please-manifest.json` file tracks the current released
+version for release-please's own bookkeeping; you don't edit it by hand.
+
+**Manual escape hatch (rare):**
+
+If you ever need to release out of band — e.g. a security fix that
+shouldn't wait for the next Release PR cycle — `make release` /
+`make release-minor` / `make release-major` still work. They read the
+latest tag, compute the next version, tag, and push. Use only when the
+release-please flow can't be used.
+
+Don't tag manually outside the Makefile — the targets enforce clean
+tree + on main + up-to-date.

release-please-config.json

@@ -0,0 +1,27 @@
+{
+  "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json",
+  "packages": {
+    ".": {
+      "release-type": "simple",
+      "bump-minor-pre-major": false,
+      "bump-patch-for-minor-pre-major": false,
+      "draft": false,
+      "prerelease": false,
+      "include-component-in-tag": false,
+      "include-v-in-tag": true,
+      "changelog-sections": [
+        { "type": "feat", "section": "Features" },
+        { "type": "fix", "section": "Bug Fixes" },
+        { "type": "perf", "section": "Performance" },
+        { "type": "revert", "section": "Reverts" },
+        { "type": "docs", "section": "Documentation", "hidden": false },
+        { "type": "refactor", "section": "Refactoring" },
+        { "type": "build", "section": "Build System", "hidden": true },
+        { "type": "ci", "section": "CI", "hidden": true },
+        { "type": "chore", "section": "Chores", "hidden": true },
+        { "type": "test", "section": "Tests", "hidden": true },
+        { "type": "style", "section": "Style", "hidden": true }
+      ]
+    }
+  }
+}