Stop the checkout from overriding the App it was meant to measure (T-1502) - #741
Merged
Conversation
The first run failed before it could measure anything:
remote: Permission to MongLong0214/commitlore.git denied to github-actions[bot]
It was carrying a valid App token at the time. `actions/checkout` defaults to `persist-credentials: true`, which leaves an `http.<url>.extraheader` holding the Actions token, and that header beats credentials embedded in a push URL. So the push went out as `github-actions[bot]` and was refused, and the run measured its own wiring instead of the question.
That is the branch the actor capture was added for one commit earlier, arriving before the capture could run -- the failure landed at the push rather than at the pull request. So the same correction goes one step earlier: after pushing, read back who the server says committed it, before opening anything on top.
The run did establish one thing that was open: the App is installed on this repository, and the token path works end to end. `app-installation-token: installation 154501414` is the first evidence of that -- it could not be checked from a user token, which is why it was on the owner's list.
Limit: this fixes the push identity; whether an App-opened pull request runs the checks is still unmeasured, which is the whole point of the workflow
Blast: local
Undo: easy
Certainty: firm
Record-Id: r-persistcreds1502
Provenance: authored
Verified: the failing run's log shows the mint step succeeding with an installation id and the push step refused for `github-actions[bot]`, which is the two facts together -- a good token and the wrong identity; the workflow parses with the option set
CommitLore-Version: 2.0.0
CommitLore — record lintTrailers: clean — 1 commit in Trailer violations fail this check. Active constraints are informational — they are what the repository already decided, not a verdict on this PR. |
This was referenced Aug 17, 2026
Committing dist is what makes the checkout the product — and what makes every second PR rebuild
#719
Closed
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
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.
The first measurement run failed before measuring anything:
It was carrying a valid App token at the time.
actions/checkoutdefaults topersist-credentials: true, leaving anhttp.<url>.extraheaderwith the Actions token — and that header beats credentials embedded in a push URL. The push went out asgithub-actions[bot], was refused, and the run measured its own wiring instead of the question.This is exactly the branch the actor capture was added for one commit earlier. It arrived before that capture could run, because the failure landed at the push rather than at the pull request. So the same correction moves one step earlier: after pushing, read back who the server says committed it.
What the failed run did establish
The App is installed on this repository and the token path works end to end. That was an open item on the owner's list — it cannot be checked from a user token, which is why it was there. A failed run answered it.
Still unmeasured
Whether an App-opened pull request runs the checks. That is the whole point of the workflow and it has not happened yet.