Repository navigation
ci: canary direct, pinned cicd-squabbler chains gate - #988
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Caution Review failedThe pull request is closed. Summary
Merge Risk:
|
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2e74e4d998
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| - 'dtolnay/rust-toolchain@v1' | ||
| - 'taiki-e/install-action@v2.88.0' | ||
| '.github/workflows/cicd-squabbler.yml': | ||
| - 'metadatastician/standards@1725bebd3773ea25627479f813283abf1c497a85' |
There was a problem hiding this comment.
Regenerate the complete lockfile dependency closure
This workflow reference has no corresponding top-level entry under dependencies:. Consequently, Hypatia.Rules.ActionsLock.parse/1 returns {:error, {:workflow_dependencies_missing, ...}}; the elixir-compile CI job explicitly runs the test that parses this repository's authoritative lockfile, so every PR containing this change will fail that gate. Regenerate the lockfile so this standards revision and all of its transitive uses entries are recorded.
Useful? React with 👍 / 👎.
…ight (#989) ## Incident and root causes PR #988 was merged with CICD Squabbler showing `startup_failure` (zero jobs) under both the cross-owner reusable and the same-owner composite action. This is not a green check. Meanwhile, Governance's Allowlist Preflight consistently failed with five `metadatastician/standards/.github/workflows/*` gaps because it fetched its policy at pinned standards revision `333b06a...`. That revision **does not** contain the reusable workflow pattern; standards revision `1725bebd3773ea25627479f813283abf1c497a85` **does**. This is an evidenced pinned-policy mismatch, not a justification to weaken the check. ## Corrections 1. Squabbler now has **zero external `uses:` references**. Checkout and pinned release installation run as shell steps. The binary is cryptographically verified against SHA256 `6cbeb4577d83ccf2dea3405a3afb0d34b7fee422af73f2113d413ea7edba026c` and attested signer/source `b854d17abc0dce296719a349ebe856ff945cf03e`. The pre-change user-visible CI already proved checkout, verified installation, and `chains` succeeded: 37 probed repositories, 290 edges, 17 nonblocking findings. No writes/auto-fix. 2. The Governance reusable is pinned to standards `1725bebd3773ea25627479f813283abf1c497a85`, whose source allowlist contains `metadatastician/standards/.github/workflows/*@*`, covering the five previously failing canon reusables. 3. `.github/workflows/actions.lock` is updated consistently: squabbler `[]` and the new Governance commit. ## Review and gating - [x] Squabbler starts real jobs, not startup_failure. - [x] Pinned install and SLSA attestation pass. - [x] Squabbler chain check passes with 0 blocking findings. - [ ] Re-run new Governance revision; the five gaps should disappear or be explicitly explained. - [ ] Verify lock and all other existing required CI jobs before merge. - [ ] Determine actual branch rules with an Administration-read connection before promoting this check to required; GitHub's current integration returns 403 on branch protection reads. **Draft by design**: remain unmergeable until combined validation passes. Never infer legitimacy from GitHub allowing a merge. Autonomous repair and fleet quarantine remain unchanged.



Canary results and revised implementation
Initial cross-owner call failed with GitHub Actions
startup_failureand zero jobs. This is a real integration defect, not a success. The revised canary invokes the independently maintained squabbler's pinned same-owner composite action directly, avoiding the cross-owner reusable/workflow policy boundary.The action is pinned to
hyperpolymath/cicd-squabbler@1ab1507a424c9edfe6cb53dea4e33a2f3cc558e3. The action's installer verifies SHA256 and provenance of the released binary; the GitHub token is read-only (contents + attestations). No Administration token and no--applyor writes.The hard chain job runs on PR, push, weekly drift sweep and manual dispatch.
squabble chains .=<repo> --follow 1fails on exit 4 (cycle/dead upstream) and on any nonzero tool error. Its stdout and exit code go to the GitHub step summary. No green is claimed for a failed or missing check.The workflow's
actions.lockentry was updated to reflect the new SHA-pinned action and checkout. The canonicalgh actions-lock --verifyand the normal CI suite must pass before merge.Acceptance criteria
startup_failure).Squabbler stays a standalone CI tool; Hypatia is only a consumer. The initial failed cross-owner attempt is retained in the PR history as diagnostic evidence.