Feature request: Inherited organization and enterprise Action locks

Open
  • Is something wrong?
#91 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Quiet
Tech stack
github-actions, go
Domain
ci-cd, security

Research direction

No repository file, test, or entry point is named. Start by comparing the requested inherited-lock behavior with gh-actions-lock's current generation and verification scope, then determine which parts require GitHub Actions service or policy support. Done means an agreed implementation scope or a redirect to the appropriate tracker.

Written by the indexing model from the issue text.

Description

area:enterprise-management feature-request

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.

Dominant language
Go
Stars
253
Forks
15
Avg merge
19h 30m
Merged PRs (30d)
60

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/gh-actions-lock

All issues in github/gh-actions-lock

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.