fix(ci): repair workflows made unparseable by a blind permissions ins… - #92
Merged
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>
|
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.
…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
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.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-allis a scalar and cannot take children. It also already grants everythingactions: readwould, so the orphaned line is dropped and nothing is lost.on:
permissions: contents: read <- two colons on one line, and
push:
permissionsis not a valid key hereDropped 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.
Summary
Closes #
Type of change
How has this been verified?
Checklist
git commit -S).SPDX-License-Identifier(code/configMPL-2.0,prose
CC-BY-SA-4.0); I did not relicense existing files.Notes for reviewers