Skip to content

fix(ci): unbreak workflow YAML and add a complete actions.lock - #104

Merged
hyperpolymath merged 1 commit into
mainfrom
fix/workflow-dependency-locking
Aug 27, 2026
Merged

fix(ci): unbreak workflow YAML and add a complete actions.lock#104
hyperpolymath merged 1 commit into
mainfrom
fix/workflow-dependency-locking

Conversation

@hyperpolymath

Copy link
Copy Markdown
Owner

Remediates GitHub Workflow Dependency Locking (public preview, no changelog entry), which rejects runs at startup_failure — zero jobs, no logs, nothing in REST or GraphQL. Full analysis: hyperpolymath/standards#657.

Proven on hyperpolymath/anamnesis: 6 of 6 workflows dead → 0 startup_failure, 13 running.

Five steps, in order — each blocks the next

1. Unbreak the workflow YAML. Any permissions: carrying a scalar with an indented mapping under it:

permissions: read-all
  actions: read        # <- mapping under a scalar. Unparseable.

This reaches past the one file: gh actions-lock refuses to run when any workflow in the repo fails to parse, so the repo can never acquire a lockfile and can never self-heal.

2. Repin standards reusables off commits with no actions.lock. The rejection requires the callee to be covered at the pinned SHA — unsatisfiable at a pre-lockfile commit.

3. Generate the lockfile with gh actions-lock.

4. Hand-add the reusable-caller entries the tool omits, as '<path>': [].

⚠️ Measured across 218 repos: P(startup_failure | has lockfile) = 91.7% vs 15.8% without — because every workflow a lockfile omits is rejected. A partial lock is worse than none. Running gh actions-lock and stopping there is how this outage spread.

5. Restore SPDX-License-Identifier to line 1, which the tool displaces with its own banner and which the workflow-security linter greps via head -1.

Verified before this PR was opened

0 unparseable workflows · lockfile covers every workflow, no omissions · SPDX on line 1 in every file. The script refuses to push if any of the three fails.

🤖 Generated with Claude Code

Remediates GitHub Workflow Dependency Locking (public preview), which
rejects runs at startup_failure with zero jobs and no logs. See
hyperpolymath/standards#657.

Five steps, in order, because each blocks the next:

1. Unbroke any workflow whose `permissions:` carried a scalar with an
   indented mapping under it - blind-permissions-insertion damage. This
   matters beyond the one file: gh actions-lock refuses to run when ANY
   workflow in the repo fails to parse, so the repo could never acquire a
   lockfile and could never self-heal.

2. Repinned hyperpolymath/standards reusables off commits that have no
   actions.lock. The rejection requires the CALLEE to be covered at the
   pinned SHA, which is unsatisfiable at a pre-lockfile commit.

3. Generated the lockfile with gh actions-lock.

4. Hand-added the reusable-workflow caller entries the tool omits, as
   '<path>': []. Measured across 218 repos: P(startup_failure | has
   lockfile) = 91.7% vs 15.8% without, because every workflow a lockfile
   OMITS is rejected. A PARTIAL lock is worse than none - running
   gh actions-lock and stopping there is how this outage spread.

5. Restored SPDX-License-Identifier to line 1, which the tool displaces
   with its own banner and which the workflow-security linter greps with
   head -1.

Verified before push: 0 unparseable workflows, lockfile covers every
workflow with no omissions, SPDX on line 1 in every file.

Proven on hyperpolymath/anamnesis: 6 of 6 workflows dead -> 0
startup_failure, 13 running.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@hyperpolymath
hyperpolymath merged commit 84759fd into main Aug 27, 2026
1 check passed
@hyperpolymath
hyperpolymath deleted the fix/workflow-dependency-locking branch August 27, 2026 04:53
@coderabbitai

coderabbitai Bot commented Aug 27, 2026

Copy link
Copy Markdown

Review Change Stack

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: fdcb7142-55e4-4458-b494-347e1fe7b927

📥 Commits

Reviewing files that changed from the base of the PR and between 02415e2 and f193510.

