Is inherited Action-lock configuration in scope for the Workflow Dependency Pinning technical preview?
It would be useful for organization and enterprise owners to provide centrally managed Action-lock entries and require selected repositories to use an effective lock, even when those repositories do not contain .github/workflows/actions.lock.
For each action reference, resolution could follow:
repository lock > organization lock > enterprise lock
This would let central owners roll out reviewed, known-good Action pins without a repository-by-repository migration. A repository could inherit the organization or enterprise resolution without a local lockfile. Repository administrators could add a local lock entry when they need a permitted repository-specific resolution, or when they introduce an action/ref that is not covered by the organization or enterprise lock.
An organization or enterprise policy/ruleset could require an effective lock for selected repositories. Once enabled, a dependency missing from all applicable lock scopes should fail rather than resolve a mutable tag or branch live.
A practical rollout could be:
audit → generate and review central-lock entries from existing workflow dependencies → enforce
The generated central entries should capture the verified resolution at generation time. After enforcement, newly introduced references would require an approved central entry or a permitted repository-level entry.
This appears to need GitHub Actions service/policy and runtime support in addition to gh-actions-lock. I’m filing it here because it is related to the technical preview, but please redirect me if there is a better tracker for the broader design.
Is inherited Action-lock configuration in scope for the Workflow Dependency Pinning technical preview?
It would be useful for organization and enterprise owners to provide centrally managed Action-lock entries and require selected repositories to use an effective lock, even when those repositories do not contain
.github/workflows/actions.lock.For each action reference, resolution could follow:
This would let central owners roll out reviewed, known-good Action pins without a repository-by-repository migration. A repository could inherit the organization or enterprise resolution without a local lockfile. Repository administrators could add a local lock entry when they need a permitted repository-specific resolution, or when they introduce an action/ref that is not covered by the organization or enterprise lock.
An organization or enterprise policy/ruleset could require an effective lock for selected repositories. Once enabled, a dependency missing from all applicable lock scopes should fail rather than resolve a mutable tag or branch live.
A practical rollout could be:
The generated central entries should capture the verified resolution at generation time. After enforcement, newly introduced references would require an approved central entry or a permitted repository-level entry.
This appears to need GitHub Actions service/policy and runtime support in addition to
gh-actions-lock. I’m filing it here because it is related to the technical preview, but please redirect me if there is a better tracker for the broader design.