Skip to content

Feature request: How should composite actions lock themselves? #183

Open

Description

@woodruffw

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:

https://github.com/zizmorcore/zizmor-action/blob/fb1d87ba4b2f888025015a269a94ad7e991f6a7b/action.yml#L131

As is, lockfiles leave these kinds of composite actions with a bit of a gap:

  1. 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).
  2. 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.

Activity

  1. jessehouwing commented on Oct 19, 2026

    @jessehouwing
    Contributor

    These should ideally be pinned to an immutable release tag. But that's another wave of change hitting the actions' ecosystem.

  2. woodruffw commented on Oct 19, 2026

    @woodruffw
    Author

    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. jessehouwing commented on Oct 19, 2026

    @jessehouwing
    Contributor

    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 ;).

  4. nodeselector commented on Oct 20, 2026

    @nodeselector
    Collaborator

    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.

  5. jessehouwing commented on Oct 20, 2026

    @jessehouwing
    Contributor

    The best wat is to pin to immutable releases. Barring those, Sha pinning.

  6. changed the title [-]How should composite actions lock themselves?[/-] on Oct 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions