fix(ci): repair workflows made unparseable by a blind permissions insertion - #89
Conversation
…ertion
These workflow files are not valid YAML, so they have NEVER run. GitHub
Actions rejects the file before creating any job: the run is recorded as
`failure` with no jobs, no log and no check run, and `gh pr checks` shows no
row at all. A red mark with nothing behind it to read.
The cause is a sweep that added permission declarations by LINE POSITION
rather than by parsing the document. Two invalid shapes resulted.
permissions: read-all
actions: read <- a mapping indented under a SCALAR value
`read-all` is a scalar and cannot take children. It also already grants
everything `actions: read` would, so the orphaned line is dropped and nothing
is lost.
on:
permissions: contents: read <- two colons on one line, and
push: `permissions` is not a valid key here
Dropped entirely.
VERIFIED, not assumed. Every workflow in this repository parses after the
change, and the repairer refuses to write any file that does not parse and
still contain jobs afterwards. Where a job-level permissions line was removed,
a top-level `permissions:` remains and is read-only, so nothing is widened —
and if none remained the tool reports that rather than inventing one, because
guessing a permission set is how you silently over-grant.
ESTATE CONTEXT: 67 repositories and 100 workflow files are in this state.
The most frequently broken file is workflow-linter.yml, in 22 repositories —
the workflow whose job is to lint workflows was itself unparseable, so it
never ran and never caught this.
Detection is being added upstream so it cannot recur invisibly: a strict YAML
loader in the governance reusable (hyperpolymath/standards#582). Ordinary
validation cannot see this class of fault, because yaml.safe_load accepts
duplicate keys and only a full parse catches the malformed indentation.
EXPECT THIS REPOSITORY TO GET LOUDER. Workflows that have been failing
silently will now actually run, and some will find real problems.
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 ✅ ApprovedRepairs malformed YAML syntax in GitHub Actions workflows caused by broken permission block insertions, restoring valid parsing and execution. No issues found.
OptionsDisplay: compact → Showing less information. Comment with these commands to change the behavior for this request:
Important Your trial ends in 4 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}
1 participant
These workflow files are not valid YAML, so they have never run. Not "ran and failed" — never ran. GitHub Actions rejects the file before creating any job: the run is recorded as
failurewith no jobs, no log and no check run, andgh pr checksshows no row at all. A red mark with nothing behind it to read.Cause
A sweep added permission declarations by line position rather than by parsing the document. Three invalid shapes resulted:
A — a mapping indented under a scalar value
read-allalready grants everythingactions: readwould, so the orphaned line is dropped and nothing is lost.B — injected inside another block
C — a literal
\nthat was never interpreted, gluing the escape'snto the key:Only a text-level writer emitting an uninterpreted escape can produce that.
Verified, not assumed
Every workflow in this repository parses after the change. The repairer refuses to write any file that does not parse and still contain jobs afterwards.
Where a job-level
permissions:line was removed, a read-only top-levelpermissions:remains, so nothing is widened — and if none would remain, the tool reports that rather than inventing one. Guessing a permission set is how you silently over-grant.Estate context
67 repositories and 100 workflow files are in this state. The most frequently broken file is
workflow-linter.yml, in 22 repositories — followed byscorecard.yml(20) anddogfood-gate.yml(13).The workflow whose job is to lint workflows was itself unparseable, so it never ran, and never caught this or anything else. The check that would have found the damage was destroyed by the same sweep that caused it.
So it cannot recur invisibly
Detection is being added upstream: a strict-YAML check in the governance reusable — hyperpolymath/standards#582. Ordinary validation cannot see this class of fault, because
yaml.safe_loadsilently accepts duplicate keys and only a full parse catches the malformed indentation.Expect this repository to get louder
Workflows that have been failing silently will now actually run, and some will find real problems that have been invisible for as long as the files have been broken.
🤖 Generated with Claude Code