Repository navigation
fix(ci): re-point standards callers to metadatastician/standards #958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -16,7 +16,7 @@ permissions: | |
|
|
||
| jobs: | ||
| governance: | ||
| uses: hyperpolymath/standards/.github/workflows/governance-reusable.yml@333b06a01db1874ffedb2de1bfabb195640927c7 | ||
| uses: metadatastician/standards/.github/workflows/governance-reusable.yml@333b06a01db1874ffedb2de1bfabb195640927c7 | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When the repository's actions-lock synchronization gate checks these five managed callers, the workflow and lockfile now disagree: Useful? React with 👍 / 👎.
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct, and it's the same gap CodeRabbit raised on this line. The tool-regenerated lock (run 40409175431, sha256 Generated by Claude Code There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
After adopting the new canonical repository name here, merge events from that repository will carry Useful? React with 👍 / 👎.
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Confirmed: Generated by Claude Code There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
For repositories using Useful? React with 👍 / 👎.
Owner
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Confirmed: While testing that, I found For this repository specifically: if hypatia's own Actions policy is Generated by Claude Code |
||
| # Scanner pin, overriding the reusable's default (51ab649, which rejects the | ||
| # v0.0.3 actions.lock that gh actions-lock now writes). This is hypatia main | ||
| # with #938 (v0.0.3 lock), #942 (WH013 per-job credentials) and #947 | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔎 Supported by static analysis
Script executed:
Repository: hyperpolymath/hypatia
Length of output: 779
Script executed:
Repository: hyperpolymath/hypatia
Length of output: 725
Regenerate
actions.lockfor the metadatastician callers.At the reviewed head,
.github/workflows/actions.lockstill recordshyperpolymath/standards@333b06a…for the governance, hypatia-scan, mirror, scorecard and secret-scanner workflows. The workflows now callmetadatastician/standardsat the same SHA. The lock and theuses:owner therefore disagree. A lock-sync check that compares them can fail for these workflows. Regenerate the lock from the updateduses:references, and commit the result to this branch before merge.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is correct, and the lock isn't committed yet.
actions.lockis tool-owned, andGITHUB_TOKENcan't push files under.github/workflows/.The one-off run 40409175431 has already regenerated it with
gh actions-lockv0.2.0 and the estate repair chain. It passedcheck-lock-sync.shand--verify-local, and the result has sha25602a8950a…. The owner is landing those bytes with a local run, and I'll resolve this thread once that commit is on the branch.Generated by Claude Code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hyperpolymath Understood. The reported validation covers the regenerated lock, but the branch update is still pending. This finding remains open until the generated bytes are committed. I’ll leave thread resolution to you.
You are interacting with an AI system.