fix(branch-prefix): recognize GitHub PR merge subject#7
Merged
Conversation
semvertag's branch-prefix strategy gated on the subject containing the literal string "Merge branch" — GitLab's default merge format. GitHub's PR-merge commits use "Merge pull request #N from OWNER/BRANCH" instead, which doesn't contain "Merge branch", so every GitHub Actions consumer of branch-prefix silently no-op'd with status=no_merge_commit even on real merge commits. Surfaced by dogfooding semvertag 0.3.0 on this repo's own CI (PR #6). Fix: rename `merge_mark_text: str` to `merge_mark_texts: tuple[str, ...]` defaulting to `("Merge branch", "Merge pull request")`; strategy now matches if any mark appears in the subject. Out-of-the-box correct for both providers. Breaking change for anyone overriding the old `merge_mark_text` env/config field — the rename to plural-tuple requires updating `SEMVERTAG_BRANCH_PREFIX__MERGE_MARK_TEXT="X"` to `SEMVERTAG_BRANCH_PREFIX__MERGE_MARK_TEXTS='["X"]'`. Acceptable pre-1.0 on an internal config knob nobody has had a chance to override in the wild (the field shipped post-bmad in v0.1.0 with no documented use case). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Summary
The
branch-prefixstrategy gated on subject containing"Merge branch"(GitLab's default merge format). GitHub's PR merges use"Merge pull request #N from OWNER/BRANCH", which doesn't contain that string — so every GitHub Actions user silently no-op'd withstatus=no_merge_commiteven on real merges. Surfaced by dogfooding this repo (PR #6, which merged but didn't tag).BranchPrefixConfig.merge_mark_text: str = "Merge branch"→merge_mark_texts: tuple[str, ...] = ("Merge branch", "Merge pull request")any(mark in subject for mark in self.config.merge_mark_texts)Breaking change for anyone overriding the old field. Acceptable pre-1.0 on a config knob the documented use case for is "non-default merge conventions" — nobody is doing that in the wild.
This PR's source branch is
bugfix/..., so once it merges and 0.3.1 publishes, the dogfood workflow's NEXT run should successfully patch-bump to 0.3.2.Test plan
just test— 420 pass (+3 new), 100% coveragejust lint-ci— cleanmkdocs build --strict— cleanbugfix/merge commit using OLD 0.3.0 (still fails the same way — fix isn't on PyPI yet)feat/orbugfix/...) → dogfood resolves 0.3.1 via>=0.3,<1→ auto-tags🤖 Generated with Claude Code