Repository navigation
fix(ci): make actions.lock agree with the workflows, restoring the CodeQL scanner - #78
Merged
Merged
Conversation
…deQL scanner The CodeQL security scanner and the OikosBot sustainability analysis have not run on main since PR #76 landed: both end in a zero-job `startup_failure` carrying the single annotation Invalid lockfile: .github/workflows/actions.lock#L1 The lockfile could not be validated. Regenerate it by running `gh actions-lock`. The cause is drift between the two files. PR #76 and the #77 Dependabot bump moved the workflows' refs — codeql.yml to the v4.38.1 commits, oikosbot.yml to `github/codeql-action/upload-sarif@v4.38.1` — while actions.lock still recorded `github/codeql-action@v4.38.0` / `b96794f0`. GitHub refuses to start any workflow whose refs disagree with its lockfile, so: * CodeQL Security Analysis -> startup_failure (not running at all) * OikosBot Sustainability -> startup_failure * governance / Actions lockfile verify -> failure The last one is the only one that shows up as a red check. A rejected workflow produces no checks at all, so the two scanners that had stopped scanning were invisible to anyone reading the checks list. Changes: * actions.lock: record `github/codeql-action@v4.38.1` -> `sha1-1c5b675653bb5c22dbe9b12b556ec555138e09fd` (verified against the upstream v4.38.1 tag) in both the per-workflow list and the dependency table, so the lock now describes what the workflows actually resolve to. Every tag-pinned entry in the file was re-resolved against GitHub and matches; `hyperpolymath/k9-ecosystem@main` is a branch ref and is expected to trail main's tip. * codeql.yml: the `# v3` comments on two v4.38.1 commits were false. They are not decoration — ci_configuration_test.ts uses that comment as the actions.lock key and asserts the two agree, so `# v3` was resolving to a dependency entry that does not exist. Corrected to `# v4.38.1`. `persist-credentials: false` is kept: it is the actual security control. * frontend/package-lock.json: deleted. Tracked package-lock.json fails the estate npm-avoidant gate, which is why `governance / Language / package anti-pattern policy` is red. Nothing references the file, and frontend/bun.lock (plus deno.lock) is the live lock for the same dependencies; it was a leftover from the npm era. * .github/funding.yml: deleted, keeping the tracked uppercase `.github/FUNDING.yml`. Both were tracked and contradicted each other (metadatastician vs hyperpolymath + ko_fi + liberapay), and on a case-insensitive filesystem a clone cannot hold both — one silently overwrites the other and the working tree is dirty on arrival. The uppercase file is the one GitHub reads and the one matching the live sponsor configuration, so its content is kept, per the same ruling applied in berrywiki#30 and progblocks#30. Delete and add are in one commit so a case-insensitive checkout applies it atomically. Verified: aspect tests pass (5/5, 20 badge-contract assertions); the lockfile audit reports zero drift between workflows and actions.lock; and the CodeQL assertions in both ci_configuration_test.ts and foundation_ci_config_test.ts were replayed against the new files. Those two suites were already failing before this change — three of the SHAs they hard-code as "reviewed" (8f31a5a4, cc58c0cb, 8750b94a) are no longer reachable from any ref in hyperpolymath/standards, and 8750b94a is the same dead pin that left a sibling repository's Scorecard not running. They are not wired into CI, which is why the drift went unnoticed. That stale map is corrected separately so no test is edited to accommodate this fix. Still red, and not addressed here (each needs a judgement call rather than a mechanical fix): the Hypatia scan and baseline-validation jobs, and the SonarCloud quality gate (Reliability Rating on new code). Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
arena-ai-coding-agent
Bot
requested a review
from hyperpolymath
as a code owner
September 29, 2026 12:41
Contributor
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
hyperpolymath
approved these changes
Sep 29, 2026
arena-ai-coding-agent Bot
pushed a commit
that referenced
this pull request
Sep 29, 2026
…not running #78 resynced the lockfile and brought oikosbot.yml back, but CodeQL stayed at `startup_failure` with the same annotation: Invalid lockfile: .github/workflows/actions.lock#L1 The lockfile could not be validated. #78 kept the inline-SHA form in codeql.yml, and that is the remaining cause. With one commit changing two things, the evidence that separated them is clean: oikosbot.yml uses tag refs and went green on #78; codeql.yml uses inline SHAs and did not. GitHub validates actions.lock against what the workflows actually reference, so a SHA in the YAML that the lock records under a tag ref is drift, and the whole workflow is refused before any job starts. This is the same correction PR #39 made in the sibling repository, where CodeQL went from startup_failure to scanning on the merge commit. Changes: * codeql.yml: `actions/checkout@v7.0.1` and `github/codeql-action/{init,analyze}@v4.38.1`, with actions.lock holding the commits (sha1-3d3c42e5…, sha1-1c5b6756…). The lock needed no change — its per-workflow entry already named exactly these refs. Matches the NOSONAR pin-authority convention already used in oikosbot.yml and dogfood-gate.yml here, and the rule progblocks records in its AGENTS.md: "do not re-inline action SHAs that .github/workflows/actions.lock already owns". `persist-credentials: false` is kept: it is the actual security control, and it is independent of how the ref is spelled. * tests/unit/ci_configuration_test.ts and tests/unit/foundation_ci_config_test.ts: three assertions demanded an inline SHA in codeql.yml. That requirement is what produced the broken form, so it is replaced by the invariant that actually protects the workflow — every ref codeql.yml uses must be recorded in the lock's codeql.yml entry, and each must resolve to an immutable 40-character commit. Both suites are rewritten to be strictly stronger than before, not weaker: they now also assert the lock's own commits are immutable SHAs, which the previous versions never checked. * The same files' hard-coded "reviewed" standards revisions (8f31a5a4, cc58c0cb, 8750b94a) are corrected to fad242d, the revision the workflows actually call. All three were unreachable — each returns "No commit found" from the standards API — and 8750b94a is not a commit at all: it is the blob id of scorecard-reusable.yml at standards 1f3eef6, the same dead pin that kept the sibling repository's Scorecard from running. A hard-coded expectation is a safety net only while it is true. Why this was not caught: these two Deno suites are not wired into any CI job. They were already failing when #76 landed, and nothing reported it. Verified: lockfile audit reports zero drift between every workflow and actions.lock; every assertion in both suites replayed against the new files and passes; aspect tests 5/5 with 20 badge-contract assertions. Still red and not addressed here: the Hypatia scan and baseline-validation jobs (the scanner exits before writing its SARIF, so the findings cannot be read without running it — adding baseline entries blind is the "silently absorb findings" pattern the repo's own exemption ledger warns against), and the SonarCloud quality gate. Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
arena-ai-coding-agent Bot
pushed a commit
that referenced
this pull request
Sep 29, 2026
…not running #78 resynced the lockfile and brought oikosbot.yml back, but CodeQL stayed at `startup_failure` with the same annotation: Invalid lockfile: .github/workflows/actions.lock#L1 The lockfile could not be validated. #78 kept the inline-SHA form in codeql.yml, and that is the remaining cause. With one commit changing two things, the evidence that separated them is clean: oikosbot.yml uses tag refs and went green on #78; codeql.yml uses inline SHAs and did not. GitHub validates actions.lock against what the workflows actually reference, so a SHA in the YAML that the lock records under a tag ref is drift, and the whole workflow is refused before any job starts. This is the same correction PR #39 made in the sibling repository, where CodeQL went from startup_failure to scanning on the merge commit. Changes: * codeql.yml: `actions/checkout@v7.0.1` and `github/codeql-action/{init,analyze}@v4.38.1`, with actions.lock holding the commits (sha1-3d3c42e5…, sha1-1c5b6756…). The lock needed no change — its per-workflow entry already named exactly these refs. Matches the NOSONAR pin-authority convention already used in oikosbot.yml and dogfood-gate.yml here, and the rule progblocks records in its AGENTS.md: "do not re-inline action SHAs that .github/workflows/actions.lock already owns". `persist-credentials: false` is kept: it is the actual security control, and it is independent of how the ref is spelled. * tests/unit/ci_configuration_test.ts and tests/unit/foundation_ci_config_test.ts: three assertions demanded an inline SHA in codeql.yml. That requirement is what produced the broken form, so it is replaced by the invariant that actually protects the workflow — every ref codeql.yml uses must be recorded in the lock's codeql.yml entry, and each must resolve to an immutable 40-character commit. Both suites are rewritten to be strictly stronger than before, not weaker: they now also assert the lock's own commits are immutable SHAs, which the previous versions never checked. * The same files' hard-coded "reviewed" standards revisions (8f31a5a4, cc58c0cb, 8750b94a) are corrected to fad242d, the revision the workflows actually call. All three were unreachable — each returns "No commit found" from the standards API — and 8750b94a is not a commit at all: it is the blob id of scorecard-reusable.yml at standards 1f3eef6, the same dead pin that kept the sibling repository's Scorecard from running. A hard-coded expectation is a safety net only while it is true. Why this was not caught: these two Deno suites are not wired into any CI job. They were already failing when #76 landed, and nothing reported it. Verified: lockfile audit reports zero drift between every workflow and actions.lock; every assertion in both suites replayed against the new files and passes; aspect tests 5/5 with 20 badge-contract assertions. Still red and not addressed here: the Hypatia scan and baseline-validation jobs (the scanner exits before writing its SARIF, so the findings cannot be read without running it — adding baseline entries blind is the "silently absorb findings" pattern the repo's own exemption ledger warns against), and the SonarCloud quality gate. Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
arena-ai-coding-agent Bot
pushed a commit
that referenced
this pull request
Sep 29, 2026
…not running #78 resynced the lockfile and brought oikosbot.yml back, but CodeQL stayed at `startup_failure` with the same annotation: Invalid lockfile: .github/workflows/actions.lock#L1 The lockfile could not be validated. #78 kept the inline-SHA form in codeql.yml, and that is the remaining cause. With one commit changing two things, the evidence that separated them is clean: oikosbot.yml uses tag refs and went green on #78; codeql.yml uses inline SHAs and did not. GitHub validates actions.lock against what the workflows actually reference, so a SHA in the YAML that the lock records under a tag ref is drift, and the whole workflow is refused before any job starts. This is the same correction PR #39 made in the sibling repository, where CodeQL went from startup_failure to scanning on the merge commit. Changes: * codeql.yml: `actions/checkout@v7.0.1` and `github/codeql-action/{init,analyze}@v4.38.1`, with actions.lock holding the commits (sha1-3d3c42e5…, sha1-1c5b6756…). The lock needed no change — its per-workflow entry already named exactly these refs. Matches the NOSONAR pin-authority convention already used in oikosbot.yml and dogfood-gate.yml here, and the rule progblocks records in its AGENTS.md: "do not re-inline action SHAs that .github/workflows/actions.lock already owns". `persist-credentials: false` is kept: it is the actual security control, and it is independent of how the ref is spelled. * tests/unit/ci_configuration_test.ts and tests/unit/foundation_ci_config_test.ts: three assertions demanded an inline SHA in codeql.yml. That requirement is what produced the broken form, so it is replaced by the invariant that actually protects the workflow — every ref codeql.yml uses must be recorded in the lock's codeql.yml entry, and each must resolve to an immutable 40-character commit. Both suites are rewritten to be strictly stronger than before, not weaker: they now also assert the lock's own commits are immutable SHAs, which the previous versions never checked. * The same files' hard-coded "reviewed" standards revisions (8f31a5a4, cc58c0cb, 8750b94a) are corrected to fad242d, the revision the workflows actually call. All three were unreachable — each returns "No commit found" from the standards API — and 8750b94a is not a commit at all: it is the blob id of scorecard-reusable.yml at standards 1f3eef6, the same dead pin that kept the sibling repository's Scorecard from running. A hard-coded expectation is a safety net only while it is true. Why this was not caught: these two Deno suites are not wired into any CI job. They were already failing when #76 landed, and nothing reported it. Verified: lockfile audit reports zero drift between every workflow and actions.lock; every assertion in both suites replayed against the new files and passes; aspect tests 5/5 with 20 badge-contract assertions. Still red and not addressed here: the Hypatia scan and baseline-validation jobs (the scanner exits before writing its SARIF, so the findings cannot be read without running it — adding baseline entries blind is the "silently absorb findings" pattern the repo's own exemption ledger warns against), and the SonarCloud quality gate. Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.com>
hyperpolymath
added a commit
that referenced
this pull request
Sep 29, 2026
…not running (#79) ## What this changes #78 resynced `actions.lock` and brought **oikosbot.yml** back. **CodeQL is still `startup_failure`** with the same annotation: > **Invalid lockfile:** `.github/workflows/actions.lock#L1` — The lockfile could not be validated. #78 kept the inline-SHA form in `codeql.yml`, and that is the remaining cause. GitHub validates `actions.lock` against what the workflows *actually reference*, so a SHA in the YAML that the lock records under a tag ref is drift, and the whole workflow is refused before any job starts. This is the same correction #39 made in the sibling repository, where CodeQL went from `startup_failure` to scanning on the merge commit. ## How the cause was isolated One commit changing two things is normally a poor experiment, but here the evidence separated them cleanly: | Workflow | Ref form | After #78 | |---|---|---| | `oikosbot.yml` | tag refs | ✅ `success` | | `codeql.yml` | inline SHAs | ❌ `startup_failure` | Same lockfile, same Actions enforcement — different ref form, different outcome. ## Changes - **`codeql.yml`** — `actions/checkout@v7.0.1` and `github/codeql-action/{init,analyze}@v4.38.1`, with `actions.lock` holding the commits (`sha1-3d3c42e5…`, `sha1-1c5b6756…`). The lock needed no change: its per-workflow entry already named exactly these refs. This matches the NOSONAR pin-authority convention already used in `oikosbot.yml` and `dogfood-gate.yml` in this repo, and the rule progblocks records in its `AGENTS.md`: *"do not re-inline action SHAs that `.github/workflows/actions.lock` already owns"*. `persist-credentials: false` is kept — it is the actual security control, and it is independent of how the ref is spelled. - **The two Deno suites** — three assertions demanded an inline SHA in `codeql.yml`. That requirement is what produced the broken form, so it is replaced by the invariant that actually protects the workflow: *every ref `codeql.yml` uses must be recorded in the lock's `codeql.yml` entry, and each must resolve to an immutable 40-character commit.* Both suites are **strictly stronger** than before, not weaker — they now also assert the lock's own commits are immutable SHAs, which the previous versions never checked. - **The hard-coded "reviewed" standards revisions** (`8f31a5a4`, `cc58c0cb`, `8750b94a`) are corrected to `fad242d`, the revision the workflows actually call. All three were unreachable — each returns "No commit found" from the standards API — and **`8750b94a` is not a commit at all**: it is the *blob* id of `scorecard-reusable.yml` at standards `1f3eef6`, the same dead pin that kept the sibling repository's Scorecard from running. A hard-coded expectation is a safety net only while it is true. ## Why this was never caught These two Deno suites are **not wired into any CI job**. They were already failing when #76 landed, and nothing reported it. That is the deeper issue behind all three scanners being down at once: the tests that would have caught it exist, are correct in intent, and are never executed. ## How it was verified - Lockfile audit comparing every `uses:` in every workflow against `actions.lock` — **zero drift**. - **Every** assertion in both suites replayed against the new files — all pass. - `bash tests/aspect/aspect_tests.sh` — **5 passed, 0 failed**, 20 badge-contract assertions. **Caveat, stated plainly:** the `pull_request`-event checks cannot start for this change — the pushing actor is not permitted to trigger Actions workflows in this organisation, so PR-event runs report `startup_failure` with "Actor is not allowed to trigger Actions workflows". That is an actor policy, not a defect in the change, and it is why verification is quoted from local runs plus `push` runs on `main`, which do execute. The confirmation that matters is that CodeQL produces real analysis jobs on `main` after merge, the way it did in the sibling repo. ## Still red, deliberately not addressed - `scan / Hypatia Neurosymbolic Analysis` and `governance / Validate Hypatia Baseline` — the scanner exits 1 and never writes its SARIF, so the findings cannot be read without running it. Adding baseline entries blind is exactly the "silently absorb findings" pattern this repo's exemption ledger warns against. - `SonarCloud Code Analysis` — quality gate, Reliability Rating on new code. Co-authored-by: hyperpolymath <6759885+hyperpolymath@users.noreply.github.com> Co-authored-by: arena-agent <297053741+arena-agent@users.noreply.github.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.
What this changes
The CodeQL security scanner has not been running on
mainsince PR #76 landed — and because a rejected workflow produces no checks at all, nothing in the checks list showed it.Both
CodeQL Security AnalysisandOikosBot Sustainability Analysisend in a zero-jobstartup_failurecarrying one annotation:Why
Drift between two files. PR #76 and the #77 Dependabot bump moved the workflows' refs —
codeql.ymlto the v4.38.1 commits,oikosbot.ymltoupload-sarif@v4.38.1— whileactions.lockstill recordedgithub/codeql-action@v4.38.0/b96794f0. GitHub refuses to start any workflow whose refs disagree with its lockfile:mainbefore this PRstartup_failure— not scanning at allstartup_failuregovernance / Actions lockfile verifyfailureThe lockfile-verify failure is the only one that appears as a red check. That is why two scanners being switched off was invisible.
Changes
actions.lock— recordgithub/codeql-action@v4.38.1→sha1-1c5b675653bb5c22dbe9b12b556ec555138e09fd(verified against the upstreamv4.38.1tag) in both the per-workflow list and the dependency table. Every tag-pinned entry in the file was re-resolved against GitHub and matches;hyperpolymath/k9-ecosystem@mainis a branch ref and is expected to trail main's tip.codeql.yml— the# v3comments on two v4.38.1 commits were false, and they are load-bearing:ci_configuration_test.tsuses that comment as theactions.lockkey and asserts the two agree, so# v3resolved to a dependency entry that does not exist. Corrected to# v4.38.1.persist-credentials: falseis kept — that is the actual security control.frontend/package-lock.json— deleted. A trackedpackage-lock.jsonfails the estate npm-avoidant gate, which is whygovernance / Language / package anti-pattern policyis red. Nothing references the file andfrontend/bun.lockis the live lock for the same dependencies; it was an npm-era leftover..github/funding.yml— deleted, keeping the tracked uppercase.github/FUNDING.yml. Both were tracked and contradicted each other (metadatasticianvshyperpolymath+ko_fi+liberapay), and on a case-insensitive filesystem a clone cannot hold both: one silently overwrites the other and the working tree is dirty on arrival. The uppercase file is the one GitHub reads and the one matching the live sponsor configuration, so its content is kept — the same ruling applied inberrywiki#30andprogblocks#30. Delete and add land in one commit so a case-insensitive checkout applies it atomically.How it was verified
bash tests/aspect/aspect_tests.sh— 5 passed, 0 failed, including 20 badge-claim contract assertions.uses:in every workflow against the lock's per-workflow and dependency tables reports zero drift (it reported drift in exactlycodeql.ymlandoikosbot.ymlbefore).actions.lockre-resolved against the GitHub API:ref→commitmatches for all 17 pinned entries.ci_configuration_test.tsandfoundation_ci_config_test.tswere replayed against the new files — all pass.Worth knowing: those two suites were already failing before this PR. Three of the SHAs they hard-code as "reviewed" (
8f31a5a4,cc58c0cb,8750b94a) are no longer reachable from any ref inhyperpolymath/standards, and8750b94ais the same dead pin that left a sibling repository's Scorecard not running. They are not wired into CI, which is why the drift went unnoticed. That stale map is corrected in a separate PR so that no test is edited to accommodate this fix.Still red, and deliberately not addressed here
Each needs a judgement call, not a mechanical fix:
scan / Hypatia Neurosymbolic Analysisandgovernance / Validate Hypatia Baseline— the scanner exits 1 and its SARIF is never produced, so the findings cannot be read without running the scanner. Adding baseline entries blind is exactly the "silently absorb findings" pattern the repo's own exemption-ledger comments warn against.SonarCloud Code Analysis— quality gate, Reliability Rating on new code.Checklist