GitHub Actions workflow dependency lockfiles enter public preview, with implications for Mac and iOS CI workflows.
GitHub launched workflow dependency lockfiles in public preview on October 14 for GitHub Enterprise Cloud, including data-residency deployments. For Mac and iOS teams, the first job is to check shared build workflows and action allowlists before enforcing the feature. GitHub Enterprise Server is not supported.
Start with shared workflows
The generated .github/workflows/actions.lock records dependency references, exact commits and numeric owner and repository IDs. GitHub runs the locked commits and checks repository identity. Coverage includes actions and their transitive dependencies.
Reusable workflows have an important boundary: dependencies inside them rely on the lockfile in the repository where that workflow is defined. Onboard shared-workflow repositories first, then their callers.
GitHub lists repository write access as a prerequisite. Check that your current action versions are the ones you intend to retain. With GitHub CLI available, install the extension, then generate from your repository root:
gh extension install github/gh-actions-lock
gh actions-lockReview more than actions.lock
The generation command also edits workflow references. It can replace a broad version such as v3 with a specific tag resolving to the same commit. Local action references can change from ./… to $/… in workflows and in-repository action definitions. The latter resolves to the running commit and needs no lockfile entry. Review the full diff.
Check action allowlists before merging. Onboarded workflows are checked against locked SHAs, so a tag-only entry such as actions/checkout@v6 no longer matches. Review full-SHA entries with whoever owns the policy; do not broaden access simply to make a build pass.
A changed commit changes the code CI runs. Changed owner_id or repo_id values deserve investigation before approval. Regenerate the lockfile rather than editing it manually.
Verify before enforcing
For a non-writing CI check, use:
gh actions-lock --verify--verify-local works offline and checks coverage only; it does not validate pins against GitHub. Normal runs keep existing pins. Use --relock deliberately to refresh eligible moved references after reviewing upstream changes.
Dependabot updates matching lockfile entries when it bumps actions in onboarded workflows. It does not onboard new workflows. Pilot the Require lockfile policy in Evaluate mode, inspect Policy insights, and establish upkeep before switching to Active, which can block runs.
For an iOS build, this still leaves Xcode selection, Package.resolved and packages fetched by run: steps under separate controls. That is a practical consequence of the feature’s dependency scope. The extension also excludes docker:// references. A lockfile neither proves a dependency safe nor makes the whole build reproducible.
This guide follows GitHub’s preview documentation; we have not tested it hands-on.
