Pin github/gh-aw-actions to commit SHA and add pinning guard

[AbhitejJohn]

What & why

GitHub's org policy "Require actions to be pinned to a full-length commit SHA" fails any workflow run that references an action by tag at runtime. Every workflow that uses the agentic-workflow (gh-aw) setup actions was referencing them by bare tag (github/gh-aw-actions/setup@v0.77.5, setup-cli@v0.77.5), so they would break once the policy is enabled. This mirrors how dotnet/msbuild pins the same actions to a SHA.

Root cause

gh aw compile pins uses: refs from .github/aw/actions-lock.json. That lock file was stale: it still held a pre-migration slash-path entry (github/gh-aw/actions/setup) and had no entry for the hyphen-path action the workflows actually use (github/gh-aw-actions/setup). With no matching lock entry, the compiler emitted a bare tag instead of a SHA. (PR #736 removed the old hyphen entry without a replacement.)

Changes

• .github/aw/actions-lock.json — load-bearing fix: add hyphen-path entries for github/gh-aw-actions/setup@v0.77.5 and setup-cli@v0.77.5, both resolving to SHA 3ea13c02d765410340d533515cb31a7eef2baaf0. This makes future gh aw compile runs emit SHA pins instead of bare tags, so the fix survives regeneration.
• Pinned all gh-aw action references across the 8 *.lock.yml files plus agentics-maintenance.yml and validate-pat-pool.yml — uses:, the decorative # vX comments, and the manifest sha fields — to @3ea13c02…baaf0 # v0.77.5.
• New .github/workflows/enforce-action-pinning.yml — a self-contained CI guard that fails a PR if any workflow references an action by tag (exempts local .//../ and docker:// refs). This is the only PR-time gate for the generated .lock.yml files, since none of the gh-aw workflows are pull_request-triggered. (This guard is an addition beyond the msbuild pattern.)

Verification

• SHA 3ea13c02…baaf0 is the commit that annotated tag v0.77.5 of github/gh-aw-actions points to (same method that reproduces msbuild's v0.78.3 → 8cfea5ae… pin exactly).
• Byte-parity proven: installed gh aw pinned to v0.77.5 and ran gh aw compile — output was byte-identical to these hand edits (git diff unchanged across all generated files). The runtime version is unchanged (still v0.77.5); this only changes tag → SHA.

Follow-ups (repo/org settings, not in this PR)

After merge, enable the org policy "Require actions to be pinned to a full-length commit SHA" and turn on immutable releases/tags.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[Copilot]

Pull request overview

Pins github/gh-aw-actions references to a full commit SHA across the repo’s agentic workflow outputs and adds a CI guard to prevent reintroducing tag/branch-based uses: references, aligning with the org policy requirement for immutable action references.

Changes:

• Updated .github/aw/actions-lock.json to include github/gh-aw-actions/setup and setup-cli entries for v0.77.5 resolving to 3ea13c02d765410340d533515cb31a7eef2baaf0.
• Replaced uses: github/gh-aw-actions/*@v0.77.5 with @3ea13c02… (and updated manifests/comments) across multiple generated *.lock.yml workflows and related workflows.
• Added a new enforce-action-pinning.yml workflow to fail PRs/pushes that introduce unpinned uses: references.

Show a summary per file

File	Description
.github/aw/actions-lock.json	Adds/updates lock entries so gh aw compile can emit SHA-pinned refs for gh-aw-actions actions.
.github/workflows/validate-pat-pool.yml	Pins github/gh-aw-actions/setup to a full commit SHA.
.github/workflows/pr-malicious-scan.agent.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/markdown-linter.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/issue-triage.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/issue-investigate.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/devops-health-investigate.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/devops-health-groom.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/devops-health-check.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/close-stale-prs.agent.lock.yml	Updates gh-aw manifest/commentary and uses: refs to SHA for github/gh-aw-actions/setup.
.github/workflows/agentics-maintenance.yml	Pins github/gh-aw-actions/setup and setup-cli to the full commit SHA.
.github/workflows/enforce-action-pinning.yml	Adds a CI job to detect and fail on unpinned uses: references in workflows.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 12/12 changed files
• Comments generated: 1

[ViktorHofer]

New .github/workflows/enforce-action-pinning.yml — a self-contained CI guard that fails a PR if any workflow references an action by tag (exempts local .//../ and docker:// refs). This is the only PR-time gate for the generated .lock.yml files, since none of the gh-aw workflows are pull_request-triggered. (This guard is an addition beyond the msbuild pattern.)

Do we need that? AFAIK, there's a repository setting to enforce that which would make actions running on PRs complain. Anything beyond that feels like over-engineering.

[Copilot]

Copilot's findings

• Files reviewed: 12/12 changed files
• Comments generated: 0 new

[AbhitejJohn]

Fair challenge — and you're right that the org/repo setting ("Require actions to be pinned to a full-length commit SHA") is the primary control, so I don't want to over-build here.

The one gap I'd flag: that policy is enforced per run, at runtime — it fails a workflow when it executes, it isn't a static scan of the repo. The catch for these files is that none of the gh-aw workflows are pull_request-triggered (they're all schedule / issues / workflow_dispatch). So if a future gh aw compile regresses a ref back to a bare tag, nothing runs during the PR to complain — the policy would only trip later when the scheduled run fires on main, i.e. after merge. The guard's only real job is to surface that regression at PR time for the generated .lock.yml files.

That said, it's a judgment call, not a hill — it is strictly more than the msbuild pattern, which has no such guard. If you'd rather lean entirely on the repo setting and keep things lean, I'm happy to drop enforce-action-pinning.yml from this PR and keep just the lock-file + SHA-pinning fix (which is the actual root-cause fix). Your call — let me know and I'll update.

— Copilot

[ViktorHofer]

Yes, I would drop that workflow. We don't do that in any other repository.

[AbhitejJohn]

Done — dropped enforce-action-pinning.yml (pushed in 9341e24). The PR now keeps just the root-cause fix: the actions-lock.json entries plus the SHA pins, so gh aw compile emits SHA-pinned refs going forward. We'll rely on the "Require actions pinned to a full-length commit SHA" setting as the enforcement mechanism. Thanks for the review!

— Copilot