Summary
action.yml references two transitive actions by floating tag with explicit # ratchet:exclude markers, which makes the action unusable from any repository whose organization enforces "actions must be pinned to a full-length commit SHA" (e.g. via Settings → Actions → "Allow specified actions and reusable workflows" → "Require actions to be pinned to a full SHA").
Reproduction
Set the org-level Actions policy on a repo to require commit-SHA pinning, then attempt to run google-github-actions/run-gemini-cli@v0.1.22 in any workflow. The workflow fails at action-download time with:
The actions google-github-actions/auth@v3 and actions/upload-artifact@v6 are not allowed in <org>/<repo> because all actions must be pinned to a full-length commit SHA.
This happens even when the unpinned actions are conditionally invoked (the policy check resolves all uses: references at workflow setup, before any if: evaluates).
Affected references
action.yml line 221:
uses: 'google-github-actions/auth@v3' # ratchet:exclude
action.yml line 435:
uses: 'actions/upload-artifact@v6' # ratchet:exclude
Suggested fix
Pin both to commit SHAs and keep the floating tag in a trailing comment, matching the convention pnpm/action-setup already uses on line 232:
uses: 'google-github-actions/auth@7c6bc770dae815cd3e89ee6cdf493a5fab2cc093' # v3
uses: 'actions/upload-artifact@b7c566a772e6b6bfb58ed0dc250532a479d7789f' # v6
(SHAs above are current v3 and v6 as of today; pin to whatever the maintainers consider stable.)
Workaround
Until upstream pins these, consumers under strict policies have to fork the action (e.g., jaredmixpanel/run-gemini-cli@v0.1.22-pinned-1), which adds maintenance burden and is awkward to keep in sync with upstream releases.
Why pin
The "require pinned SHAs" Actions policy is a common defense against supply-chain attacks where a maliciously-pushed tag could swap action contents. Pinning to a commit SHA defeats that vector. The current # ratchet:exclude markers suggest these were intentionally left unpinned — but they break the action for any repo under that policy and there's no documented way for consumers to work around the constraint other than forking.
Happy to send a PR if helpful.
Summary
action.ymlreferences two transitive actions by floating tag with explicit# ratchet:excludemarkers, which makes the action unusable from any repository whose organization enforces "actions must be pinned to a full-length commit SHA" (e.g. via Settings → Actions → "Allow specified actions and reusable workflows" → "Require actions to be pinned to a full SHA").Reproduction
Set the org-level Actions policy on a repo to require commit-SHA pinning, then attempt to run
google-github-actions/run-gemini-cli@v0.1.22in any workflow. The workflow fails at action-download time with:This happens even when the unpinned actions are conditionally invoked (the policy check resolves all
uses:references at workflow setup, before anyif:evaluates).Affected references
action.ymlline 221:action.ymlline 435:Suggested fix
Pin both to commit SHAs and keep the floating tag in a trailing comment, matching the convention
pnpm/action-setupalready uses on line 232:(SHAs above are current
v3andv6as of today; pin to whatever the maintainers consider stable.)Workaround
Until upstream pins these, consumers under strict policies have to fork the action (e.g.,
jaredmixpanel/run-gemini-cli@v0.1.22-pinned-1), which adds maintenance burden and is awkward to keep in sync with upstream releases.Why pin
The "require pinned SHAs" Actions policy is a common defense against supply-chain attacks where a maliciously-pushed tag could swap action contents. Pinning to a commit SHA defeats that vector. The current
# ratchet:excludemarkers suggest these were intentionally left unpinned — but they break the action for any repo under that policy and there's no documented way for consumers to work around the constraint other than forking.Happy to send a PR if helpful.