ci(release): switch release automation to release-please - #99
ci(release): switch release automation to release-please#99danielscholl wants to merge 6 commits into
Conversation
There was a problem hiding this comment.
Pull request overview
Replaces label-driven releases with release-please while preserving build-time version stamping and ensuring releases contain installable artifacts before publication.
Changes:
- Adds release-please configuration and draft-to-published release workflow.
- Enforces Conventional Commit PR titles.
- Updates release documentation and changelog history.
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/release.yml |
Implements release-please and artifact publication. |
.github/workflows/pr-title.yml |
Adds PR title validation. |
.release-please-config.json |
Configures release and changelog behavior. |
.release-please-manifest.json |
Seeds the current version. |
.github/PULL_REQUEST_TEMPLATE.md |
Replaces release-label guidance. |
docs/branch-protection.json |
Requires the title check. |
docs/CI_SETUP.md |
Documents release setup and operation. |
CONTRIBUTING.md |
Documents the new release process. |
AGENTS.md |
Updates contributor automation guidance. |
CHANGELOG.md |
Consolidates historical release notes. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Replace the label-driven release workflow with release-please triggered on push to main, add a pr-title workflow enforcing conventional commit PR titles, and update docs, branch protection, and PR template to match
3baab3f to
05347d5
Compare
Pass event, tag, and sha values via env instead of inline interpolation Draft the release before uploading assets to avoid a published release missing its wheel on upload failure
Enable force-tag-creation so release-please tags vX.Y.Z alongside the draft release, letting the assets job recover the version if it fails before publishing. Update comments and docs to match.
Explain config-as-code install via microsoft/github-operations repo and list the specific permissions used by release automation
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.
Suppressed comments (2)
Previously missed (2) — in code that hasn't changed since the last review.
AGENTS.md:47
- This states that every breaking
!produces a major release, but the new release-please config setsbump-minor-pre-major: true; at the current 0.5.1 version, a breaking title produces 0.6.0, not 1.0.0. Match the caveat already documented inCONTRIBUTING.mdso contributors are not given conflicting release semantics.
Squash-merge uses the PR title as the commit subject release-please
versions from (`feat` minor, breaking `!` major, anything else patch);
the `pr-title` check enforces it.
.github/PULL_REQUEST_TEMPLATE.md:18
- This omits the configured pre-1.0 exception: with
bump-minor-pre-major: true, a breaking!at 0.5.1 bumps to 0.6.0 rather than 1.0.0. The template should describe that behavior consistently withCONTRIBUTING.md.
The PR title determines release impact via release-please:
feat -> minor, breaking ! -> major, anything else -> patch.
yuchen-wang99
left a comment
There was a problem hiding this comment.
Verdict: no functional blocker; safe to approve. All checks pass, and an independent release-please dry run correctly proposed 0.5.2 . Draft release, forced tag creation, exact-SHA build, and asset-first publishing are sound.
Summary
Cutting a release today depends on remembering to apply a
release:*label before merging; forget it and nothing ships. This switches the repo to release-please: every merge tomainkeeps a standingchore: release X.Y.ZPR up to date, and merging that PR is the entire release process.Changes
release.ymlwith release-please plus anassetsjob that builds and attaches the wheelspi updatenever sees a release without onepyproject.tomlat the0.0.0+sourcesentinel; the real version is still stamped at build timepr-titlelint check, since the PR title now determines the version bump (featminor, breaking!major, anything else patch)CHANGELOG.mdso release-please can take it overdocs/CI_SETUP.mdfor the new modelOne-time setup (GitHub App, secrets, squash-only merges, branch protection) needs repo admin; the commands are in the new
docs/CI_SETUP.mdsection. After this merges, the first push tomainopenschore: release 0.5.2covering everything since v0.5.1.Validation
uv run pre-commit run --all-filesgreen (ruff, ty, pytest)chore: release 0.5.2with a correctly sectioned changelogspi-0.5.2-py3-none-any.whl+ sdist; sentinel restored after