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
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-allactions: 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.
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>
A rabbit checks each workflow line
Tags now mark the action sign
SHA pins hop out of sight
Permissions stay scoped and tight
Green paths guide the build tonight
✨ 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.
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
The PR is currently not up to standards according to Codacy and automated reviews. While it attempts to implement a dependency locking strategy using gh actions-lock, it introduces several critical issues that must be addressed before merging:
Functional Regression: The workflow-linter.yml is missing contents: read permissions, which will cause the checkout step to fail and break the CI pipeline.
Security Regression: The PR systematically replaces immutable commit SHAs with mutable version tags. This increases supply chain risk and directly conflicts with the project's existing security policies and automated linter logic.
Missing Artifact: The core file intended to manage these dependencies, .github/workflows/actions.lock, was not included in the provided diff, making it impossible to verify the locking implementation.
Linter Conflict: The updated tag-based format will cause the existing 'Check pinned actions' security gate to fail, as it specifically expects inline SHA comments.
About this PR
Systematic removal of full-length commit SHAs across all workflows violates the established security policy. While the goal is to use a lock file, the workflows should ideally maintain the SHA in the uses: field (or as a trailing comment) to ensure compatibility with existing security scanners and to provide defense-in-depth against tag-moving attacks.
The file .github/workflows/actions.lock is missing from this PR. Since this file is the central mechanism for the proposed dependency locking strategy and manual entries were mentioned in the description, it must be included for verification.
1 comment outside of the diff.github/workflows/workflow-linter.yml
line 53 ⚪ LOW RISK
Suggestion: The regex uses:.*@v[0-9] combined with grep -v '#' will now flag all updated workflows as 'unpinned' despite them being tracked in the lock file. The linter logic needs to be updated to account for the actions.lock file to avoid constant CI warnings.
Test suggestions
Validate that the permissions block in workflow-linter.yml is valid YAML and permits the 'actions: read' mapping.
Verify that all modified workflow files have the SPDX header on line 1 and the tool banner on line 2.
Verify that the actions.lock file contains entries for all workflows, including manual caller-path entries as specified in Step 4.
Confirm that the 'Check pinned actions' step in the linter still functions or is updated for the new locking strategy.
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that the actions.lock file contains entries for all workflows, including manual caller-path entries as specified in Step 4.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
This PR systematically removes immutable commit SHAs. While updating to specific version tags is useful for readability, the loss of the SHA pin creates a supply chain security risk. Ensure your configuration maintains SHAs in the uses: field to satisfy local security requirements.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Avoid removing the commit SHA when updating actions. Pinning to a full-length commit SHA is the only way to ensure the action used is immutable and protected against upstream tampering.
The reason will be displayed to describe this comment to others. Learn more.
🔴 HIGH RISK
Do not pin actions to a branch like @main. This makes your workflow non-deterministic and vulnerable to malicious or breaking changes in the source repository. Always use a full-length commit SHA.
Try running the following prompt in your IDE agent:
Find the latest commit SHA for the repository hyperpolymath/a2ml-ecosystem/validate-action and replace '@main' with that SHA in .github/workflows/dogfood-gate.yml.
The reason will be displayed to describe this comment to others. Learn more.
🟡 MEDIUM RISK
This change replaces a pinned commit SHA with a mutable version tag. This reduces security (as tags can be moved) and violates the project's policy of pinning actions with SHAs. Revert to the action@SHA # version format to comply with the local security linter.
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.
![codacy-production[bot]](https://avatars.githubusercontent.com/in/56611?s=60&v=4){kind=small}
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