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
Feature request: How should composite actions lock themselves? #183
This is somewhat related to #139 (comment) and has come up while I'm working on zizmor's support for lockfiles.
TL;DR: lockfiles are currently workflow-oriented, with reusable workflows as a documented limitation. But how should repos that contain composite actions pin their dependencies?
For example, in zizmor-action, we use the upload-serif action:
As is, lockfiles leave these kinds of composite actions with a bit of a gap:
We can switch back to ref-pinning, and let downstream users lock as part of their resolution. However, this degrades the integrity/immutability property for users who haven't adopted lockfiles yet (or can't for whatever reason).
We can keep hash-pinning our dependencies in the "old" way, but this is now out of sync with the idiom that's being established for locking workflows. In particular this means that tools like zizmor will need to have two pathways: a lockfile pathway for workflows, and a "you still have to do it the old way" for composite actions.
AFAICT this could be handled by allowing composite actions in the current lockfile format as well (keyed by repo-relative path?), and then having gh actions-lock honor the downstream lockfile when present/merge it into the upstream lockfile.
Alternatively it would be solved by the "intrinsic" idea in #139 (comment), since composite action definitions could grow similar dedicated syntax for pinning, etc.
Yeah, I think realistically there's a large tail of actions that won't or can't (for good or bad reasons) use immutable releases. If everything was immutable already there'd arguably be no need for lockfiles for workflows either 🙂
3. Yeah, I think realistically there's a large tail of actions that won't or can't (for good or bad reasons) use immutable releases. If everything was immutable already there'd arguably no need for lockfiles for workflows either 🙂
I hope the runner will start issueing warnings at some point. A little more coercion wouldn't be that bad ;).
We plan on coming back to this as a part of improving the publisher side of the supply chain. Unfortunately, the best way forward for composite actions today is to continue to sha pin. We haven't committed to a design and will include the community in the process as we start working on it. Sorry for the awkwardness here, you describe the predicament perfectly.
Reacted by William Woodruff, François Proulx and Masayuki Matsuki
Activity
jessehouwing commentedon Oct 19, 2026
These should ideally be pinned to an immutable release tag. But that's another wave of change hitting the actions' ecosystem.
woodruffw commentedon Oct 19, 2026
Yeah, I think realistically there's a large tail of actions that won't or can't (for good or bad reasons) use immutable releases. If everything was immutable already there'd arguably be no need for lockfiles for workflows either 🙂
jessehouwing commentedon Oct 19, 2026
I hope the runner will start issueing warnings at some point. A little more coercion wouldn't be that bad ;).
nodeselector commentedon Oct 20, 2026
We plan on coming back to this as a part of improving the publisher side of the supply chain. Unfortunately, the best way forward for composite actions today is to continue to sha pin. We haven't committed to a design and will include the community in the process as we start working on it. Sorry for the awkwardness here, you describe the predicament perfectly.
jessehouwing commentedon Oct 20, 2026
The best wat is to pin to immutable releases. Barring those, Sha pinning.
[-]How should composite actions lock themselves?[/-]