Verify Actions

Why This Matters

• Comments like # v4 can be wrong — a SHA may actually point to v3 or a branch
• Version mismatches across workflows cause subtle bugs (e.g., upload-artifact v4 can't download v7 artifacts)
• Supply-chain attacks target CI — pinning a wrong SHA from main instead of a tag defeats the purpose

Agent Workflow

1. Before Changing Any Action Reference

When you encounter a uses: owner/action@SHA # vX line, verify the SHA:

For GitHub Actions:

# Look up what tag a SHA belongs to
gh api repos/{owner}/{repo}/git/ref/tags/{tag} --jq '.object.sha'

# Or list recent tags to find the right one
gh api repos/{owner}/{repo}/tags --jq '.[].name' | head -20

# Verify a specific SHA matches a tag
gh api repos/{owner}/{repo}/git/ref/tags/v4 --jq '.object.sha'

For GitLab Actions (CI/CD):

# Check the registry or project for the correct image tag
# Use the project API or container registry
glab api projects/{id}/repository/tags

Fallback — web fetch:

WebFetch: https://github.com/{owner}/{repo}/releases/tag/{tag}
Confirm the release exists and note the commit SHA.

2. Version Consistency Check

Before committing workflow changes, verify ALL action references across the workspace are version-consistent:

# Find all action references and group by action name
grep -rn 'uses:' .github/workflows/ .github/actions/ \
  | sed 's/.*uses: \([^@]*\)@.*/\1/' \
  | sort | uniq -c | sort -rn

# For each unique action, verify all SHAs match
grep -rn 'uses: actions/upload-artifact@' .github/workflows/
grep -rn 'uses: actions/checkout@' .github/workflows/
grep -rn 'uses: actions/download-artifact@' .github/workflows/

3. When Adding a New Action

1. Find the latest release tag from the upstream repo
2. Resolve the SHA for that tag using gh api
3. Pin the SHA with a version comment
4. Verify no other workflow uses a different version of the same action

4. When Updating an Action

1. Identify the current SHA and version in use
2. Find the latest release tag
3. Resolve the new SHA
4. Update ALL files that reference this action to the same SHA
5. Run the consistency check from step 2

Canonical SHA Reference

These are verified SHAs for commonly used actions. Always cross-check before using — upstream may have released newer versions.

Rule: Before using a SHA from this table, verify it still matches the claimed version. Run gh api to confirm. This table drifts: the previous revision listed actions/checkout v6, actions/github-script v7, and Swatinem/rust-cache v2 SHAs that were two major versions behind, and every one of them ran on the deprecated Node.js 20 runtime.

Checking for runtime deprecations

An action major version can be pinned correctly and still be unusable because GitHub retired its Node runtime. Check the declared runtime directly:

gh api "repos/{owner}/{repo}/contents/action.yml?ref={tag}" \
  --jq '.content' | base64 -d | grep -m1 'using:'

A node20 result produces this warning in every job that uses it:

Node.js 20 is deprecated. The following actions target Node.js 20 but are being
forced to run on Node.js 24: ...

Fixing it requires a major version bump, because the Node 24 runtime landed in a new major line for nearly every action. Enumerate them all at once:

grep -rhoE "uses: [a-zA-Z0-9_.-]+/[a-zA-Z0-9_.-]+@[a-f0-9]{40}" .github/ \
  | sed 's/uses: //' | sort -u \
  | while IFS=@ read -r repo sha; do
      printf '%-45s %s\n' "$repo@${sha:0:7}" \
        "$(gh api "repos/$repo/contents/action.yml?ref=$sha" --jq '.content' \
            | base64 -d | grep -m1 'using:')"
    done

## Red Flags

- [ ] Action pinned from a branch (`# main`, `# master`) instead of a tag
- [ ] Version comment says one thing but SHA resolves to another
- [ ] Same action used with different SHAs across workflow files
- [ ] `download-artifact` version doesn't match `upload-artifact` version
- [ ] No version comment on a SHA-pinned reference
- [ ] SHA not resolvable via `gh api` (may be from a fork or deleted tag)

## Common Mismatches to Watch

| Action Pair | Must Match |
|-------------|-----------|
| `upload-artifact` + `download-artifact` | Same major version |
| `actions/checkout` across all workflows | Same SHA |
| `actions/upload-artifact` across all workflows | Same SHA |
| Composite action internal pins | Match consuming workflow versions |

## Rationalizations

| Rationalization | Reality |
|-----------------|---------|
| "The version comment already tells me which version this is" | The comment is a claim, not a fact. Resolve the SHA against the upstream tag before trusting it. |
| "I'll just bump the SHA to the latest commit on main" | Pinning `main` defeats the purpose of SHA pinning — the supply chain is unpinned again. |
| "Only one workflow uses this action, so no consistency check needed" | Version skew usually appears later, when a second workflow is added or a matrix job runs. Check on every change. |