fix: BUG: ISSUE-705 cannot see a ref-scoped type=gha buildx cache (scope= par...

[yhay81]

Fixes #433.

Summary

BUG: ISSUE-705 cannot see a ref-scoped type=gha buildx cache (scope= parameter ignored)

Validation

• Mechanical gate: +43/-12, tests passed
• Adversarial review: approved

---

🤖 AI-authored PR, operated by @yhay81.

[thomasboni]

Hello @yhay81 Thanks for the PR!

Two problems before merge

Blocker: a scoped line hides an unscoped one

_key_is_release_scoped iterates some entry in split(value, "\n"), so as soon as one cache-from line is ref-scoped the whole action passes, even if another line is a bare unscoped type=gha restore. This workflow produces no finding today:

cache-from: |
  type=gha,scope=myapp-${{ github.ref_name }}
  type=gha
cache-to: type=gha,scope=myapp-${{ github.ref_name }},mode=max

The second line restores from the shared unscoped namespace, which is exactly the vector the control exists to catch, and multi-source cache-from is a normal buildx pattern. Before this change any type=gha buildx cache always fired, so this is a new gap rather than a pre-existing one. The quantifier is backwards for a security check: it should flag when any type=gha restore entry is unscoped, not pass when some entry is scoped. Concretely, the second regex match needs to hold for every type=gha entry, and a bare type=gha with no scope= must fail scoping.

Please confirm: head_ref does not scope on release

The change adds github.head_ref to the accepted refs. github.head_ref is empty on every event except pull_request, which includes release and push, the triggers that put a job in release context here. So scope=myapp-${{ github.head_ref }} renders as the constant myapp- on a release and provides no isolation, but the control now treats it as scoped. A release job scoped only with head_ref gets no finding. The issue lists head_ref explicitly, so this may be intended, but on the release path it is not effective. Worth a second look before it ships.

Minor

• The s3 and azblob name= backends are wired in but the only cache action in the default config carrying an enableInput is docker/build-push-action, so those two paths have no fixture. The issue scoped them as "if those ever join the inventory," so leaving them is fine, but one fixture would pin the regex.
• The new _key_is_release_scoped(action, spec) clause reads action.with[spec.enableInput], which is undefined for a spec with no enableInput (for example actions/cache, mode always). That is handled correctly (the clause is skipped and the with.key clause takes over, verified against the existing actions/cache fixtures), but a one-line comment saying so would save the next reader the check.

[yhay81]

@thomasboni Addressed in 9763e72.