You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
ci(workflow-linter): look for SPDX in the leading comment block - #168
lint-workflows fails on main with ERROR: .github/workflows/<file>.yml missing SPDX header for all 38 workflows. The SPDX check reads only line 1. Dependabot's actions-lock bumps prepend # This workflow is managed by gh actions-lock. above the existing header, so every SPDX line is now on line 2 or later. Moving it back to the top would only last until the next bump.
Change
workflow-linter.yml: the "Check SPDX headers" step now accepts an SPDX-License-Identifier anywhere in the leading block of comment and blank lines, before the first YAML line. A file whose only SPDX line comes after YAML, or that has none, still fails.
Testing
I ran the step scripts locally against this branch:
SPDX check: exit 0.
Permissions check: exit 0.
Negative test: a file with no SPDX header and a file with SPDX after name: both fail.
The "Check SPDX headers" step only read line 1 of each workflow. Dependabot's
actions-lock bumps now prepend "# This workflow is managed by gh
actions-lock." above the existing header, so every workflow's SPDX line sits
on line 2 or later and lint-workflows fails on main ("missing SPDX header",
one error per file). Moving the SPDX line back to the top would last only
until the next Dependabot bump.
The check now accepts an SPDX-License-Identifier anywhere in the leading
block of comment and blank lines, before the first YAML line. A file whose
only SPDX line comes after YAML content, or that has none, still fails.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
Review was skipped as selected files did not have any reviewable changes.
Run configuration
Source mode: Auto
Repository: Unavailable
Branch: Unavailable
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: ASSERTIVE
Plan: Advanced
Run ID: f0e5e7bb-aaa2-4089-9cfc-7458896d2149
Commits
Reviewing files that changed from the base of the PR and between aee59c7 and c0617e4.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
No actionable comments were generated in the recent review.
Summary
Summary by CodeRabbit
Bug Fixes
SPDX header checks now recognize identifiers that appear after leading blank lines or comments, rather than checking only the first line. This makes validation more consistent for files with introductory comments while still stopping the search at the first non-comment, non-blank line.
The workflow’s SPDX header check now searches leading comment lines for an SPDX identifier. It skips blank lines and stops at the first non-comment, non-blank line.
Changes: SPDX Header Check
Layer / File(s)
Summary
Scan leading lines for SPDX identifier .github/workflows/workflow-linter.yml
The check searches leading comment lines for an SPDX identifier, skipping blank lines and stopping at the first non-comment, non-blank line.
No actionable merge-blocking risk remains in this change.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title states the main change: the workflow linter's SPDX check now looks for the identifier in the leading comment block. The raw summary and objectives confirm this matches the single changed lin…
Description check
The description explains the problem (Dependabot's actions-lock bump prepends a comment, so SPDX headers move off line 1 and lint-workflows fails on all 38 workflows), the change (SPDX accepted anywhe…
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Full details: Title check
Explanation
The title states the main change: the workflow linter's SPDX check now looks for the identifier in the leading comment block. The raw summary and objectives confirm this matches the single changed line in workflow-linter.yml. The title uses the 'ci(workflow-linter)' scope and is specific enough for a teammate scanning history.
Full details: Description check
Explanation
The description explains the problem (Dependabot's actions-lock bump prepends a comment, so SPDX headers move off line 1 and lint-workflows fails on all 38 workflows), the change (SPDX accepted anywhere in the leading comment and blank block), and the local testing. It directly relates to the changeset.
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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.
File: No configuration file from this repository applied
Commit: Unavailable
Layers: Organization UI
Review profile: ASSERTIVE
Plan: Advanced
Run ID: e6a0e6e5-d40f-428e-9f7c-6622377d2eb1
Commits
Reviewing files that changed from the base of the PR and between e436fd4 and 4c02e81.
Files selected for processing: 1
.github/workflows/workflow-linter.yml
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.
Recent review details
Context from checks skipped due to timeout: 4
GitHub Check: CodeRabbit
GitHub Check: semgrep-cloud-platform/scan
GitHub Check: Analyze (actions)
GitHub Check: Analyze (rust)
CI failures not shown inline: 10
GitHub Actions: ClusterFuzzLite PR fuzzing / 0_PR (address).txt: ci(workflow-linter): look for SPDX in the leading comment block
##[group]K9 Configuration Validation
Scanning . for K9 files (.k9, .k9.ncl)...
Found 10 K9 file(s)
Validating: ./config/build.k9.ncl
##[error]Missing K9 format marker. A .k9.ncl file needs a magic_number = "K9!" field, a K9! preamble line, or a K9 pedigree schema import/application/merge
Validating: ./config/rust-fmt.k9.ncl
##[error]Missing K9 format marker. A .k9.ncl file needs a magic_number = "K9!" field, a K9! preamble line, or a K9 pedigree schema import/application/merge
##[error]Pedigree block missing 'name' field (in pedigree.metadata.name or pedigree.name)
...
Validating: ./contractiles/self-validating/examples/setup-repo.k9.ncl
Validating: ./contractiles/self-validating/template-hunt.k9.ncl
Validating: ./contractiles/self-validating/template-kennel.k9.ncl
Validating: ./contractiles/self-validating/template-yard.k9.ncl
Validating: ./setup-dev-env.k9.ncl
##[error]Hunt-level K9 file must include a 'signature' or 'signature_required' field
...
Errors: 4
Warnings: 0
Strict mode: false
────────────────────────────────────────
##[endgroup]
##[error]K9 validation failed with 4 error(s)
##[error]Process completed with exit code 1.
GitHub Actions: Dogfood Gate / Validate K9 contracts: ci(workflow-linter): look for SPDX in the leading comment block
##[group]K9 Configuration Validation
Scanning . for K9 files (.k9, .k9.ncl)...
Found 10 K9 file(s)
Validating: ./config/build.k9.ncl
##[error]Missing K9 format marker. A .k9.ncl file needs a magic_number = "K9!" field, a K9! preamble line, or a K9 pedigree schema import/application/merge
Validating: ./config/rust-fmt.k9.ncl
##[error]Missing K9 format marker. A .k9.ncl file needs a magic_number = "K9!" field, a K9! preamble line, or a K9 pedigree schema import/application/merge
##[error]Pedigree block missing 'name' field (in pedigree.metadata.name or pedigree.name)
...
Validating: ./contractiles/self-validating/examples/setup-repo.k9.ncl
Validating: ./contractiles/self-validating/template-hunt.k9.ncl
Validating: ./contractiles/self-validating/template-kennel.k9.ncl
Validating: ./contractiles/self-validating/template-yard.k9.ncl
Validating: ./setup-dev-env.k9.ncl
##[error]Hunt-level K9 file must include a 'signature' or 'signature_required' field
...
Errors: 4
Warnings: 0
Strict mode: false
────────────────────────────────────────
##[endgroup]
##[error]K9 validation failed with 4 error(s)
##[error]Process completed with exit code 1.
GitHub Actions: Dogfood Gate / 2_Empty-linter (invisible characters).txt: ci(workflow-linter): look for SPDX in the leading comment block
The Dogfood Gate's "Validate K9 contracts" job (k9-ecosystem/validate-action)
fails on main with four errors:
- config/build.k9.ncl, config/rust-fmt.k9.ncl: "Missing K9 format marker".
The K9! preamble sat on line 2, under the SPDX comment; the validator
requires it as the first non-empty line, which is how the contractiles
templates lay it out. K9! now comes first, SPDX second.
- config/rust-fmt.k9.ncl: "Pedigree block missing 'name' field". Both config
contracts now carry a pedigree name.
- setup-dev-env.k9.ncl: "Hunt-level K9 file must include a 'signature' or
'signature_required' field". It is a Hunt component (it runs installers
and shell commands), so its pedigree now declares signature_required =
true, as contractiles/self-validating/template-hunt.k9.ncl does.
The validator now reports 10 files scanned, 0 errors.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
(cherry picked from commit a94f3ea)
… build
ClusterFuzzLite fails in build_fuzzers on every PR, for three reasons:
- It runs `docker build -f .clusterfuzzlite/Dockerfile`, but the directory
only had a Containerfile. Add a Dockerfile that mirrors it (same pinned
base-builder-rust digest). The Containerfile stays for podman-first
local builds.
- build.sh copied targets from ./target/..., but cargo-fuzz writes them
to ./fuzz/target/x86_64-unknown-linux-gnu/release/. The copy failed with
"cannot stat".
- Once built, fuzz_parser reported a leak on its first input (a single
newline). The leak comes from nickel-lang-parser, which allocates AST
nodes in a bumpalo arena that never runs destructors, so strings in
those nodes always leak. Add fuzz_parser.options turning off leak
detection for libFuzzer and ASan, and have build.sh copy each target's
.options file to $OUT. ASan still reports memory-safety errors.
Verified locally with the same base image:
- The compile finishes and $OUT contains fuzz_parser.
- A 90-second fuzz run (615 executions) produced no crashes.
- With both leak switches off, the run exits 0 with no artifacts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
(cherry picked from commit 3f5120d)
SonarCloud failed this PR on a D security rating for new code:
- Dockerfile:10 "Copying recursively might inadvertently add sensitive
data to the container." `COPY . $SRC/bunsenite` sent the whole
checkout, .git included, into the build image.
- build.sh:13 "Use '[[' instead of '['".
The image now copies only what the fuzz build reads:
- Cargo.toml and Cargo.lock
- src/
- benches/ (declared as [[bench]] targets)
- crates/ (the patched nickel-lang-vector)
- fuzz/
- .clusterfuzzlite/ (build.sh reads the per-target .options from there)
The Containerfile gets the same change, to stay in sync. Nothing in
these paths uses include_str!/include_bytes! on files outside them, and
`cargo metadata` resolves both manifests from that subset.
The "runs as root" warning stays as it is: the OSS-Fuzz base-builder
image needs root.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye
(cherry picked from commit bb33a7e)
SonarCloud (B security rating). The cause is a single hotspot that arrived with the ported ClusterFuzzLite commits: .clusterfuzzlite/Dockerfile:8, "might run with root". It is the same item already explained on #170. The OSS-Fuzz base-builder-rust image compiles into $OUT as root, so adding a USER line would break the fuzz build. The hotspot needs a maintainer to mark it "Safe" in SonarCloud. Once it is marked on #170, the same hotspot here and on #169 should clear too.
… build (#170)
## Summary
**ClusterFuzzLite PR fuzzing / PR (address)** fails on every PR,
including [#168](#168).
This PR fixes the three causes, in the order they surface.
## Changes
- **`.clusterfuzzlite/Dockerfile` (new).** `build_fuzzers` runs `docker
build -f .clusterfuzzlite/Dockerfile`, but the directory only had a
`Containerfile`.
- The new file mirrors the Containerfile, using the same pinned
`base-builder-rust` digest. This is the estate convention betlang and
jtv-lang already follow.
- The Containerfile stays for podman-first local builds.
- **`.clusterfuzzlite/build.sh`.**
- Copies the targets from
`./fuzz/target/x86_64-unknown-linux-gnu/release/`, where cargo-fuzz
writes them. The old path `./target/...` failed with `cannot stat`.
- Also copies each target's `.options` file to `$OUT`.
- **`.clusterfuzzlite/fuzz_parser.options` (new).** Turns off leak
detection for libFuzzer and ASan.
- Once built, `fuzz_parser` reported a leak on its first input, a single
newline.
- The leak comes from `nickel-lang-parser` 0.4.0. It allocates AST nodes
in a `bumpalo` arena, which never runs destructors (see the `AstAlloc`
docs in `src/ast/alloc.rs`), so strings in parsed literals always leak.
- Without this file, every fuzz run would report that upstream leak as a
crash. AddressSanitizer still reports memory-safety errors.
## Testing
I ran the compile locally in the same base image with
`FUZZING_LANGUAGE=rust` and `SANITIZER=address`:
- The build finished and `$OUT` contained `fuzz_parser`.
- A 90-second fuzz run (615 executions, about 13.4k coverage edges)
produced no crashes.
- With both leak switches off, the run exited 0 and wrote no artifacts.
- `bash -n build.sh` passes, and the options file parses as INI.
One thing to watch: the PR job has a 15-minute timeout. Locally the
compile took about 6 minutes and the run step fuzzes for 300 seconds, so
the margin is small.
---
_Generated by [Claude
Code](https://claude.ai/code/session_0132Cdz3iwk2QGKv2sUhhsye)_
---------
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
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.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
What was wrong
lint-workflowsfails onmainwithERROR: .github/workflows/<file>.yml missing SPDX headerfor all 38 workflows. The SPDX check reads only line 1. Dependabot's actions-lock bumps prepend# This workflow is managed by gh actions-lock.above the existing header, so every SPDX line is now on line 2 or later. Moving it back to the top would only last until the next bump.Change
workflow-linter.yml: the "Check SPDX headers" step now accepts anSPDX-License-Identifieranywhere in the leading block of comment and blank lines, before the first YAML line. A file whose only SPDX line comes after YAML, or that has none, still fails.Testing
I ran the step scripts locally against this branch:
name:both fail.Generated by Claude Code