Give the gate the repository, not a snapshot of its tip - #169
Merged
Merged
Conversation
actions/checkout defaults to a depth-1 shallow clone, so the gate has been running without tags and without history since the day I added it. Anything built on git describe therefore cannot name the commit, fails closed, and reports red on both runtimes for a reason that has nothing to do with the change under test - while passing on a full-history qualification host, which is the worst version of this failure because the CI signal and the local signal disagree and CI looks wrong. #168 adds exactly such a guard and is red on both runtimes today. The defect is older than that PR and is mine. A gate that asserts a repository's behaviour has to check out the repository. fetch-depth: 0. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
silverstein
added a commit
that referenced
this pull request
Aug 19, 2026
…a host The publish test drove the real script with no git identity in its environment, while the fixture helper injected one for its own commits. The publisher commits into the distribution repo, so on any machine without a global git identity the run reached "4 file(s) changed" and then died on "Author identity unknown". That read as the guard refusing a legitimate publish. It is the host being assumed: it passes wherever a global identity happens to exist, and fails on a CI runner or a developer box without one. Same class as #164, hiding in a test rather than in the product. Worth recording because the diagnosis was wrong twice before it was right. Both lanes concluded the red was the depth-1 checkout that #169 fixed. It was not: the same test failed identically here with full history. #169 was still correct on its own merits, since a shallow gate cannot evaluate anything resting on git describe, but it did not fix this, and merging on "the hypothesis held" would have landed a red gate on a false explanation. Also carries the merge of master, resolving the one predicted conflict in check-plugin-freshness.mjs by taking the shipped-paths version and adding scripts/plugin-version.mjs to the import closure it binds. publish-guard 15/15, plugin-freshness-coverage 5/5. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merged
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.
My defect, from the day I added the gate.
actions/checkoutdefaults to a depth-1 shallow clone.pull-request-gate.ymlnever setfetch-depth, so every run since #150 has had no tags and no history.Anything built on
git describetherefore cannot name the commit, fails closed, and reports red on both runtimes for a reason unrelated to the change under test — while passing on a full-history qualification host.That last part is what makes it costly: CI and local disagree, and CI is the one that looks wrong. The natural response is to distrust the gate.
#168 ("Bind the plugin publish guard, and stop it accepting a build it cannot identify") adds exactly such a guard and is red on both runtimes today. The diagnosis is pdf:1's; the bug is mine and predates that PR.
A gate that asserts a repository's behaviour has to check out the repository.
fetch-depth: 0.Verification is #168 itself: once this lands, its guard should be able to identify the commit and the red should resolve without touching the guard.
🤖 Generated with Claude Code