⛔ Files ignored due to path filters (1)
  • .github/workflows/actions.lock is excluded by !**/*.lock
📒 Files selected for processing (19)
  • .github/workflows/cargo-audit.yml
  • .github/workflows/casket-pages.yml
  • .github/workflows/cflite_batch.yml
  • .github/workflows/cflite_pr.yml
  • .github/workflows/codeql.yml
  • .github/workflows/comprehensive-quality.yml
  • .github/workflows/governance.yml
  • .github/workflows/hypatia-scan.yml
  • .github/workflows/jekyll-gh-pages.yml
  • .github/workflows/mirror.yml
  • .github/workflows/pages.yml
  • .github/workflows/proofs.yml
  • .github/workflows/push-email-notify.yml
  • .github/workflows/release.yml
  • .github/workflows/scorecard.yml
  • .github/workflows/secret-scanner.yml
  • .github/workflows/spark-theatre-gate.yml
  • .github/workflows/test.yml
  • .github/workflows/workflow-linter.yml

📝 Walkthrough

Summary by CodeRabbit

  • Chores

    • Standardised workflow metadata across automated checks and deployment processes.
    • Updated the email notification action to version 3.12.0.
    • Updated the Racket setup action used by testing and linting workflows.
    • Added the required read access for workflow actions in secret scanning.
  • Documentation

    • Cleaned up and aligned workflow management comments without changing normal workflow behaviour.

Walkthrough

The pull request updates GitHub Actions workflow headers and changes three workflow configurations: one permission entry, one mail action version, and two Racket setup action versions.

Changes

GitHub Actions workflow updates

Layer / File(s) Summary
Workflow management headers
.github/workflows/*.yml
Workflow files add, retain, or remove gh actions-lock management comments.
Workflow action and permission configuration
.github/workflows/secret-scanner.yml, .github/workflows/push-email-notify.yml, .github/workflows/test.yml
The secret scanner adds actions: read. The mail action changes to v3.12.0. Both Racket setup steps change to v1.9.1.

Estimated code review effort: 2 (Simple) | ~10 minutes

Poem

A rabbit checks each workflow line,

Headers hop into a tidy design.
Mail flies with a newer tag,
Racket steps follow the flag.
Permissions read, then all align.

✨ Finishing Touches 💡 1
🛠️ Fix failing CI checks 💡
  • Create stacked PR
  • Commit on current branch

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@gitar-bot

gitar-bot Bot commented Aug 27, 2026

Copy link
Copy Markdown

Important

You are using the Gitar free plan. Upgrade to unlock code review, CI analysis, auto-apply, custom automations, and more.

Gitar

@codacy-production

Copy link
Copy Markdown

Not up to standards ⛔

🔴 Issues 2 high

Alerts:
⚠ 2 issues (≤ 0 issues of at least minor severity)

Results:
2 new issues

Category Results
Security 2 high

View in Codacy

AI Reviewer: first review requested successfully. AI can make mistakes. Always validate suggestions.

Run reviewer

TIP This summary will be updated as you push new changes.

@codacy-production codacy-production Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

The Pull Request is currently not up to standards. While it successfully addresses YAML parsing errors and ensures the correct placement of SPDX license headers, it introduces systemic redundancy and a critical logic error in permission handling. Specifically, a header comment is duplicated across all modified workflow files. Furthermore, a workflow-level permission setting is rendered ineffective because it is overridden by job-level permissions in a reusable workflow configuration. Most significantly, the 'actions.lock' file mentioned in the PR description is missing from the diff, preventing verification of the manual dependency entries required for reusable-caller workflows.

About this PR

  • The .github/workflows/actions.lock file is missing from this Pull Request. The PR description indicates that this file should include manual entries for reusable-caller workflows that the tool omits; without this file, the implementation of the dependency locking mechanism cannot be verified.
1 comment outside of the diff
[REDACTED:HIGH_ENTROPY]

line 13 🟡 MEDIUM RISK
The actions: read permission defined at the workflow level will not be inherited by the scan job because the job specifies its own permissions block, which overrides global settings. To ensure the reusable workflow has the necessary access, move this permission into the job-level block.

Test suggestions

  • Verify YAML parsing for all modified workflows (no permissions block syntax errors).
  • Verify SPDX-License-Identifier is strictly on line 1 for all workflow files.
  • Verify actions.lock contains manual entries ('': []) for reusable callers omitted by the tool.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify actions.lock contains manual entries ('<path>': []) for reusable callers omitted by the tool.

TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback

@@ -1,5 +1,6 @@
# SPDX-License-Identifier: MPL-2.0
# This workflow is managed by gh actions-lock.
# This workflow is managed by gh actions-lock.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚪ LOW RISK

Nitpick: The comment '# This workflow is managed by gh actions-lock.' is duplicated on lines 2 and 3. This redundancy appears across multiple modified files in this PR and should be corrected to maintain a clean configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant