ci: introduce release-please automated release pipeline#44
Merged
Conversation
Drives version bumps, tagging, and publish triggers from conventional commits for both Python (py-materials → PyPI) and Rust (rs-materials → crates.io, gated) packages. Pipeline on push to main: 1. release-please scans commits since the last tag and opens a per-package Release PR bumping versions + appending CHANGELOG entries. 2. Merging the Release PR pushes a tag (vX.Y.Z or rs-materials/vX.Y.Z), which triggers the existing publish workflows. 3. release-please creates the GitHub Release with auto-generated notes — the duplicate `github-release` jobs in release.yml and release-rs-materials.yml are removed. Also: - PR Hygiene job enforces the contributor PR template checklist via mheap/require-checklist-action. Template restructured into "required" (must be checked) and "if applicable" (delete sections that don't apply) groups. Bot PRs from release-please are exempt (they carry their own release-reviewer checklist for humans). - rs-materials crates.io publishing is gated behind vars.CRATES_IO_PUBLISH_ENABLED until the token is configured and downstream consumer coordination completes (issue #43). - Uses the existing RELEASE_APP GitHub App so the tag release-please pushes triggers downstream workflows (GITHUB_TOKEN pushes are inert under recursion protection). Refs: #43
gerchowl
added a commit
that referenced
this pull request
Apr 18, 2026
Two fixes to the release-please pipeline that only surfaced on the first live run against main (#44): 1. `extra-files` type `python` is not a valid release-please type — supported types are `json`, `yaml`, `toml`, `xml`, and `generic`. Switched to `generic` and annotated the `__version__` line in `src/pymat/__init__.py` with the `x-release-please-version` marker so release-please can rewrite it on version bumps. 2. Manifest baseline for `py-materials` was set to 3.0.0 (the pending vis-cutover version on feature/40-vis-cutover), but the current released state on main is 2.1.0. Corrected to `.: "2.1.0"` so release-please computes the next version from the actual main history rather than leapfrogging. rs-materials at 0.2.0 is already correct. The "commit could not be parsed" noise in the first run is from legacy merge-commit subjects and pre-convention release commits — those are warnings, not fatal, and release-please ignores them when computing the next version. Refs: #43
5 tasks
gerchowl
added a commit
that referenced
this pull request
Apr 18, 2026
…#46) Two fixes to the release-please pipeline that only surfaced on the first live run against main (#44): 1. `extra-files` type `python` is not a valid release-please type — supported types are `json`, `yaml`, `toml`, `xml`, and `generic`. Switched to `generic` and annotated the `__version__` line in `src/pymat/__init__.py` with the `x-release-please-version` marker so release-please can rewrite it on version bumps. 2. Manifest baseline for `py-materials` was set to 3.0.0 (the pending vis-cutover version on feature/40-vis-cutover), but the current released state on main is 2.1.0. Corrected to `.: "2.1.0"` so release-please computes the next version from the actual main history rather than leapfrogging. rs-materials at 0.2.0 is already correct. The "commit could not be parsed" noise in the first run is from legacy merge-commit subjects and pre-convention release commits — those are warnings, not fatal, and release-please ignores them when computing the next version. Refs: #43
gerchowl
added a commit
that referenced
this pull request
Apr 18, 2026
Brings in the release-please automated release pipeline (#44), the pipeline self-fix (#46), and the 2.1.1 CI-infrastructure patch release (#48) onto the vis cutover branch so 3.0 ships through the new flow. Conflict resolutions: - pyproject.toml: kept `version = "3.0.0"` over main's 2.1.1 - src/pymat/__init__.py: kept 3.0.0 + kept main's `# x-release-please-version` marker comment - CHANGELOG.md: renamed the pre-written `[3.0.0]` section to `Unreleased` (release-please will version it on Release PR), folded main's 2.1.1 entry in below, added mat-vis-client>=0.4.0 bump + cache-clear note to the Breaking list Refs: #40
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.
Description
Introduce the release-please automated release pipeline for both Python (
py-materials→ PyPI) and Rust (rs-materials→ crates.io, gated) packages. Adds PR hygiene enforcement, restructures the PR template for "delete-if-not-applicable" semantics, and defers rs-materials crates.io publishing via a repo-var gate pending downstream coordination.Type of Change
ci/build— CI/CD pipeline changes (no release)Required
uv run pytest— 241 passed, 18 skipped earlier this session; this PR touches only CI/workflow/template files, no Python code)Refs:line at the bottomIf Applicable
Documentation
RELEASE_PROCESS.mdto describe the new flow (replaces the manualgit tag/git pushinstructions)pull-request-headerso every auto-generated Release PR carries explicit merge gatesAdditional Notes
Failure modes now gated out:
pyproject.toml,src/pymat/__init__.py,mat-rs/Cargo.tomlversion fields)v9.9.9typed by hand) → impossible (versions derived from commit history)RELEASE_APPtoken, notGITHUB_TOKEN, so tag pushes trigger downstream workflows)What must follow this PR landing on main:
PR Hygieneto required-status-checks on bothmain-protection(ruleset 15092073) anddev-protection(ruleset 15092074). I'll do this viagh apiautomatically once this PR merges.RELEASE_APPpermissions — needscontents: write+pull-requests: write. Likely already granted since the App handles auto-merge insync-main-to-dev.yml, but worth checking in the App settings.Related issues:
Refs: #43