ci(PROC-1514): adopt release-please for automated versioning#97
Merged
Conversation
Add release-please action that opens a Release PR on every push to main, computes the next version from Conventional Commit prefixes, and writes CHANGELOG.md. Next release pinned to 1.0.0 via release-as. Adds a repo-level conventional-commit PR title check; companion regex update needed in the org pr-title-check workflow (draft saved at .context/org-pr-title-check-proposed.yml) so titles like feat(PROC-XXXX): ... are accepted.
Merged
5 tasks
Add a Pull Requests & Releases section to CLAUDE.md and a Contributing section to README.md so future contributors (and Claude sessions) know the title format and that pyproject.toml versions are no longer hand-edited.
CalNightingale
changed the title
saicheems
pushed a commit
to gradienthealth/.github
that referenced
this pull request
Apr 21, 2026
) ## Summary Widen the PR title check so titles like `feat(ENG-123): add feature` are accepted in addition to the existing `ENG-123: ...` and `NO-ISSUE:` formats. ## Why Adopting [release-please](https://github.com/googleapis/release-please) in `cloud_optimized_dicom` (see [PR #97](gradienthealth/cloud_optimized_dicom#97)) requires PR titles to start with a Conventional Commit type prefix (`feat:`, `fix:`, `chore:`, etc.) so the bot can decide the next version. The existing org-level check requires the Linear ID at the very start, which conflicts. Putting the Linear ID inside the conventional-commit scope (`feat(ENG-123): ...`) satisfies both worlds, but the current regex doesn't recognize it. ## Change Two new branches added to the existing if/elif chain: - Conventional Commit with Linear ID in scope: `feat(ENG-123): add feature` - Conventional Commit with `NO-ISSUE` opt-out: `chore: NO-ISSUE refactor internals` Existing formats continue to pass — pure superset, zero behavior change for repos not adopting Conventional Commits. ## Test plan - [ ] Title `ENG-123: existing format` → passes (unchanged) - [ ] Title `feat(ENG-123): new format` → passes (new) - [ ] Title `NO-ISSUE: opt-out` → passes (unchanged) - [ ] Title `chore: NO-ISSUE thing` → passes (new) - [ ] Title `random title with no marker` → fails
4 tasks
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.
Linear: https://linear.app/gradienthealth/issue/PROC-1514/adopt-release-please-for-cloud-optimized-dicom
Summary
Adopt release-please so version bumps, tagging, and changelog generation become automatic. release-please opens a continuously-updated Release PR on every push to
main; merging it bumps the version, updatesCHANGELOG.md, tagsvX.Y.Z, and triggers our existingpublish.ymlworkflow.What's added
.github/workflows/release-please.yml— runs on every push tomain.release-please-config.json— Python release type, single-package,release-as: 1.0.0to pin the next release at 1.0.0 (we've been prod-stable for a while; jumping to 1.x makes our compatibility contract explicit). Remove therelease-asfield after that release ships so subsequent versions are derived from Conventional Commit types..release-please-manifest.json— pins current version (0.2.5)..github/workflows/pr-title-conventional.yml— usesamannn/action-semantic-pull-requestto require a Conventional Commit prefix (feat:,fix:,chore:, etc.) on every PR title. release-please needs this prefix to decide bump type after merge.CLAUDE.mdandREADME.md— new sections documenting the title format, type→bump mapping, and thatpyproject.tomlversionis no longer hand-edited.Title format going forward
<type>(PROC-XXXX): short description— e.g.feat(PROC-1502): backfill dropped UID tags.feat→ minor bump (1.0.0 → 1.1.0)fix→ patch (1.0.0 → 1.0.1)feat!orBREAKING CHANGE:footer → major (1.0.0 → 2.0.0)chore,docs,refactor,test,ci,build,perf,revert→ no releaseCompanion org-level PR required first
The existing org-level
pr-title-check.yml(ingradienthealth/.github) requires the Linear ID at the start of the title. The new format puts the Linear ID inside a Conventional-Commit scope:feat(PROC-XXXX): .... A widened regex that accepts both styles is up for review at gradienthealth/.github#6 (Linear: https://linear.app/gradienthealth/issue/PROC-1513/allow-conventional-commit-titles-in-org-pr-title-check) — that PR needs to merge first, otherwise titles in the new format will fail the orgcheck-titleworkflow (including this PR's title).Test plan
check-titleon this PR; confirm it passes alongside the newconventional-prefixcheckv1.0.0tag is created andpublish.ymlships to PyPI