fix(ci): complete actions.lock coverage — missing entries kill workflows at startup - #15
Conversation
…ows at startup In a repo with an actions.lock, EVERY workflow needs an entry. One that is absent is rejected before any job starts -- startup_failure with zero jobs, no log, no annotation. The counts matched exactly before this change, which is what identified the cause: coverage was short by precisely the number of workflows whose latest run was startup_failure. gh actions-lock does not generate entries for workflows whose only 'uses:' is a reusable workflow, so those are hand-added as '<path>: []', the form proven correct in reposystem (16/16 coverage, governance passing). Diagnosed against metadatastician-governance#24. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
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
This PR addresses critical CI startup failures caused by missing entries in actions.lock for workflows that rely exclusively on reusable workflows. While Codacy reports that the PR is up to standards, the primary changes in .github/workflows/actions.lock were not visible in the diff analyzed, which prevents verification of the 7 specific missing entries (6 for _pathroot and 1 for phi-LAM).
There is a significant implementation risk because this fix is manual. Without an automated CI check to enforce that all workflows are present in the lock file, future additions of reusable-only workflows will likely reintroduce the 'startup_failure' error. It is recommended to verify the syntax and presence of the new entries manually or through a script before merging.
About this PR
- The file '.github/workflows/actions.lock' was not available in the diff for review. Please verify that the 7 specific entries for '_pathroot' and 'phi-LAM' have been added using the correct
<path>: []format before merging. - The current fix is manual. Consider implementing a CI check or a pre-commit hook to ensure that every workflow in
.github/workflows/has a corresponding entry inactions.lockto prevent future startup failures.
Test suggestions
- Verify that every file in .github/workflows/ has a key in actions.lock
- Verify that entries for reusable-only workflows are formatted as an empty array []
Prompt proposal for missing tests
Consider implementing these tests if applicable:
1. Verify that every file in .github/workflows/ has a key in actions.lock
2. Verify that entries for reusable-only workflows are formatted as an empty array []
TIP Improve review quality by adding custom instructions
TIP How was this review? Give us feedback
1 participant
In a repo carrying an
actions.lock, every workflow needs an entry. One that is absent is rejected before any job starts —startup_failurewith zero jobs, no log, no annotation anywhere in the API.The counts identified the cause
startup_failureruns_pathrootphi-LAMCoverage was short by precisely the number of workflows failing. That exact match is what distinguishes this from the other three lockfile failure modes.
The fix
gh actions-lockdoes not generate entries for workflows whose onlyuses:is a reusable workflow — which is why these were missed. Hand-added as'<path>': [], the form proven correct inreposystem(16/16 coverage, governance passing).Diagnosed against metadatastician/metadatastician-governance#24, which reported 13 repos in this state at 05:21Z today. Re-checking now, most have since recovered — these two were the ones still showing a coverage gap.
🤖 Generated with Claude Code