fix(allowlist): admit eight actions the estate already depends on - #579
Merged
Conversation
The governance gate's Allowlist Preflight is a real gate doing its job — it exits 1 on an uncovered `uses:` and 0 when clean, which I verified directly rather than inferring. Its failures across the estate are genuine findings, not a broken check. Measured by running the check locally against 124 repository checkouts: 22 fail, and they cluster into just eight actions: SonarSource/sonarqube-scan-action 15 refs — SonarCloud runs estate-wide julia-actions/julia-runtest 4 julia-actions/julia-buildpkg 3 JuliaRegistries/TagBot 2 julia-actions/CompatHelper 1 oven-sh/setup-bun 1 Bogdanp/setup-racket 1 anchore/sbom-action 1 The SonarSource one is the striking case: SonarCloud is a required status check in a large part of the estate, so the allowlist was rejecting an action the governance rules elsewhere insist upon. Each is the ecosystem's canonical action for its job, and each was already in use before this change — this admits what is depended on rather than widening the surface: SonarSource for SonarCloud, julia-actions/JuliaRegistries for the .jl family, oven-sh/setup-bun (which the Bun-over-Deno ruling makes load- bearing), Bogdanp/setup-racket as the de facto Racket action, and anchore/sbom-action alongside anchore/scan-action, which was already allowed. NOT added, because it is a different defect: metadatastician/paint-type calls governance-reusable.yml and scorecard-reusable.yml from `metadatastician/ standards`, which returns 404. That is a wrong-org reference to a repository that does not exist, and it belongs in paint-type, not here. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>
|
Note Automatic reviews are paused because your trial's included automatic processing has been used for this period. Upgrade now, or comment "Gitar review" to run a review anytime. Code Review ✅ ApprovedAdds eight canonical ecosystem actions to the governance allowlist to resolve policy contradictions across the estate. No issues found.
OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Important Your trial ends in 5 days — upgrade now to keep code review, CI analysis, auto-apply, custom automations, and more. Was this helpful? React with 👍 / 👎 | Gitar |
![gitar-bot[bot]](https://avatars.githubusercontent.com/in/827041?s=60&v=4){kind=small}
|
hyperpolymath
added a commit
to metadatastician/paint-type
that referenced
this pull request
Aug 5, 2026
…ot exist (#51) Both workflows called reusables from **`metadatastician/standards`**: ```yaml uses: metadatastician/standards/.github/workflows/governance-reusable.yml@2b6d30b uses: metadatastician/standards/.github/workflows/scorecard-reusable.yml@2b6d30b ``` **There is no `standards` repository in the `metadatastician` organisation.** The API returns 404, and it does not appear in the org's repository list. The canonical one is `hyperpolymath/standards`, which every other repo in the estate calls. The consequence is unambiguous: **`governance.yml` has failed 10 times out of 10.** A caller pointing at a non-existent reusable is rejected before any job is created — no log, no check run, and nothing on the board to explain it. Repointed both to `hyperpolymath/standards@bd0df9ead7fa` (the commit that made the governance check lockfile-aware), verified present via the commits API rather than copied from a sibling repo. ## How it surfaced Found while auditing allowlist failures across 124 repository checkouts. These two refs appeared as uncovered `uses:` entries — but they are **not an allowlist gap**. Allowlisting them would have papered over a workflow that can never run, which is why they were excluded from hyperpolymath/standards#579. ## Two further findings, deliberately not fixed here Left out so this PR stays reviewable, but both are real: 1. **`.machine_readable/ECOSYSTEM.a2ml` does not exist**, yet `verify-manifests.yml` greps it for the string `"metadatastician/standards"`. So that workflow cannot pass either — and its expectation **encodes the same wrong-org belief**, which suggests this was a systematic assumption rather than a typo. 2. **There is no `.github/workflows/actions.lock`.** Under this account's workflow-lockfile enforcement that is the usual cause of repo-wide `startup_failure`. Found during the 2026-08-05 estate CI/CD census. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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.
The governance gate's Allowlist Preflight is a real gate doing its job — I verified directly that it exits 1 on an uncovered
uses:and 0 when clean, rather than inferring it. Its failures across the estate are genuine findings, not a broken check.Measured, not sampled
Ran the check locally against 124 repository checkouts. 22 fail, and they cluster into just eight actions:
SonarSource/sonarqube-scan-actionjulia-actions/julia-runtestjulia-actions/julia-buildpkgJuliaRegistries/TagBotjulia-actions/CompatHelperoven-sh/setup-bunBogdanp/setup-racketanchore/sbom-actionThe SonarSource one is the striking case. SonarCloud is a required status check across a large part of the estate — so the allowlist was rejecting an action the governance rules elsewhere insist upon. Two estate policies in direct contradiction, each individually reasonable.
This admits what is depended on, not new surface
Every one of these was already in use before this change. Each is its ecosystem's canonical action:
.jlfamilyanchore/scan-action@*, which was already allowedDeliberately not added
metadatastician/paint-typecallsgovernance-reusable.ymlandscorecard-reusable.ymlfrommetadatastician/standards, which returns 404. That is a wrong-org reference to a repository that does not exist — a bug inpaint-type, not an allowlist gap, and allowlisting it would paper over a workflow that can never run.Found during the 2026-08-05 estate CI/CD census.
🤖 Generated with Claude Code