Exigir el uso de archivos de bloqueo para las dependencias de action

Requerir archivos lock le ofrece una garantía coherente y auditable de que cada flujo de trabajo ejecuta código examinado, sin pedir a cada equipo que adopte la práctica por sí solo. Para obtener una introducción, consulta Archivos de bloqueo de dependencias del flujo de trabajo.

Esta guía le ayuda a ejecutar un piloto en repositorios seleccionados y a configurar automatizaciones para mantener actualizados los lockfiles. Cuando esté seguro de que los archivos de bloqueo funcionan según lo previsto y no introducen fricción para desarrolladores, puede aplicar la directiva Requerir archivo de bloqueo .

Prerequisites

Antes de hacer obligatorios los archivos de bloqueo del flujo de trabajo y crear procesos para mantenerlos actualizados, el archivo de bloqueo debe existir en los repositorios. Para obtener instrucciones, consulte Bloqueo de dependencias de acciones en los flujos de trabajo de un repositorio. No es necesario ser administrador para crear un archivo de bloqueo. Cualquier persona con acceso de escritura a un repositorio puede hacerlo, por lo que puede delegar la incorporación a equipos individuales antes de aplicar la directiva de forma centralizada.

Si los flujos de trabajo llaman a flujos de trabajo reutilizables de otros repositorios, confirme que esos repositorios de origen también se hayan incorporado. El archivo de bloqueo del repositorio que realiza la llamada no los cubre. Si un flujo de trabajo reutilizable llamado no se incorpora en su propio repositorio, la directiva Requerir archivo de bloqueo bloquea la ejecución del flujo de trabajo que realiza la llamada.

1. Probar la política "Requerir archivo de bloqueo"

La directiva Require lockfile bloquea las ejecuciones de flujos de trabajo seleccionados que no se han añadido al archivo de bloqueo del repositorio, incluidos los flujos de trabajo sin dependencias de uses:.

Realice una prueba piloto antes de aplicar esta directiva en todos los repositorios. Debería hacer lo siguiente:

• Limita la directiva a repositorios específicos que se han incorporado a lockfiles.
• Dirija los flujos de trabajo específicos que se han incorporado al lockfile, hasta que se incorporen todos los flujos de trabajo y haya automatizado procesos para incorporar nuevos.
• Comience con la directiva en modo Evaluar y analice los resultados en Información de directivas.

Requerir archivo de bloqueo es una directiva independiente de Requerir que las acciones se anclen a un SHA de commit completo. Puede mantener ambos habilitados durante el despliegue. Para configurar la directiva y ver cómo interactúan los dos, consulte Gobernanza de la ejecución de flujos de GitHub Actions trabajo.

2. Mantener los archivos de bloqueo actualizados

La aplicación solo funciona si los lockfiles permanecen actualizados. Agregue automatizaciones para que los desarrolladores no tengan que recordar ejecutar el comando lock cada vez que crean o editan flujos de trabajo.

En las secciones siguientes se proporcionan ejemplos sobre cómo evitar archivos de bloqueo obsoletos en distintos puntos del ciclo de vida de desarrollo:

• Mantenga actualizado el archivo habilitando Dependabot.
• Cree un flujo de trabajo para ejecutar el comando lock y comprobarlo como parte de los requisitos de la solicitud de incorporación de cambios.

Dependabot actualizaciones de versión

Cuando Dependabot actualiza la versión de una acción, vuelve a generar la entrada correspondiente del archivo de bloqueo en la misma solicitud de incorporación de cambios.

No necesita ninguna configuración más allá de que Dependabot gestione las dependencias de GitHub Actions. Consulte Mantener tus acciones actualizadas con el Dependabot.

Dependabot no admitirá un flujo de trabajo que aún no tenga entradas de archivo de bloqueo, por lo que esta opción mantiene la cobertura en lugar de ampliarla.

Un flujo de trabajo dedicado o Copilot

Cuando alguien agrega o edita un flujo de trabajo, ejecuta otro flujo de trabajo que ejecuta el comando lock. Desencadene el flujo de trabajo cuando haya cambios en .github/workflows/** y en cualquier archivo action.yml o action.yaml, y asígnele dos trabajos:

• Un trabajo de actualización que regenera el archivo de bloqueo al hacer push y confirma el resultado. Este trabajo necesita contents: write permisos y las reglas o conjuntos de reglas de protección de rama deben permitir GitHub Actions hacer push en las ramas en las que se ejecuta el flujo de trabajo. La escritura en el archivo de bloqueo requiere el workflow alcance de OAuth, por lo que debe confirmar que las herramientas tienen ese alcance.
• Un trabajo de comprobación que se ejecuta gh actions-lock --verify en las solicitudes de extracción. Esto debería salir con un error si el archivo de bloqueo está obsoleto, lo que hace que sea útil para una comprobación necesaria.

Para obtener un flujo de trabajo de ejemplo listo para usar, consulte verify-lockfile.yml en el gh-actions-lock repositorio. Si usa Copilot para editar flujos de trabajo, también puede configurarlo para volver a generar el archivo de bloqueo en el mismo conjunto de cambios. Consulte la skill gh-actions-lock y Aptitudes del agente.

3. Configurar un proceso de revisión para los cambios en el lockfile

Un lockfile es solo un control de seguridad si alguien lee el diff. Un SHA de commit modificado, en concreto, indica que el código que ejecutan los flujos de trabajo ha cambiado.

1. Agregue .github/workflows/actions.lock a tu archivo CODEOWNERS para que se solicite automáticamente la revisión al equipo responsable de la seguridad de compilación. Consulte Acerca de los propietarios de código.
2. Configura una regla de protección de rama o un conjunto de reglas de repositorio para requerir la aprobación de un propietario del código.
3. Indique a los revisores qué buscar. Para más información, consulta Bloqueo de dependencias de acciones en los flujos de trabajo de un repositorio.

4. Aplicar la directiva

Cuando esté seguro de que los archivos de bloqueo están en su lugar y permanecerán actualizados, cambie el estado de cumplimiento de la directiva Requerir archivo de bloqueo a Activo. Asegúrese de que todos los repositorios y flujos de trabajo incorporados están configurados como destino.

Deje la comprobación del paso 2 en su lugar. La política bloquea una ejecución de flujo de trabajo que no tiene ningún archivo de bloqueo válido. Una comprobación de verificación, por el contrario, indica a un autor que su archivo de bloqueo está obsoleto mientras sigue trabajando en la pull request.

Si falla una comprobación de verificación, consulte la guía de solución de problemas de gh-actions-lock en el repositorio gh-actions-lock.