Feature request: Inherited organization and enterprise Action locks

Abierto
  • ¿Algo no está bien?
#91 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
github-actions, go
Área
ci-cd, security

Línea de trabajo

No se especifica ningún archivo del repositorio, prueba ni punto de entrada. Empieza comparando el comportamiento solicitado de inherited-lock con el alcance actual de generación y verificación de gh-actions-lock, y determina después qué partes requieren compatibilidad del servicio o de las políticas de GitHub Actions. Se considera terminado cuando se haya acordado el alcance de la implementación o se haya redirigido al tracker correspondiente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
253
Forks
15
Merge medio
19 h 30 min
PR fusionados (30 d)
60

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de github/gh-actions-lock

Todos los issues de github/gh-actions-lock

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.