Repository navigation
fix(ci): SPDX check accepts the licence after the actions-lock banner - #80
Merged
Merged
Conversation
`gh actions-lock` writes "# This workflow is managed by gh actions-lock." as the first line of every workflow it touches, which pushes the SPDX line to line 2. The linter only read line 1, so Workflow Security Linter has failed on every workflow since the actions group bump (#77). The check now looks for the SPDX line anywhere in the leading comment block, before the workflow body. This is the rsr-template-repo check (0afa6c9, #237) copied unchanged; standards' governance check works the same way. No workflow header changes. Tested: passes on main's 20 workflows; on planted files it passes SPDX on line 1 or after the banner, and fails no SPDX and SPDX below `name:`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y6FD63UrriRBHqmhhEca9t
Contributor
|
Note Currently processing new changes in this PR. This may take a few minutes, please wait... ⚙️ Run configuration
📒 Files selected for processing: 1
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
marked this pull request as ready for review
October 19, 2026 21:47
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. |
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
hyperpolymath
enabled auto-merge (squash)
October 19, 2026 21:47
Owner
Author
|
CI at fdf8e61: none of the failing checks comes from this PR's change. They are main's own failures, and each one is fixed in another PR:
I haven't copied those fixes into this PR; see my note to the owner about merge order. I haven't re-run anything: these failures are deterministic. Generated by Claude Code |
Contributor
|
Add Carrot credits or activate Agent usage billing to use Autofix |
hyperpolymath
added a commit
that referenced
this pull request
Oct 20, 2026
## Summary On main, `network-repair --help` exits 1 on every distribution in Distribution Matrix Tests and in Tests: ``` src/main.sh: line 17: .../src/utils/utils/privileges.sh: No such file or directory ``` Every module that `src/main.sh` sources starts by assigning the global `SCRIPT_DIR` to its own directory. That covers `utils/logging.sh` and everything in `diagnostics/` and `repairs/`. Once main.sh has sourced `utils/logging.sh`, `SCRIPT_DIR` is `src/utils`, so main.sh's next `source` resolves under `src/utils/utils/`. ## Changes - **8800119.** Each sourced module resolves the directory it needs into its own name and leaves `SCRIPT_DIR` to `main.sh`: - `NR_UTILS_DIR` is always `src/utils`, whichever module sets it. - `repairs/routing.sh` sets `NR_REPAIRS_DIR`, because two of its functions re-source `interfaces.sh` at run time. - **7895d9c** (CodeRabbit): - Diagnostics that find issues no longer abort `diagnose` under `set -e`. - The safe-mode test reads `diagnose`'s output once. - The colour test accepts empty colours when stdout is not a terminal. - Two ShellCheck warnings are fixed. - **45da73d** (CodeRabbit): comments in `repairs/routing.sh`. - **4270e56:** a regression test. Sourcing any module from a fresh shell must leave the caller's `SCRIPT_DIR` alone. The test fails on main. ## Testing | Check | main | this PR | |---|---|---| | `./network-repair --help` / `--version` | exit 1 | exit 0 | | `tests/run-tests.sh` | 20/25 | 25/25 | | `tests/test-utils.sh` | fails | passes | | `shellcheck -S warning` on `src/` | 2 warnings | clean | | CI: Unit Tests, ShellCheck, Integration (ubuntu 20.04/22.04/24.04, debian:12), most distro jobs | red | green | ## Still red here, fixed elsewhere - `lint-workflows`: fixed by #80 (SPDX) and #81 (pinning). - Debian 11, Rocky/Alma 9 and openSUSE installs: fixed by #82. - `scan / *` and `hypatia`: these need the estate re-pin of the standards workflows (75bd599). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Y6FD63UrriRBHqmhhEca9t --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
hyperpolymath
disabled auto-merge
October 20, 2026 12:35
|
hyperpolymath
added a commit
that referenced
this pull request
Oct 20, 2026
## Why Workflow Security Linter's "Check SHA-Pinned Actions" step requires an inline 40-hex SHA on every `uses:` line. This repository pins its actions with tag refs that `actions.lock` resolves, so the step rejects every one of them. That keeps the linter red on main whatever else it finds. This is the second failing step, after the SPDX check that #80 fixes. ## What - The step now runs `scripts/check-action-pinning.js`, copied unchanged from rsr-template-repo (ec33724). A ref passes when it is an inline SHA or when `actions.lock` resolves it. - The script runs under Bun 1.4.2, the estate pin. A new "Install verified Bun 1.4.2" step downloads it from the release archive and checks its sha256, as hyperpolymath/rsr-template-repo#249 now does in the template. - bf2a196 first used the template's `oven-sh/setup-bun@v2.2.0` with `bun-version: latest`. SonarCloud failed this PR on that tag-pinned third-party action ("C Security Rating"), and the runtime was unpinned. 9d13eba replaces it, on the owner's call. - `actions.lock` is unchanged from main. - One change from the template: the example in the error message now labels `actions/checkout@3d3c42e…` as v7.0.1, which is what this repository's lock records. The template says v6.0.1. ## Tested - The script passes on this branch's workflows: "all action refs are pinned". - It fails on a planted `uses: some-org/unlocked-action@v1`. - I extracted the Bun step from the workflow and ran it with a scratch `RUNNER_TEMP` whose path contains a space. The checksum printed `OK` and `bun --version` prints `1.4.2`. - standards' `validate-actions-lock.sh` (75bd599) passes on the lock. ## Merge order The owner's order is #79 → #82 → #80 → #81 → #78. This PR and #80 change different steps of the same workflow, so they don't conflict. The linter goes fully green only once both are in. scan and hypatia also need the estate re-pin to standards `75bd599`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Y6FD63UrriRBHqmhhEca9t --------- Co-authored-by: Claude <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
2 participants
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.
Why
gh actions-lockwrites# This workflow is managed by gh actions-lock.as the first line of every workflow it touches, which moves the SPDX line to line 2. Workflow Security Linter only reads line 1, so since the actions group bump (#77) it has failed on main and on every PR.What
The "Check SPDX Headers" step now looks for the SPDX line anywhere in the leading comment block, before the workflow body. The step is the rsr-template-repo check (0afa6c9, rsr-template-repo#237) copied unchanged. standards' governance check (
governance-reusable.yml, "Check SPDX headers + permissions") also reads the whole header block.No workflow header is changed: licence headers are edited only by the owner.
Tested
name:.Still failing after this
The next step, "Check SHA-Pinned Actions", also fails on main. It requires an inline 40-hex SHA. This repository pins with tag refs that
actions.lockresolves, so the step rejects all of them.The template fixed this with
scripts/check-action-pinning.js, a Bun script that reads the lock. Porting it means addingoven-sh/setup-bunto this workflow and toactions.lock. That is a larger change than this PR, so it is left for the owner to decide.Generated by Claude Code