Feature request: Inherited organization and enterprise Action locks

Aperta
  • Qualcosa non va?
#91 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
github-actions, go
Ambito
ci-cd, security

Direzione di ricerca

Non viene indicato alcun file del repository, test o punto di ingresso. Inizia confrontando il comportamento richiesto di inherited-lock con l'attuale ambito di generazione e verifica di gh-actions-lock, quindi determina quali parti richiedono il supporto del servizio o delle policy di GitHub Actions. Il lavoro è completato quando è stato concordato un ambito di implementazione o è stato effettuato un reindirizzamento al tracker appropriato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
253
Fork
15
Merge medio
19h 30m
PR unite (30g)
60

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di github/gh-actions-lock

Tutte le issue di github/gh-actions-lock

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.