Fix mode unpins a reusable workflow call when the same repository is also used as a step action

Open Beginner friendly
  • Is something wrong?
#261 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, go
Domain
ci-cd, cli

Research direction

Start in internal/workflowfile/rewrite.go, at RewriteActionRefs and subpathRewriteLookup, which the issue links to. Reproduce with the workflow from the issue, then check that jobs.<job_id>.uses values are skipped or that refs under .github/workflows/ are not treated as action sub-paths. Done means the reusable workflow call keeps its SHA while the step action is still rewritten to the tag.

Written by the indexing model from the issue text.

Description

Summary

When a workflow calls a reusable workflow pinned by a commit SHA (jobs.<job_id>.uses), and a step in the same file uses an action from the same repository pinned by the same SHA, gh actions-lock rewrites the reusable workflow call to the tag too.

The lockfile doesn't lock reusable workflow calls (#179), so this replaces the SHA pin with a tag that nothing locks. Unless the tag belongs to an immutable release, it can be moved to another commit.

Version

gh-actions-lock v0.4.1

Steps to reproduce

Create .github/workflows/test.yaml in an empty Git repository:

name: test
on: pull_request
jobs:
  gomodule:
    uses: suzuki-shunsuke/download-go-module-action/.github/workflows/download.yaml@e03acd0c9d3d230019ebb7bd4a62507431fe4316 # v0.0.10
    permissions:
      contents: read
  test:
    needs: [gomodule]
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: suzuki-shunsuke/download-go-module-action/restore@e03acd0c9d3d230019ebb7bd4a62507431fe4316 # v0.0.10

Run gh actions-lock.

Actual behavior

Both uses: lines are rewritten to the tag:

   gomodule:
-    uses: suzuki-shunsuke/download-go-module-action/.github/workflows/download.yaml@e03acd0c9d3d230019ebb7bd4a62507431fe4316 # v0.0.10
+    uses: suzuki-shunsuke/download-go-module-action/.github/workflows/[email protected]
 ...
     steps:
-      - uses: suzuki-shunsuke/download-go-module-action/restore@e03acd0c9d3d230019ebb7bd4a62507431fe4316 # v0.0.10
+      - uses: suzuki-shunsuke/download-go-module-action/[email protected]

Expected behavior

Only the step action is rewritten. The reusable workflow call keeps the SHA, as it does when the file has no step action from that repository.

The README says:

Reusable workflows called at jobs.<id>.uses from another repository are not locked (#179).

And the docs say:

It doesn't pin calls to reusable workflows (jobs.<job_id>.uses). To pin a reusable workflow, reference it by its full commit SHA.

So a full commit SHA is the only pin a reusable workflow call has, and gh actions-lock shouldn't rewrite it.

If the step is replaced with an action from another repository (e.g. actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1), the reusable workflow call is left as it is.

Cause

RewriteActionRefs rewrites every scalar uses: value in the file, including job-level reusable workflow calls.

The replacement map has a key for the step action, suzuki-shunsuke/download-go-module-action@e03acd0c.... subpathRewriteLookup matches owner/repo/<path>@ref against an owner/repo@ref key, so .github/workflows/download.yaml is treated as an action sub-path like restore, and the reusable workflow call gets the step action's new ref.

Skipping jobs.<job_id>.uses (or refs whose path starts with .github/workflows/) in the rewrite would fix it.

Workaround

Pin the reusable workflow call to the SHA again after running gh actions-lock. Running gh actions-lock again after that keeps the SHA.

Dominant language
Go
Stars
253
Forks
15
Avg merge
19h 30m
Merged PRs (30d)
60

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-actions-lock

All issues in github/gh-actions-lock

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.