Archivos de bloqueo de dependencias del flujo de trabajo

¿Por qué bloquear las dependencias de flujo de trabajo?

Cuando un flujo de trabajo hace referencia a una acción mediante una etiqueta o rama, como uses: octo-org/deploy-action@v3 o uses: octo-org/deploy-action@main, GitHub Actions resuelve esa referencia al commit al que apunte la etiqueta o rama en el momento de la ejecución.

Las etiquetas y ramas se pueden mover, por lo que no se garantiza que el código que se ejecuta sea el código que el autor del flujo de trabajo revisó originalmente. Si la cuenta del mantenedor upstream ha sido comprometida y se vuelve a apuntar una etiqueta, los repositorios podrían ejecutar código malintencionado.

Un archivo de bloqueo de dependencias de flujo de trabajo fija un SHA de confirmación a cada acción (incluidas las dependencias transitivas) y a cada flujo de trabajo reutilizable del que dependen los flujos de trabajo. Esto le proporciona lo siguiente:

• Compilaciones reproducibles
• Cambios de dependencia revisables y Dependabot actualizaciones de versiones
• Un inventario auditable de las dependencias de tus sistemas de CI/CD

¿Cómo funciona el lockfile?

El archivo de bloqueo se define en un repositorio en .github/workflows/actions.lock. Se genera mediante gh actions-lock, una GitHub CLI extensión y nunca se debe editar manualmente.

Puede incorporar los flujos de trabajo de un repositorio al flujo de trabajo de lockfile de uno en uno o todos a la vez. Después de que se haya integrado un flujo de trabajo:

• Cada dependencia de acción que usa el flujo de trabajo debe estar presente en el archivo de bloqueo.
• El commit bloqueado es lo que se ejecuta cuando se ejecuta el flujo de trabajo y lo que comprueban las directivas de acciones permitidas. Este commit debe existir dentro de una rama del repositorio de origen.

Un archivo de bloqueo cubre los flujos de trabajo de su propio repositorio. Se extiende a dependencias transitivas (acciones que usan las dependencias de su acción), excepto por las dependencias de llamadas de flujo de trabajo reutilizables. Un flujo de trabajo reutilizable está cubierto por el archivo de bloqueo del repositorio donde se define.

¿Qué registra el archivo lockfile?

El archivo de bloqueo tiene dos secciones. workflows registra las dependencias que usa cada flujo de trabajo incorporado y dependencies registra a qué commit se resuelve cada una de esas referencias.

# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
version: 'v0.0.2'
workflows:
    '.github/workflows/ci.yml':
        - 'octo-org/[email protected]'
dependencies:
    'octo-org/[email protected]':
        ref: 'v3.1.0'
        commit: 'sha1-...'
        owner_id: 44036562
        repo_id: 197814629

Cada dependencia registra:

• ref: la referencia que usa el flujo de trabajo, como una etiqueta o una rama.
• commit: El commit exacto al que se resolvió la referencia. Este es el código que se ejecutará.
• owner_id y repo_id: la identidad numérica del repositorio de origen. GitHub Actions los usa para confirmar en tiempo de ejecución que el repositorio detrás del nombre sigue siendo el que ha bloqueado.

¿Cómo se comparan los lockfiles con la fijación por SHA?

GitHub ha recomendado históricamente anclar acciones de terceros a un SHA de confirmación de longitud completa en los archivos de flujo de trabajo. En el caso de los repositorios que adoptan un archivo de bloqueo, el anclaje sha dentro de los archivos de flujo de trabajo ya no es necesario. El archivo de bloqueo es la mejor opción porque admite dependencias transitivas, facilita la lectura de los archivos de flujo de trabajo y registra la identidad del repositorio de origen.

Pasos siguientes

Para crear un archivo de bloqueo para un repositorio, consulte Bloqueo de dependencias de acciones en los flujos de trabajo de un repositorio.