ci: automate releases with release-please#9
Conversation
manuel-alvarez-alvarez
force-pushed
the
ci/release-automation
branch
3 times, most recently
from
b6ad0f9 to
7ddff3f
Compare
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7ddff3fada
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
manuel-alvarez-alvarez
force-pushed
the
ci/release-automation
branch
from
7ddff3f to
3d3c766
Compare
Adds release-please-driven release automation: - release-please-config.json + .release-please-manifest.json drive Python-style version bumps (pre-1.0: feat -> minor, fix -> patch, feat!/BREAKING CHANGE -> minor) from conventional-commit PR titles squash-merged into main. pyproject.toml's version is updated by the Python strategy automatically; src/aiguard/__init__.py is pinned via extra-files (auto-discovery doesn't match the no-separator path) and bumped on the x-release-please-version annotation line. - changelog-sections customizes the generated CHANGELOG with section headers: 🚀 Features, 🐛 Bug Fixes, ⏱️ Performance Improvements, ⏮️ Reverts, 📖 Documentation, ♻️ Code Refactoring. Build, CI, tests, chores, and styles are hidden — none of them move the version, and Dependabot's build(deps)/build(deps-dev) bumps would otherwise clutter release notes. - .github/workflows/release.yml runs release-please on every push to main, maintaining an open PR titled "ci: release X.Y.Z" that bumps the version files and updates CHANGELOG.md. Merging that PR cuts a tag and creates a GitHub Release with auto-generated notes. The job mints a short-lived installation token from a dedicated GitHub App (via actions/create-github-app-token) rather than using the default GITHUB_TOKEN, so the release PR triggers pull_request checks — GITHUB_TOKEN-authored events do not. The App ID and private key are stored as RELEASE_PLEASE_APP_ID and RELEASE_PLEASE_APP_PRIVATE_KEY repo secrets. - .github/workflows/build.yml learns a workflow_call trigger and a release_tag input. When release.yml invokes it after a release is cut, the existing platform build runs and a new step uploads the tarballs and SHA-256 sidecars to the GitHub Release. The tag-push trigger is preserved as a manual recovery path. We invoke build.yml as a reusable workflow rather than relying on tag-push side effects because GITHUB_TOKEN-created tag pushes don't trigger downstream workflows. - CONTRIBUTING.md documents the conventional-commit PR title requirement, the release process, the bump table, and the manual recovery path.
manuel-alvarez-alvarez
force-pushed
the
ci/release-automation
branch
from
3d3c766 to
722bb72
Compare
Address Codex review comment on PR #9: `gh release upload` fails if no Release exists for the tag. The release-please path is fine because release-please creates the Release before the publish job runs, but the manual recovery flow (`git push origin vX.Y.Z`) had no equivalent step and would fail at upload time. The upload step now `gh release view`s the tag and, if absent, runs `gh release create --generate-notes` before uploading. `|| true` tolerates the race where two matrix runners both miss the view and try to create at once — one wins, the other harmlessly fails. The release-please path is unaffected because the view succeeds and the create branch is skipped entirely. CONTRIBUTING.md updated: the manual recovery procedure is now just "push the tag" — no separate "create the Release" step.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 386d1f2cde
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| | `fix:` / `perf:` | patch | `0.1.0 → 0.1.1` | | ||
| | `feat:` | minor | `0.1.0 → 0.2.0` | | ||
| | `feat!:` / `BREAKING CHANGE:` body | minor | `0.1.0 → 0.2.0` | | ||
| | `chore:` / `docs:` / `ci:` / `test:`/ `refactor:` / `style:` | none | no release | |
There was a problem hiding this comment.
The new version-bump table says docs: commits produce “no release”, but this repository is configured with release-type: "python" in release-please-config.json, and release-please’s Python strategy treats docs commits as releasable units. As written, contributors will use docs: expecting no version change and still trigger release PR/version bumps, which makes the documented release contract inaccurate and can cause unexpected releases.
Useful? React with 👍 / 👎.
2 participants
What does this PR do?
Wires up automated releases driven by release-please so that conventional-commit PR titles squash-merged into
mainproduce versioned GitHub Releases with attached platform binaries.After merge,
release.ymlwill open and maintain a long-lived PR titledci: release X.Y.Z. Merging that PR cuts the tag, creates the Release with auto-generated notes, builds the three platform tarballs, and attaches them (plus.sha256sidecars) to the Release — which is whatscripts/install.shalready expects.Files added
release-please-config.json— Python release type,bump-minor-pre-major: true(pre-1.0 keeps majors suppressed),extra-filespinned tosrc/aiguard/__init__.py(auto-discovery would miss the no-separator path), PR title patternci: release \${version}..release-please-manifest.json— bootstrapped at0.1.0..github/workflows/release.yml— runs release-please on push tomain; onrelease_createdinvokesbuild.ymlas a reusable workflow withrelease_tag.Files modified
.github/workflows/build.yml— addsworkflow_callwith optionalrelease_taginput; adds agh release uploadstep guarded so it runs both when invoked byrelease.ymland when av*tag is pushed manually (recovery path). Concurrency rekeyed so a main-branch run doesn't cancel the release-time run.src/aiguard/__init__.py—# x-release-please-versionannotation on the__version__line so the Generic updater catches it.CONTRIBUTING.md— documents the conventional-commits requirement and the release flow.Motivation
Today
build.ymlbuilds artifacts on tag push but never creates a GitHub Release or attaches assets —install.shwon't actually find anything to download until a human cuts the Release by hand. This PR removes that manual step and makes versioning + changelog generation deterministic from PR titles.Why a reusable-workflow call instead of relying on the tag-push trigger?
GITHUB_TOKEN-created tag pushes do not trigger downstream workflows (GitHub safeguard against recursive runs). The reusable-workflow pattern avoids that footgun without requiring a PAT.How was it tested?
python3 -c 'import json; json.load(open(\"release-please-config.json\")); json.load(open(\".release-please-manifest.json\"))'passes.release.ymlrun onmainshould open aci: release 0.2.0PR (or0.1.1— depends on what counts as conventional sincev0.1.0).git tag v0.x.y && git push) still works because the existingpush: tags: ["v*"]trigger is preserved and the upload step'sif:guard covers both invocation modes.Checklist
ci:).uv run ruff check src/ tests/anduv run ruff format --check src/ tests/pass (only__init__.pytouched; comment annotation is line-format-stable).Follow-up (not in this PR)
amannn/action-semantic-pull-request) to block non-conventional titles before they corrupt the CHANGELOG.build(deps):/build(deps-dev):from the CHANGELOG viachangelog-sectionsif Dependabot noise becomes a problem.