GITHUB_TOKEN

Obtenga información sobre qué GITHUB_TOKEN es, cómo funciona y por qué es importante para la automatización segura en GitHub Actions los flujos de trabajo.

En este artículo

Acerca de GITHUB_TOKEN

Al inicio de cada tarea del flujo de trabajo, GitHub crea automáticamente un secreto GITHUB_TOKEN único para usarlo en el flujo de trabajo. Puede usar GITHUB_TOKEN para autenticarse en el trabajo del flujo.

Al habilitar GitHub Actions, GitHub instala un GitHub App en el repositorio. El GITHUB_TOKEN secreto es un GitHub App token de acceso de instalación. Puede usar el token de acceso de instalación para autenticarse en nombre de la aplicación instalada GitHub App en su repositorio. Los permisos del token están limitados al repositorio que contiene tu flujo de trabajo. Para obtener más información, vea Sintaxis del flujo de trabajo para Acciones de GitHub.

Antes de que comience cada trabajo, GitHub captura un token de acceso de instalación para el trabajo. GITHUB_TOKEN expira cuando el trabajo finaliza o después de su vida útil máxima efectiva.

La vida útil máxima efectiva del token depende del tipo de ejecutor:

  • GitHubEjecutores alojados El tiempo máximo de ejecución del trabajo es de 6 horas, por lo que GITHUB_TOKEN puede existir durante un máximo de 6 horas.
  • Ejecutores autohospedados El tiempo máximo de ejecución del trabajo es de 5 días. Sin embargo, dado que el GITHUB_TOKEN es un token de acceso de instalación, solo se puede actualizar durante hasta 24 horas. Si el trabajo se ejecuta más de 24 horas, use en su lugar un personal access token método de autenticación u otro.

El token también está disponible en el contexto de github.token. Para obtener más información, vea Contextos de referencia.

Cuando GITHUB_TOKEN desencadena ejecuciones de flujos de trabajo

Cuando se usa el repositorio GITHUB_TOKEN para realizar tareas, los eventos desencadenados por GITHUB_TOKEN no crearán una nueva ejecución de flujo de trabajo, con las siguientes excepciones:

  • workflow_dispatch y repository_dispatch los eventos siempre crean ejecuciones de flujo de trabajo.
  • pull_request eventos con los tipos de actividad opened, synchronize o reopened: cuando un flujo de trabajo que usa GITHUB_TOKEN crea o actualiza una solicitud de extracción, el evento pull_request resultante genera ejecuciones de flujo de trabajo en estado de aprobación obligatoria. La solicitud de incorporación de cambios muestra un banner en el cuadro de combinación, y un usuario con acceso de escritura al repositorio puede iniciar las ejecuciones seleccionando Aprobar flujos de trabajo para ejecutar. Otros pull_request tipos de actividad (como labeled, editedo closed) no crean ejecuciones de flujo de trabajo. Esto evita que se ejecute un flujo de trabajo recursivo mientras se permiten que los flujos de trabajo de CI se ejecuten en las solicitudes de incorporación de cambios creadas por la automatización. Para obtener más información sobre cómo aprobar ejecuciones de flujo de trabajo, consulte Aprobación de ejecuciones de flujo de trabajo desde bifurcaciones.

Para todos los demás eventos, este comportamiento impide que cree accidentalmente ejecuciones de flujo de trabajo recursivas. Por ejemplo, si una ejecución de flujo de trabajo inserta código mediante GITHUB_TOKEN del repositorio, un nuevo flujo de trabajo no se ejecutará incluso cuando el repositorio contenga un flujo de trabajo configurado para ejecutarse cuando se produzcan eventos push.

Nota:

Si necesita que las ejecuciones del flujo de trabajo de solicitudes de incorporación de cambios creadas por el propio flujo de trabajo se ejecuten sin necesidad de aprobación, use un token de acceso de instalación de GitHub App o un personal access token en lugar de GITHUB_TOKEN al crear o actualizar la solicitud de incorporación de cambios.

Las confirmaciones insertadas por un flujo de trabajo de GitHub Actions que usa GITHUB_TOKEN no desencadenan una compilación de GitHub Pages.

Pasos siguientes