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
{{ message }}
Repository navigation
Feedback: A broken action.lock file causes it to be ignored #125
I was surprised dependabot was able to suddenly update my actions without workflows failing, turned out I had somehow pushed a broken action lock file:
@jessehouwing this one is tricky if we fail closed here we impact all workflows even those not onboarded and because the lockfile is broken we cannot reliably read it. The Require lockfile policy is what gets you fail closed behavior, we know all workflows are onboarded and can hard fail. I think we need some additional docs to help make this clear and some nudging to adopt that policy.
2. @jessehouwing this one is tricky if we fail closed here we impact all workflows even those not onboarded and because the lockfile is broken we cannot reliably read it. The Require lockfile policy is what gets you fail closed behavior, we know all workflows are onboarded and can hard fail. I think we need some additional docs to help make this clear and some nudging to adopt that policy.
I'd at least expect a warning in every workflow that might have been covered by that lockfile.
Better yet, a manual approval to run.
And are there plans to report on corrupt lock files anywhere? The fact that for example bad code owners files can't be centrally detected at account or org level makes it really hard to find these issues and fix them.
I can't really run an action workflow that runs gh actions-lock -verify either, since the corrupt lock file would prevent it from running. Along those lines... Is there a PR check yet that scans lock files for corruptions?
@nodeselector I realize this may not be the right place for this feedback, but it’s related to the reporting concerns above.
With the Require lockfile policy enabled, policy failures are difficult to discover. The PR shows required checks as “Expected — Waiting for status to be reported,” suggesting CI hasn’t started rather than that execution is blocked.
To find the reason, users have to open Checks, select the affected workflow, and find the error under Annotations, below an empty workflow graph.
Are there plans to surface the policy failure and remediation directly in the PR checks summary?
Activity
nodeselector commentedon Oct 15, 2026
@jessehouwing this one is tricky if we fail closed here we impact all workflows even those not onboarded and because the lockfile is broken we cannot reliably read it. The
Require lockfilepolicy is what gets you fail closed behavior, we know all workflows are onboarded and can hard fail. I think we need some additional docs to help make this clear and some nudging to adopt that policy.jessehouwing commentedon Oct 16, 2026
I'd at least expect a warning in every workflow that might have been covered by that lockfile.
Better yet, a manual approval to run.
And are there plans to report on corrupt lock files anywhere? The fact that for example bad code owners files can't be centrally detected at account or org level makes it really hard to find these issues and fix them.
I can't really run an action workflow that runs
gh actions-lock -verifyeither, since the corrupt lock file would prevent it from running. Along those lines... Is there a PR check yet that scans lock files for corruptions?[-]A broken action.lock file causes it to be ignored[/-]MathieuSevegny commentedon Oct 26, 2026
@nodeselector I realize this may not be the right place for this feedback, but it’s related to the reporting concerns above.
With the
Require lockfilepolicy enabled, policy failures are difficult to discover. The PR shows required checks as “Expected — Waiting for status to be reported,” suggesting CI hasn’t started rather than that execution is blocked.To find the reason, users have to open Checks, select the affected workflow, and find the error under Annotations, below an empty workflow graph.
Are there plans to surface the policy failure and remediation directly in the PR checks summary?
nodeselector commentedon Oct 26, 2026
@MathieuSevegny can you open a dedicated issue for this? 🙇