fix(ci): correct release-please extra-file type and manifest baseline#46
Merged
fix(ci): correct release-please extra-file type and manifest baseline#46
Conversation
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
6 tasks
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
6 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.
Description
Two small fixes to the release-please pipeline (#44) that surfaced on its first live run against main:
extra-filestypepythonis invalid. Release-please supportsjson,yaml,toml,xml, andgeneric— notpython. Switched togenericand annotated the__version__line insrc/pymat/__init__.pywith thex-release-please-versionmarker so release-please finds and rewrites it on every version bump.Manifest baseline was wrong. I set
.: "3.0.0"based on the pending vis-cutover version in my local working tree, but main's current released state is2.1.0. Corrected so release-please computes the next version from main's actual history.rs-materials: "0.2.0"was already correct.The "commit could not be parsed" warnings in the failing run are legacy merge-commit subjects and pre-convention release commits — noise, not fatal.
Type of Change
fix— Bug fix (no user-facing behavior change; pipeline was non-functional)Required
__version__; no Python code affected)Refs:line at the bottomAdditional Notes
After this merges: release-please should open its first Release PR on the next push to main that contains a
feat:/fix:commit. Until then, chore/ci/docs/test commits continue to be hidden (no release).Verification: watch
gh run view --workflow release-please.yml --limit 1after merge — it should complete successfully with either "No release necessary" (nothing warranting a bump) or a Release PR opened.Refs: #43