Symptom
The reusable claude-pr-review.yml@v2 quality-gate false-blocks release PRs. It reported a critical / blocking finding claiming a CHANGELOG/commit-count mismatch that does not exist.
Observed on glitchwerks/claude-configs PR #987 (release v0.27.0):
-
Quality-gate finding: "PR/CHANGELOG claim 3 user-facing commits since v0.26.0, but git history shows only 1 commit (#836)." → marked 🔴 critical, quality-gate FAIL, quality-gate-shadow agree:blocking.
-
Actual git history (verified):
$ git rev-list -n1 v0.26.0
f56481b...
$ git log --oneline v0.26.0..origin/main
4b5a77a fix(scan): disambiguate source_id ... (#836)
ed60ad1 fix(test-implementer): format authored test files ... (#973)
0d7737f feat(router): consume mixed_content decision ... (#704)
$ git merge-base --is-ancestor ed60ad1 v0.26.0 && echo IN || echo NOT-IN
NOT-IN # #973 is genuinely unreleased
$ git merge-base --is-ancestor 0d7737f v0.26.0 && echo IN || echo NOT-IN
NOT-IN # #704 is genuinely unreleased
CHANGELOG was correct: 3 unreleased commits. Gate saw only 1.
Likely root cause
On a release PR, the head branch (release/vX.Y.Z) is cut from main and already contains the unreleased commits. The gate appears to compute "commits since last tag" against the wrong base — candidates:
- diffing only the PR's own commit(s) (the single
chore(release) commit) instead of git log <last-tag>..HEAD,
- using the squash-merge title of the latest already-merged PR as the entire history,
- a shallow
fetch-depth that truncates history so only the most recent commit/tag relationship is visible.
Suggested fix
- Enumerate release commits with
git log <last-annotated-tag>..HEAD (after git fetch --tags --unshallow or sufficient fetch-depth), not against the PR diff or a single merge commit.
- For the CHANGELOG cross-check specifically: resolve the prior tag via
git describe --tags --abbrev=0 HEAD^ (or the tag named in the CHANGELOG link refs) and count the real range.
- Add a regression fixture: a release-style PR whose branch contains N>1 unreleased commits must not be flagged as a count mismatch.
Impact
Every future claude-configs release PR will hit this and require a manual UI override to merge. Workaround in the meantime: verify the count via git log <tag>..HEAD + merge-base and override-merge if the finding is the stale-base false positive.
Reported from claude-configs PR #987 (merged via UI override after verification).
🤖 Generated by Claude Code on behalf of @cbeaulieu-gt
Symptom
The reusable
claude-pr-review.yml@v2quality-gate false-blocks release PRs. It reported a critical / blocking finding claiming a CHANGELOG/commit-count mismatch that does not exist.Observed on
glitchwerks/claude-configsPR #987 (releasev0.27.0):Quality-gate finding: "PR/CHANGELOG claim 3 user-facing commits since v0.26.0, but git history shows only 1 commit (#836)." → marked 🔴 critical,
quality-gateFAIL,quality-gate-shadowagree:blocking.Actual git history (verified):
CHANGELOG was correct: 3 unreleased commits. Gate saw only 1.
Likely root cause
On a release PR, the head branch (
release/vX.Y.Z) is cut frommainand already contains the unreleased commits. The gate appears to compute "commits since last tag" against the wrong base — candidates:chore(release)commit) instead ofgit log <last-tag>..HEAD,fetch-depththat truncates history so only the most recent commit/tag relationship is visible.Suggested fix
git log <last-annotated-tag>..HEAD(aftergit fetch --tags --unshallowor sufficientfetch-depth), not against the PR diff or a single merge commit.git describe --tags --abbrev=0 HEAD^(or the tag named in the CHANGELOG link refs) and count the real range.Impact
Every future
claude-configsrelease PR will hit this and require a manual UI override to merge. Workaround in the meantime: verify the count viagit log <tag>..HEAD+merge-baseand override-merge if the finding is the stale-base false positive.Reported from claude-configs PR #987 (merged via UI override after verification).
🤖 Generated by Claude Code on behalf of @cbeaulieu-gt