Activity

1. nodeselector

   added

   feature-request

   area:lockfile

   on Oct 15, 2026
2. woodruffw commented on Oct 19, 2026

   

   woodruffw

   on Oct 19, 2026

   More actions

   I want to register my support for this idea as well -- I like the current lockfile design as a ground-up approach, but I think the current fractured nature of Actions means that it has a lot of limitations (including documented/known ones like reusable workflows and Docker pinning), but also philosophical ones like "how should composite actions enforce their own pinning?".

   If possible, I think it'd be really great for Actions pinning to instead be done in an "intrinsic" manner on each workflow/composite action. For example (making this up completely):

   name: example
   
   on: [push, pull_request]
   
   permissions: {}
   
   # this could be `true | false | incremental` or `all | none | incremental`
   # when set, the runner should enforce that state.
   pinned: true
   
   jobs:
     example:
       name: example
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout
           ref: v7.0.1
           # the runner also enforces that this is not an impostor
           # by confirming that it actually matches the `ref` in the given namespace.
           hash: sha1-abcd...

   On top of @webknjaz's point about edit contention, this also simplifies the integration story for downstream tooling (which I am selfishly interested in 🙂).
3. jessehouwing commented on Oct 19, 2026

   

   jessehouwing

   on Oct 19, 2026

   Contributor

   More actions

   For large monorepos, I've also suggested to allow subfolders under .github/workflows/* and to lock each folder with its own lockfile.
4. nodeselector

   changed the title [-][FR] Per-workflow lock files[/-] [+]Feature request: Per-workflow lock files[/+] on Oct 21, 2026