PIMP MY IDE
GitHub Actions / dependency control / 14 OCT 2026

Lock the code behind the label.

A readable action tag is useful for humans. A reviewed commit is what the runner should execute.

Garage note 362 / workflow lockplate

A tag is a label, not a frozen object

GitHub Actions workflows often reference an action with a tag such as actions/checkout@v4. The tag can move after review. GitHub's new workflow dependency lockfiles keep the readable reference in the workflow while the runner executes the commit recorded in .github/workflows/actions.lock.[1]

The public preview covers GitHub Enterprise Cloud and GitHub Enterprise Cloud with data residency. Teams can onboard one workflow at a time. Once a workflow is onboarded, every action dependency it uses must have a lockfile entry.[1]

The lockfile freezes resolution. It does not certify the code.Review the dependency before locking it. A stable bad commit is still a bad commit.

The useful part is the second hop

A full commit SHA in a workflow pins the direct action. GitHub's lockfile also records actions used by that action. The docs call these transitive dependencies. The file also records repository identity, and the runner checks that identity before execution.[2]

Reusable workflow calls need a boundary note. The caller's lockfile records the reusable workflow itself, but dependencies inside that reusable workflow belong to the lockfile in the repository where it is defined.[2] One green lock icon cannot describe both repositories.

Put drift checks in the normal review lane

The official CLI extension generates the lockfile and can verify it without writing changes. Its online --verify check confirms recorded refs and repository identity. The offline --verify-local mode only checks that entries exist, so it cannot establish that the entries are trustworthy.[3]

Dependabot can update the workflow reference and matching lockfile entry in one pull request. That gives reviewers one place to inspect the label change and the commit change together.[1]

Adopt it as a controlled migration

Start with a workflow that uses third party actions and has a clear owner. Generate the file, inspect every new commit, add online verification to continuous integration, and record who reviews dependency updates. Move the next workflow only after the first one has a boring update path.

The preview still has eligibility limits. The extension README says workflows with local path actions are skipped for onboarding. Check the current limits before making a repository policy depend on lockfiles.[3]

Interactive makeover / rollout lockplate

Build the review route.

A loose checklist hides dependency boundaries. This connected lock bus keeps four rollout decisions on one route and drafts a copyable plan. It does not inspect a repository or create a lockfile.

Choose rollout requirements

Lock circuits

Connected review route

Dependency lock bus

Direct actionsSelected
Transitive actionsSelected
Reusable workflowsOpen
Online verificationSelected
3 CIRCUITS SELECTED / PLAN STRUCTURE READYReusable workflows remain open. Repository evidence still needs review.
This planner records requested review steps. It does not authenticate the CLI, read workflows, resolve action refs, review code, generate actions.lock, or run CI.
Source ledger

What was read

Three first party sources
  1. GitHub Changelog, "GitHub Actions workflow lockfiles in public preview", read October 14, 2026. This supports the preview scope, threat model, gradual onboarding, policy, Dependabot, and setup claims.
  2. GitHub Docs, "Workflow dependency lockfiles", read October 14, 2026. This supports the file location, transitive dependency, repository identity, reusable workflow, and SHA comparison claims.
  3. github/gh-actions-lock repository, inspected October 14, 2026. This supports the install command, verification modes, runtime checks, and current local action limitation. The extension source was read but not installed or run against a repository.