Los archivos de bloqueo de GitHub Actions entran en versión preliminar pública

GitHub puso los archivos de bloqueo de dependencias de flujos de trabajo (workflow dependency lockfiles) de GitHub Actions en versión preliminar pública el 14 de octubre de 2026. Un nuevo archivo, .github/workflows/actions.lock, registra el commit exacto que hay detrás de cada acción que usa un flujo de trabajo. Una ejecución posterior ya no puede incorporar en silencio un código distinto, un hueco en la cadena de suministro que los equipos han tenido que cerrar a mano.

GitHub Actions es el sistema de GitHub para ejecutar tareas automatizadas, como pruebas y despliegues, cuando cambia el código. Esas tareas se construyen con pasos reutilizables llamados acciones. La mayoría de las acciones están en repositorios de otras personas.

Qué problema resuelve el archivo de bloqueo

Un flujo de trabajo suele nombrar una acción por una etiqueta o una rama, como actions/checkout@v6. Ese nombre puede apuntar mañana a un código distinto. «Las etiquetas y las ramas pueden moverse después de que revises un flujo de trabajo, así que una ejecución posterior podría ejecutar un código distinto», dice el changelog de GitHub. La documentación de GitHub menciona una forma en que ocurre: alguien se hace con la cuenta de un mantenedor upstream y mueve una etiqueta.

Hasta ahora, la principal defensa era fijar cada acción a su hash de commit completo, llamado SHA, dentro del archivo del flujo de trabajo. La documentación de GitHub dice que eso «ya no es necesario» en los repositorios que adoptan un archivo de bloqueo. Fijar a mano tampoco cubría las acciones que otras acciones incorporan. El archivo de bloqueo cubre también esas dependencias indirectas, o transitivas.

Cómo funciona actions.lock

Una herramienta de línea de comandos llamada gh actions-lock escribe el archivo. Es una extensión para gh, el cliente de línea de comandos de GitHub. Se instala con gh extension install github/gh-actions-lock y después se ejecuta gh actions-lock desde la raíz del repositorio. El archivo empieza con una advertencia de que no se edite a mano.

Cada entrada de dependencia guarda cuatro valores: la referencia, el commit resuelto y los ID numéricos del propietario y del repositorio. Durante la ejecución, Actions comprueba esos ID. Así confirma que el repositorio que hay detrás del nombre sigue siendo el que se bloqueó.

Elemento	Detalle
Archivo	.github/workflows/actions.lock
Herramienta	gh actions-lock, una extensión de GitHub CLI
Cubre	Acciones directas, acciones transitivas, dependencias de flujos de trabajo reutilizables
Planes en la versión preliminar	Free, Team, Enterprise Cloud, Enterprise Cloud con residencia de datos
Aplicación	Una política «Require lockfile» para quienes administran empresas, organizaciones o repositorios
Estado	Versión preliminar pública desde el 14 de octubre de 2026

Los equipos pueden incorporar los flujos de trabajo de uno en uno o todos a la vez, por ejemplo con gh actions-lock .github/workflows/ci.yml. A partir de ahí, cada acción que usa el flujo de trabajo debe tener una entrada, y Actions ejecuta el commit registrado. La herramienta también reescribe una referencia imprecisa como @v3 a la versión exacta que encontró, como @v3.1.0.

Cuando una etiqueta upstream se mueve por un buen motivo, gh actions-lock --relock actualiza la entrada. Si un commit bloqueado ha desaparecido, por ejemplo tras un force-push, la documentación remite a --relock --accept-moved.

Quién lo recibe y qué hace Dependabot

El changelog enumera cuatro planes: Free, Team, Enterprise Cloud y Enterprise Cloud con residencia de datos. Una nota del editor dice que GitHub cambió esa lista el 14 de octubre. Las primeras informaciones, entre ellas la de OpenTools, describían la versión preliminar como exclusiva de Enterprise Cloud. Ninguna de las fuentes menciona GitHub Enterprise Server, la edición autoalojada.

Una política «Require lockfile», también en versión preliminar, permite a quienes administran hacer obligatorios los archivos de bloqueo. Funciona a nivel de empresa, de organización o de repositorio.

Dependabot es el bot de GitHub para actualizar dependencias. Cuando actualiza una acción en un flujo de trabajo incorporado, ahora regenera la entrada correspondiente del archivo de bloqueo en la misma pull request. No incorpora flujos de trabajo nuevos por sí solo, según la documentación de GitHub.

Lo que el archivo de bloqueo no hace

Un archivo de bloqueo congela el código, pero no lo revisa. El changelog de GitHub pide a los equipos que revisen las dependencias antes de bloquearlas. El desarrollador Dave Kurian dijo lo mismo en su guía en DEV Community. «El bloqueo registra a qué commit se resuelve una dependencia de un flujo de trabajo; no evalúa si la acción es segura».

Los flujos de trabajo reutilizables tienen una pega. Un flujo de trabajo reutilizable es un flujo de trabajo completo al que llaman otros flujos de trabajo. Lo cubre el archivo de bloqueo del repositorio donde está definido, no el de quienes lo llaman. Los equipos que comparten flujos de trabajo desde un repositorio central deberían bloquear primero ese repositorio, aconseja la documentación.

Qué significa esto para los desarrolladores

• Empieza por un flujo de trabajo. Bloquea primero un flujo de despliegue o de publicación, ya que suelen tener las credenciales más potentes. Observa algunas ejecuciones antes de ampliarlo.
• Corrige tus listas de permitidos. Algunas organizaciones permiten acciones por etiqueta, como actions/checkout@v6. La documentación de GitHub dice que esas entradas dejan de coincidir con los flujos de trabajo bloqueados, así que cámbialas por un comodín o por un SHA completo.
• Activa primero Dependabot para las acciones. Mantiene al día las entradas del archivo de bloqueo en la misma pull request, para que los flujos de trabajo bloqueados no se queden desfasados.
• Busca archivos de bloqueo desfasados en CI. La herramienta puede comprobar las entradas sin cambiar ningún archivo. OpenTools sugiere una comprobación obligatoria que falle si el archivo de bloqueo está desfasado, además de que los code owners revisen el archivo.
• Espera para activar la política hasta que la cobertura esté lista. «Activar la política antes de que la cobertura y la automatización de actualizaciones estén listas puede bloquear ejecuciones de flujos de trabajo», advierte OpenTools. Mide primero y aplica después.
• Trata un cambio de ID de propietario o de repositorio como una alarma. La documentación de GitHub dice que un cambio así debería ser poco frecuente. Investígalo antes de fusionar.