Los lockfiles de Actions llegan a GA: qué demuestra un check verde
Una PR puede conservar la misma versión en uses mientras cambia el código que hay detrás. Las etiquetas pueden apuntar a otro commit. GitHub anunció la disponibilidad general de los lockfiles el 28 de octubre. Tras la vista previa, conviene entender qué evidencia ofrece cada comprobación.
Referencias legibles y commits registrados
.github/workflows/actions.lock relaciona las referencias de las acciones con los commits que se ejecutarán. Se genera con gh actions-lock y está disponible en Free, Team y GitHub Enterprise Cloud, incluida la residencia de datos. Es posible incorporar workflows por separado. Se revisan los cambios del workflow y el archivo generado juntos, sin construirlo a mano.
En un ejemplo ficticio, demo/build@v1 apunta primero al commit A y después al B. Resolver solo la referencia puede seleccionar otro código en la siguiente ejecución; el lockfile conserva el commit registrado. La ilustración no es una prueba real. Si el commit deja de ser alcanzable desde la rama o etiqueta registrada, la ejecución puede rechazarlo.
¿Qué confirma la comprobación sin conexión?
gh actions-lock --verify-local comprueba la cobertura sin usar la red: que las referencias uses tengan entradas. Es útil antes del commit, pero no verifica la procedencia. gh actions-lock --verify la comprueba en línea y el runner vuelve a hacerlo al iniciar el trabajo. Los dos resultados verdes no significan lo mismo.
Si otra PR añade una acción y olvida actualizar el archivo, la cobertura local puede detectar la omisión. Tener todas las entradas no demuestra la procedencia ni la seguridad del código. La segunda ilustración resume la documentación; no instalamos ni ejecutamos la CLI para este artículo.
Los workflows reutilizables cruzan otra frontera
Se incluyen las dependencias transitivas de acciones, pero las llamadas mediante jobs.<job_id>.uses no quedan fijadas por el lockfile. Deben referenciarse mediante el SHA completo. Sus acciones internas dependen del lockfile del repositorio que define el workflow, no del repositorio que lo llama.
Imaginemos una aplicación que llama al despliegue de un repositorio de plataforma. Revisar únicamente actions.lock de la aplicación no revela los commits de las acciones de la plataforma. Hay que relacionar el SHA de llamada con sus dependencias. La imagen del runner, las entradas y los secretos también siguen siendo elementos distintos del entorno.
Leer dos archivos en las PR de actualización
Cuando Dependabot actualiza una acción de un workflow incorporado, regenera su entrada en la misma PR. Así se comparan la versión legible y el commit real. --relock mueve las referencias a los commits actuales y escribe archivos: su función difiere de una comprobación de solo lectura. La revisión del código sigue siendo necesaria.
Require lockfile permite exigir la adopción, pero no elimina esas fronteras. Empezar por un workflow ayuda a entender generación, revisión y validación en línea. El próximo check verde merece una lectura precisa: ¿prueba cobertura, procedencia o una revisión del código elegido?