fix(ci): unbreak workflow YAML and add a complete actions.lock - #61
Conversation
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>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (16)
📝 WalkthroughSummary by CodeRabbit
WalkthroughChangesGitHub Actions workflow updates
Estimated code review effort: 2 (Simple) | ~10 minutes Poem
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
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 |
|
Up to standards ✅🟢 Issues
|
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
There was a problem hiding this comment.
Pull Request Overview
While the PR is up to quality standards according to Codacy, there is a significant logic issue in the permission configuration: job-level permission blocks in workflows like 'hypatia-scan.yml' are shadowing the newly added workflow-level 'actions: read' permission, which will likely cause failures in reusable workflow calls.
Additionally, the automation used to manage the 'actions.lock' has introduced redundant header comments across multiple files. Please verify the idempotency of the locking tool. Note that several acceptance criteria, including the restoration of the 'SPDX-License-Identifier' to the first line and repository-wide version consistency, are currently unverified or missing in the implementation.
About this PR
- The management banner ('# This workflow is managed by gh actions-lock.') is being duplicated across several files (e.g., boj-build.yml, mirror.yml). The tool used to generate these updates should be checked for idempotency to avoid cluttered YAML headers.
Test suggestions
- Verify that the SPDX-License-Identifier is on line 1 for all workflow files.
- Validate that all workflows calling reusable workflows contain the 'actions: read' permission.
- Ensure no workflow file contains duplicate management comment lines.
- Check that all instances of 'actions/checkout' use a consistent version across the repository.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that the SPDX-License-Identifier is on line 1 for all workflow files.
2. Validate that all workflows calling reusable workflows contain the 'actions: read' permission.
3. Ensure no workflow file contains duplicate management comment lines.
4. Check that all instances of 'actions/checkout' use a consistent version across the repository.
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
| workflow_dispatch: | ||
|
|
||
| permissions: | ||
| actions: read |
There was a problem hiding this comment.
🟡 MEDIUM RISK
The workflow-level 'actions: read' permission is ignored by this job because it defines its own permissions block. To fix this, move 'actions: read' into the job-level permissions block starting at line 21.
| @@ -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. | |||
There was a problem hiding this comment.
⚪ LOW RISK
Nitpick: Duplicate banner found. Line 2 and Line 3 are identical. Please ensure the locking tool is idempotent.
| @@ -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. | |||
There was a problem hiding this comment.
⚪ LOW RISK
Nitpick: Duplicate management comment. Line 2 already contains the banner '# This workflow is managed by gh actions-lock.'. Please remove the redundant line.
1 participant
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 → 0startup_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:This reaches past the one file:
gh actions-lockrefuses 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
standardsreusables off commits with noactions.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>': [].P(startup_failure | has lockfile) = 91.7%vs15.8%without — because every workflow a lockfile omits is rejected. A partial lock is worse than none. Runninggh actions-lockand stopping there is how this outage spread.5. Restore
SPDX-License-Identifierto line 1, which the tool displaces with its own banner and which the workflow-security linter greps viahead -1.Verified before this PR was opened
0unparseable 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