feat: adopt GitHub Actions workflow lockfiles (actions.lock) with Renovate #164

What

Adopt GitHub Actions workflow lockfiles (.github/workflows/actions.lock, public preview since 2026-10-14) in this repo, generated with the gh actions-lock extension and kept current by Renovate.

• Changelog: https://github.blog/changelog/2026-10-14-github-actions-workflow-lockfiles-in-public-preview/
• Docs: https://docs.github.com/actions/concepts/security/workflow-dependency-lockfiles
• Renovate support: https://docs.renovatebot.com/modules/manager/github-actions/

Why

• A reusable workflow called via workflow_call is covered by the lockfile of the repo where it is defined. A lockfile here locks the dependencies of tf-plan, docker-build-push-ecr, service-pipeline and the rest for every consuming repo.
• About 40 uses: references here are mutable tags (actions/checkout@v6 x19, DND-IT/tamci/actions/*@v0, tj-actions/changed-files@v47, docker/build-push-action@v7, ...). The lockfile pins them and their transitive action dependencies, which SHA pinning in workflow files never covered.
• The lockfile records owner_id/repo_id, so a renamed or re-registered upstream repo is caught at run time.

Renovate

Supported (experimental), no config change needed: if actions.lock exists, the github-actions manager (enabled in tx-pts-dai/renovate-config) runs gh actions-lock --no-narrow --no-migrate-local-actions once per branch and regenerates the lockfile in the same PR.

Open questions

• How is Renovate run for DND-IT (Mend-hosted app or self-hosted), and does that version include actions.lock support? If self-hosted with binarySource=global, the image needs gh and gh-actions-lock preinstalled.
• Pinning convention: gh actions-lock replaces SHA pins with version tags unless the "require full-length commit SHA" policy is enabled (currently sha_pinning_required: false at org and repo level). Decide whether to keep SHA pins (enable the policy) or move to tags + lockfile, and align the tam:audit SHA-pinned-actions check accordingly.
• Behaviour of local reusable workflow calls (uses: ./.github/workflows/*.yaml, used 10+ times) is not documented. Verify they work once the caller is onboarded.

Plan

1. On a branch, onboard one low-risk workflow (e.g. notify-slack.yaml) with gh actions-lock and run _test-notify-slack.yaml.
2. Confirm a Renovate update PR regenerates actions.lock.
3. Onboard remaining workflows incrementally, running each _test-*.yaml.
4. Add a CI check that the lockfile is up to date (gh actions-lock check mode).
5. Once all workflows are onboarded, consider enabling the Require lockfile policy for this repo.
6. Document the change in the README / docs site.

Caveats

• Public preview; behaviour may change.
• Once a workflow is onboarded, every dependency must have a lockfile entry.
• Locking pins what runs; it does not vet whether a dependency is safe.