Repository navigation
Lock refs another workflow rewrites in a shared $/ action - #231
Merged
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
Shared-action rewrites can still leave an unused SHA recorded as a direct root, causing --verify-local to fail.
1 open issue
What changed in this PR
Updates lockfile generation so workflows sharing an in-repository $/ action record refs introduced by another workflow’s rewrites, while preserving refs declared by remote composites.
Changes:
- Merges shared-action rewrites before updating workflow lockfile entries.
- Adds regression coverage for shared rewrites, mixed-case full SHAs, and both verification modes.
| File | Description |
|---|---|
| internal/pin/commit.go | Adopts pins introduced by shared-action rewrites before writing lockfile entries. |
| cmd/gh-actions-lock/run_test.go | Tests shared-action rewriting and subsequent local and remote verification. |
Review effort: Max
Workflows that reach the same in-repo $/ action share its rewrites. When one workflow kept a full-SHA ref (because a composite it uses declares that SHA) and another narrowed it to a tag, the shared action file was rewritten but the first workflow's lockfile list still named only the SHA, so --verify-local reported ref-changed right after a successful fix. Commit now records, under each workflow, the pins that other workflows' rewrites give its shared action files. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
When another workflow's rewrite of a shared $/ action removed a workflow's only direct use of a ref, the ref stayed a workflow root and --verify-local reported it stale. Commit now drops it from the workflow's roots unless the workflow, after its own rewrites, or one of its $/ actions, after the merged rewrites, still uses it. The pin and the composite edge that requires it stay. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
nodeselector
force-pushed
the
nodeselector-shared-self-action-rewrites
branch
from
October 22, 2026 04:27
e54e09e to
e49d35d
Compare
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.
Workflows that reach the same in-repo
$/action share its rewrites. When one workflow keeps a full-SHA ref (a composite it uses declares that SHA) and another narrows the same ref to a tag, the shared action file is rewritten, but the first workflow's lockfile list still names only the SHA. The fix run exits 0 and--verify-localthen reports ref-changed.Commit now records, under each workflow, the pins that other workflows' rewrites give its shared action files. The runner looks up each
uses:in a$/action as written, so the workflow has to lock both refs. Rewriting both to one ref would instead rename the edge the composite declares. Full-SHA refs match case-insensitively.