Skip to main content
Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Eventos que desencadenan flujos de trabajo

Puedes configurar tus flujos de trabajo para que se ejecuten cuando ocurre una actividad específica en GitHub Enterprise Server, en un horario programado o cuando se produce un evento fuera de GitHub Enterprise Server.

Acerca de los eventos que activan flujos de trabajo

Los activadores de los flujos de trabajo son eventos que ocasionan que se ejecute un flujo de trabajo. Para obtener más información sobre cómo utilizar activadores de flujo de trabajo, consulta la sección "Activar un flujo de trabajo".

Eventos disponibles

Algunos eventos tienen tipos de actividad múltiple. Para ellos, puedes especificar qué tipos de actividad activarán una ejecución de flujo de trabajo. Para obtener más información sobre qué significa cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Nota que no todos los eventos de webhook activan flujos de trabajo.

check_run

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
check_run- created
- rerequested
- completed
-requested_action
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. Para obtener más información sobre cada uno de los tipos de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando ocurre actividad relacionada con una ejecución de verificación. Una ejecución de verificación es una prueba individual que forma parte de una suite de verificación. Para obtener más información, consulta la sección "Iniciar con la API de verificaciones". Para obtener más información sobre las API de ejecución de verificación, consulta la sección "CheckRun" en la documentación de la API de GraphQL o "Checks" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una ejecución de verificación esté como rerequested o completed.

on:
  check_run:
    types: [rerequested, completed]

check_suite

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
check_suite- completedÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. Para obtener más información sobre cada uno de los tipos de actividad, consulta la sección "Cargas útiles y eventos de webhook". Aunque solo el tipo de actividad started es compatible, el especificar el tipo de actividad mantendrá a tu flujo de trabajo como específico si se agregan más tipos de actividad en el futuro. Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: Para evitar flujos de trabajo recurrentes, este evento no activa flujos de trabajo si la comprobación de suite fue creada por GitHub Actions.

Ejecuta tu flujo de trabajo cuando ocurre una actividad de suite de verificación. Una suite de verificación es una recolección de ejecuciones de verificación para una confirmación específica. Las suites de verificación resumen el estado y conclusión de las ejecuciones de verificación que están en la suite. Para obtener más información, consulta la sección "Iniciar con la API de verificaciones". Para obtener más información sobre las API de suite de verificación, consulta la sección "CheckSuite" en la documentación de la API de GraphQL o "Checks" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una suite de verificación esté como completed.

on:
  check_suite:
    types: [completed]

create (crear)

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
create (crear)n/aÚltima confirmación en la rama o etiqueta creadaRama o etiqueta creada

Nota: No se creará ningún evento cuando crees más de tres etiquetas a la vez.

Ejecuta tu flujo de trabajo cuando alguien crea una referencia de Git (rama o etiqueta de Git) en el repositorio del flujo de trabajo. Para obtener más información sobre las API para crear una referencia de Git, consulta la sección "createRef" en la documentación de la API de GraphQL o "Crear una referencia" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento crear.

on:
  create

delete

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
deleten/aÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: No se creará ningún evento cuando borres más de tres etiquetas a la vez.

Ejecuta tu flujo de trabajo cuando alguien borra una referencia de Git (rama o etiqueta de Git) en el repositorio del flujo de trabajo. Para obtener más información sobre las API para borrar una referencia de Git, consulta la sección "deleteRef" en la documentación de la API de GraphQL o "Borrar una referencia" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento eliminar.

on:
  delete

deployment

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
deploymentn/aConfirmación de implementaciónRama o etiqueta que se debe desplegar (en blanco si se crea con el SHA de una confirmación)

Ejecuta tu flujo de trabajo cuando alguien crea un despliegue en el repositorio del flujo de trabajo. Las implementaciones creadas con SHA de confirmación pueden no tener una referencia de Git. Para obtener más información sobre las API para crear un despliegue, consulta la sección "createDeployment" en la documentación de la API de GraphQL o "Despliegues" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento implementación.

on:
  deployment

deployment_status

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
deployment_statusn/aConfirmación de implementaciónRama o etiqueta que se debe implementar (vacío si está confirmada)

Nota: Cuando un estado de despliegue se ajusta en inactive, no se activará ninguna ejecución de flujo de trabajo.

Ejecuta tu flujo de trabajo cuando un tercero proporciona un estado de despliegue. Las implementaciones creadas con SHA de confirmación pueden no tener una referencia de Git. Para obtener más información sobre las API para crear un estado de despliegue, consulta la sección "createDeploymentStatus" en la documentación de la API de GraphQL o "Crear un estado de despliegue" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento implementación.

on:
  deployment_status

bifurcación

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
bifurcaciónn/aÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando alguien bifurca un repositorio. Para obtener más información sobre la API de REST, consulta la sección "Crear una bifurcación".

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento de bifurcación.

on:
  fork

gollum

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
gollumn/aÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando alguien crea o actualiza una página de Wiki. Para obtener más información, consulta la sección "Acerca de los wikis".

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento gollum.

on:
  gollum

comentario_propuesta

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
comentario_propuesta- created
- edited
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando se crea, edita o borra un comentario en una propuesta o solicitud de cambios. Para obtener más información sobre las API de comentarios en propuestas, consulta la sección "ssueComment" en la documentación de la API de GraphQL o "comentarios de propuesta" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un comentario en una propuesta o solicitud de cambios se muestre como created o deleted.

on:
  issue_comment:
    types: [created, deleted]

issue_comment solo en propuestas o solicitudes de cambio

El evento issue_comment ocurre para los comentarios tanto en propuestas como en solicitudes de cambios. Puedes utilizar la propiedad github.event.issue.pull_request en un condicional para tomar una acción diferente dependiendo de si el objeto activador fue una propuesta o una solicitud de cambios.

Por ejemplo, este flujo de trabajo ejecutará el job pr_commented únicamente si el evento issue_comment se originó de una solicitud de cambios. Este ejecutará el job issue_commented únicamente si el evento issue_comment se originó desde una propuesta.

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

propuestas

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
propuestas- opened
- edited
- deleted
- transferred
- pinned
- unpinned
- closed
- reopened
- assigned
- unassigned
- labeled
- unlabeled
- locked
- unlocked
- milestoned
- demilestoned
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando se crea o modifica una propuesta en el repositorio de un flujo de trabajo. Para ver la actividad relacionada con los comentarios de una propuesta, utiliza el evento issue_comment. Para obtener más información acerca de los informes de problemas, consulta la sección "Acerca de los informes de problemas". Para obtener la información sobre las API de propuestas, consulta la sección "Propuestas" en la documentación de la API de GraphQL o "Propuestas" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una propuesta ha sido opened (abierta), edited (editada), o milestoned (marcada como hito).

on:
  issues:
    types: [opened, edited, milestoned]

etiqueta

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
etiqueta- created
- edited
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando se crea o modifica una etiqueta en el repositorio del mismo. Para obtener más información sobre las etiquetas, consulta la sección "Administrar etiquetas". Para obtener más información sobre las API de etiquetas, consulta la sección "Etiqueta" en la documentación de la API de GraphQL o "Etiquetas" en la documentación de la API de REST.

Si quieres ejecutar tu flujo de trabajo cuando se agrega o elimina una etiqueta de una propuesta, solicitud de cambios o debate, utiliza los tipos de actividad labeled o unlabeled para los eventos issues, pull_request, pull_request_target o discussion en su lugar.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un miembro ha sido creado o eliminado.

on:
  label:
    types: [created, deleted]

hito

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
hito- created
- closed
- opened
- edited
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando se crea o modifica un hito en el repositorio de tu flujo de trabajo. Para obtener más información sobre los hitos, consulta la sección "Acerca de los hitos". Para obtener más información sobre las API de hitos, consulta "Hito" en la documentación de la API de GraphQL o "Hitos" en la documentación de la API de REST.

Si quieres ejecutar tu flujo de trabajo cuando se agregue o elimine una propuesta de un hito, utiliza los tipos de actividad milestoned o demilestoned para el evento issues en su lugar.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un hito ha sido abierto o eliminado.

on:
  milestone:
    types: [opened, deleted]

page_build

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
page_buildn/aÚltima confirmación en la rama predeterminadan/a

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando alguien sube información a una rama que sea la fuente de publicación de Páginas de GitHub si Páginas de GitHub se encuentra habilitado para el repositorio. Para obtener más información sobre las fuentes de publicación de Páginas de GitHub, consulta la sección "Cojnfigurar una fuente de publicación para tu sitio de GitHub Pages". Para obtener información acerca de la API de REST, consulta la sección "Páginas".

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento page_build.

on:
  page_build

project

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
project- created
- closed
- reopened
- edited
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. El tipo de actividad edited se refiere a cuando se edita un tablero de proyecto, no así una columna o tarjeta de este. Para obtener más información sobre cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: Este evento solo ocurre para proyectos que le pertenecen al repositorio del flujo de trabajo y no para proyectos que pertenezcan a usuarios u organizaciones ni para aquellos que le pertenezcan a otro repositorio.

Ejecuta tu flujo de trabajo cuando se crea o modifica un tablero de proyecto. Para encontrar actividad relacionada con tarjetas o columnas en un tablero de proyecto, utiliza los eventos project_card o project_column en su lugar. Para obtener más información acerca de los tableros de proyecto, consulta la sección "Acerca de los tableros de proyecto". Para obtener más información sobre las API de tablero de proyecto, consulta la sección de "Proyecto" en la documentación de la API de GraphQL o "Proyectos" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un proyecto ha sido creado o eliminado.

on:
  project:
    types: [created, deleted]

project_card

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
project_card- created
- moved
- converted to an issue
- edited
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: Este evento solo ocurre para proyectos que le pertenecen al repositorio del flujo de trabajo y no para proyectos que pertenezcan a usuarios u organizaciones ni para aquellos que le pertenezcan a otro repositorio.

Ejecuta tu flujo de trabajo cuando se crea o modifica una tarjeta en un tablero de proyecto. Para ver la actividad relacionada con las columnas o tableros de proyecto, utiliza el evento project o project_column en su lugar. Para obtener más información acerca de los tableros de proyecto, consulta la sección "Acerca de los tableros de proyecto". Para obtener más información sobre las API de tarjeta de proyecto, consulta la sección "ProjectCard" en la documentación de la API de GraphQL o "Tarjetas de proyecto" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una tarjeta de proyecto se muestre como created o deleted.

on:
  project_card:
    types: [created, deleted]

project_column

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
project_column- created
- updated
- moved
- deleted
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. Para obtener más información sobre cada uno de los tipos de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: Este evento solo ocurre para proyectos que le pertenecen al repositorio del flujo de trabajo y no para proyectos que pertenezcan a usuarios u organizaciones ni para aquellos que le pertenezcan a otro repositorio.

Ejecuta tu flujo de trabajo cuando se crea o modifica una columna en un tablero de proyecto. Para ver la actividad relacionada con las tarjetas o tableros de proyecto, utiliza el evento project o project_card en su lugar. Para obtener más información acerca de los tableros de proyecto, consulta la sección "Acerca de los tableros de proyecto". Para obtener más información sobre las API de columna de proyecto, consulta la sección "ProjectColumn" en la documentación de la API de GraphQL o "Columnas de proyecto" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una columna de proyecto ha sido created o deleted.

on:
  project_column:
    types: [created, deleted]

public

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
publicn/aÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando el repositorio de tu flujo de trabajo cambia de privado a público. Para obtener más información acerca de la API de REST, consulta la sección "Editar repositorios".

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento público.

on:
  public

solicitud_extracción

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
solicitud_extracción- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- converted_to_draft
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
Última confirmación de fusión en la rama GITHUB_REFRama de fusión de PR refs/pull/:prNumber/merge

Nota: Más de un tipo de actividad desencadena este evento. Para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Predeterminadamente, un flujo de trabajo solo se ejecuta cuando el tipo de actividad de en evento de pull_request es opened, synchronize, o reopened. Puedes especificar tipos de actividad diferentes utilizando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Predeterminadamente, solo los tipos de actividad opened, synchronize y reopened activan flujos de trabajo que se ejecutan en el evento pull_request. Para activar flujos de trabajo mediante tipos de actividad diferentes, utiliza la palabra clave types.

Nota: Los flujos de trabajo no se ejecutarán en la actividad de pull_request si la solicitud de cambio tiene un conflicto de fusión. El conflicto de fusión se debe resolver primero.

Por el contrario, los flujos de trabajo con el evento pull_request_target se ejecutarán incluso si la solicitud de cambios presenta un conflicto de fusión. Antes de utilizar el activador pull_request_target, deberás estar consciente de los riesgos de seguridad. Para obtener más información, consulta la sección pull_request_target.

Ejecuta tu flujo de trabajo cuando ocurre alguna actividad en la solicitud de trabajo del repositorio del flujo de trabajo. Por ejemplo, si no se especifican tipos de actividad, el flujo de trabajo se ejecutará cuando se abra o vuelva a abrir una solicitud de cambios o cuando se actualice la rama de encabezado de la misma. Para encontrar actividad relacionada con las revisiones, comentarios de revisión o comentarios de las solicitudes de cambios, utiliza los eventos pull_request_review, pull_request_review_comment o issue_comment en su lugar. Para obtener más información sobre las API de solicitud de cambios, consulta la sección "PullRequest" en la documentación de la API de GraphQL o "Solicitudes de cambios" en la documentación de la API de REST.

Nota que el GITHUB_SHA para este evento es la última confirmación de fusión de la rama fusionada de la solicitud de cambios. Si quieres obtener la ID de confirmación para la última confirmación de la rama de encabezado de la solicitud de cambios, utiliza github.event.pull_request.head.sha en su lugar.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se haya abierto o vuelto a abrir una solicitud de cambios.

on:
  pull_request:
    types: [opened, reopened]

Puedes utilizar el contexto del evento para controlar aún más cuándo se ejecutarán los jobs en tu flujo de trabajo. Por ejemplo, este flujo de trabajo se ejecutará cuando se solicite una revisión en una solicitud de cambios, pero el job specific_review_requested solo se ejecutará cuando se solicite una revisión de octo-team.

on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'

Ejecutar tu flujo de trabajo con base en la rama base o de encabezado de una solicitud de cambios.

Puedes utilizar el filtro branches o branches-ignore para configurar tu flujo de trabajo para que solo se ejecute en solicitudes de cambio que apunten a ramas específicas. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando alguien vuelva a abrir una solicitud de cambios que apunte a una rama cuyo nombre inicie con releases/:

on:
  pull_request:
    types:
      - opened
    branches:    
      - 'releases/**'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajos solo se ejecutará cuando se abra una solicitud de cambios que incluya un cambio en un archivo de JavaScript (.js) en una rama cuyo nombre inicie con releases/:

on:
  pull_request:
    types:
      - opened
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

Para ejecutar un job con base en el nombre de la rama de encabezado de la solicitud de cambios (contrario al nombre de la rama base de dicha solicitud de cambios), utiliza el contexto github.head_ref en un condicional. Por ejemplo, este flujo de trabajo se ejecutará cada que se abra una solicitud de cambios, pero el job run_if solo se ejecutará si el encabezado de la solicitud de cambios es una rama cuyo nombre inicie con releases/:

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Ejecutar tu flujo de trabajo con base en los archivos que cambiaron en una solicitud de cambios

También puedes configurar tu flujo de trabajo para que se ejecute cuando una solicitud de cambios cambie archivos específicos. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando una solicitud de cambios incluya un cambio en un archivo de JavaScript (.js):

on:
  pull_request:
    paths:
      - '**.js'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajos solo se ejecutará cuando se abra una solicitud de cambios que incluya un cambio en un archivo de JavaScript (.js) en una rama cuyo nombre inicie con releases/:

on:
  pull_request:
    types:
      - opened
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

Ejecutar tu flujo de trabajo cuando se fusiona una solicitud de cambios

Cuando se fusiona una solicitud de cambios, esta se cierra automáticamente. Para ejecutar un flujo de trabajo cuando se fusiona una solicitud de cambios, utiliza el tipo de evento pull_request closed junto con una condicional que verifique el valor merged del mismo. Por ejemplo, el siguiente flujo de trabajo se ejecutará cada que se cierre una solicitud de cambios. El job if_merged solo se ejecutará si la solicitud de cambios también se fusionó.

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

Flujos de trabajo en repositorios bifurcados

Los flujos de trabajo no se ejecutan predeterminadamente en los repositorios bifurcados. Debes habilitar las Acciones de GitHub en la pestaña Actions (Acciones) del repositorio bifurcado.

Con la excepción de GITHUB_TOKEN, los secretos no se pasan al ejecutador cuando un flujo de trabajo se dispara desde un repositorio bifurcado. El GITHUB_TOKEN tiene permisos de solo lectura en los repositorios bifurcados. Para obtener más información, consulta "Autenticar con el GITHUB_TOKEN".

Eventos de solicitud de extracción para repositorios bifurcados

En el caso de las solicitudes de cambios desde un repositorio bifurcado hacia un repositorio base, GitHub Enterprise Server enviará los eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review y pull_request_target al repositorio base. No existirán eventos de solicitudes de cambio en el repositorio bifurcado.

Nota: los flujos de trabajo no se ejecutan en repositorios base privados cuando abres una solicitud de extracción desde un repositorio bifurcado.

Nota: Los flujos de trabajo que se activan mediante las solicitudes de cambios del Dependabot se tratan como si fueran de un repositorio bifurcado y también están sujetas a estas restricciones.

pull_request_comment (utiliza issue_comment)

Para ejecutar tu flujo de trabajo cuando se crea, edita o borra un comentario en una solicitud de cambios (no así en un diff de esta), utiliza el evento issue_comment. Para encontrar actividad relacionada con las revisiones de solicitudes de cambios o comentarios de revisión de estas, utiliza los eventos pull_request_review o pull_request_review_comment.

revisión_solicitud de extracción

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
revisión_solicitud de extracción- submitted
- edited
- dismissed
Última confirmación de fusión en la rama GITHUB_REFRama de fusión de PR refs/pull/:prNumber/merge

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Ejecuta tu flujo de trabajo cuando se emite, edita o descarta una revisión de una solicitud de cambios. Una revisión de solicitud de cambios es un grupo de comentarios de dicha revisión junto con un comentario del cuerpo y un estado. Para encontrar actividad relacionada con los comentarios o comentarios de revisión de una solicitud de cambios, utiliza los eventos pull_request_review_comment o issue_comment en su lugar. Para obtener más información acerca de las API de revisión de solicitudes de cambio, consulta la sección "PullRequestReview" en la documentación de la API de GraphQL o "Revisiones de solicitudes de cambio" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una revisión de solicitud de extracción ha sido editada o descartada.

on:
  pull_request_review:
    types: [edited, dismissed]

Ejecutar un flujo de trabajo cuando se aprueba una solicitud de cambios

Para ejecutar tu flujo de trabajo cuando se aprobó una solicitud de cambios, puedes activarlo con el tipo submitted del evento pull_request_review y luego verificar el estado de revisión con la propiedad github.event.review.state. Por ejemplo, este flujo de trabajo se ejecutará cada que se emita una revisión de solicitud de cambios, pero el job approved solo se ejecutará si la revisión emitida es una aprobada:

on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"

Flujos de trabajo en repositorios bifurcados

Los flujos de trabajo no se ejecutan predeterminadamente en los repositorios bifurcados. Debes habilitar las Acciones de GitHub en la pestaña Actions (Acciones) del repositorio bifurcado.

Con la excepción de GITHUB_TOKEN, los secretos no se pasan al ejecutador cuando un flujo de trabajo se dispara desde un repositorio bifurcado. El GITHUB_TOKEN tiene permisos de solo lectura en los repositorios bifurcados. Para obtener más información, consulta "Autenticar con el GITHUB_TOKEN".

Eventos de solicitud de extracción para repositorios bifurcados

En el caso de las solicitudes de cambios desde un repositorio bifurcado hacia un repositorio base, GitHub Enterprise Server enviará los eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review y pull_request_target al repositorio base. No existirán eventos de solicitudes de cambio en el repositorio bifurcado.

Nota: los flujos de trabajo no se ejecutan en repositorios base privados cuando abres una solicitud de extracción desde un repositorio bifurcado.

Nota: Los flujos de trabajo que se activan mediante las solicitudes de cambios del Dependabot se tratan como si fueran de un repositorio bifurcado y también están sujetas a estas restricciones.

comentarios _revisiones_solicitudes de extracción

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
comentarios _revisiones_solicitudes de extracción- created
- edited
- deleted
Última confirmación de fusión en la rama GITHUB_REFRama de fusión de PR refs/pull/:prNumber/merge

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Ejecuta tu flujo de trabajo cuando se modifica un comentario de una revisión de solicitud de cambios. Un comentario de revisión de una solicitud de cambios es un comentario en el diff de dicha solicitud. Para encontrar actividad relacionada con las revisiones o comentarios de las solicitudes de cambio, utiliza los eventos pull_request_review o issue_comment en su lugar. Para obtener más información acerca de las API de comentarios de las revisiones de solicitudes de cambio, consulta la sección "PullRequestReviewComment" en la documentación de la API de GraphQL o "Comentarios de revisión" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un comentario de revisión de solicitud de extracción ha sido creado o eliminado.

on:
  pull_request_review_comment:
    types: [created, deleted]

Flujos de trabajo en repositorios bifurcados

Los flujos de trabajo no se ejecutan predeterminadamente en los repositorios bifurcados. Debes habilitar las Acciones de GitHub en la pestaña Actions (Acciones) del repositorio bifurcado.

Con la excepción de GITHUB_TOKEN, los secretos no se pasan al ejecutador cuando un flujo de trabajo se dispara desde un repositorio bifurcado. El GITHUB_TOKEN tiene permisos de solo lectura en los repositorios bifurcados. Para obtener más información, consulta "Autenticar con el GITHUB_TOKEN".

Eventos de solicitud de extracción para repositorios bifurcados

En el caso de las solicitudes de cambios desde un repositorio bifurcado hacia un repositorio base, GitHub Enterprise Server enviará los eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review y pull_request_target al repositorio base. No existirán eventos de solicitudes de cambio en el repositorio bifurcado.

Nota: los flujos de trabajo no se ejecutan en repositorios base privados cuando abres una solicitud de extracción desde un repositorio bifurcado.

Nota: Los flujos de trabajo que se activan mediante las solicitudes de cambios del Dependabot se tratan como si fueran de un repositorio bifurcado y también están sujetas a estas restricciones.

pull_request_target

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
solicitud_extracción- assigned
- unassigned
- labeled
- unlabeled
- opened
- edited
- closed
- reopened
- synchronize
- converted_to_draft
- ready_for_review
- locked
- unlocked
- review_requested
- review_request_removed
- auto_merge_enabled
- auto_merge_disabled
Última confirmación en la rama base de la solicitud de extracciónRama base de la solicitud de extracción

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Predeterminadamente, un flujo de trabajo se ejecuta únicamente cuando el tipo de actividad de un pull_request_target se encuentra como opened, synchronize, o reopened. Para activar los flujos de trabajo para más tipos de actividades, usa la palabra clave tipos. Puedes especificar tipos de actividad diferentes utilizando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Predeterminadamente, solo los tipos de actividad opened, synchronize y reopened activan flujos de trabajo que se ejecutan en el evento pull_request. Para activar flujos de trabajo mediante tipos de actividad diferentes, utiliza la palabra clave types.

Ejecuta tu flujo de trabajo cuando ocurre alguna actividad en la solicitud de trabajo del repositorio del flujo de trabajo. Por ejemplo, si no se especifican tipos de actividad, el flujo de trabajo se ejecutará cuando se abra o vuelva a abrir una solicitud de cambios o cuando se actualice la rama de encabezado de la misma.

Este evento se ejecuta en el contexto de la base de la solicitud de cambios en vez de en aquel de la confirmación de fusión, como lo hace el evento pull_request. Esto previene la ejecución del código no seguro desde el encabezado de la solicitud de cambios que pudiera alterar tu repositorio o robar cualquier secreto que utilices en tu flujo de trabajo. Este evento permite que tu flujo de trabajo haga cosas como etiquetar o comentar en las solicitudes de cambios de las bifurcaciones. Evita utilizar este evento si necesitas compilar o ejecutar código desde la solicitud de cambios.

Advertencia: En el caso de los flujos de trabajo que se activan con el evento pull_request_target, se otorgarán permisos de lectura/escritura en el repositorio al GITHUB_TOKEN a menos de que se especifique la clave permissions y que el flujo de trabajo pueda acceder a los secretos, incluso cuando se activa desde una bifurcación. Aunque las ejecuciones de flujo de trabajo se ejecutan en el contexto de la base de la solicitud de cambios, debes asegurarte de que no revisas, compilas o ejecutas código no confiable desde ella con este evento. Adicionalmente, cualquier caché comparte el mismo alcance que la rama base. Para ayudar a prevenir el envenenamiento del caché, no debes guardar el caché si existe la posibilidad de que su contenido se haya alterado. Para obtener más información, consulta la sección "Mantener seguros tus GitHub Actions y flujos de trabajo: Prevenir solicitudes de pwn" en el sitio web de GitHub Security Lab.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando una solicitud de extracción ha sido assigned (asignada), opened, syncronize o reopened.

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

Ejecutar tu flujo de trabajo con base en la rama base o de encabezado de una solicitud de cambios.

Puedes utilizar el filtro branches o branches-ignore para configurar tu flujo de trabajo para que solo se ejecute en solicitudes de cambio que apunten a ramas específicas. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando alguien vuelva a abrir una solicitud de cambios que apunte a una rama cuyo nombre inicie con releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:    
      - 'releases/**'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajos solo se ejecutará cuando se abra una solicitud de cambios que incluya un cambio en un archivo de JavaScript (.js) en una rama cuyo nombre inicie con releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

Para ejecutar un job con base en el nombre de la rama de encabezado de la solicitud de cambios (contrario al nombre de la rama base de dicha solicitud de cambios), utiliza el contexto github.head_ref en un condicional. Por ejemplo, este flujo de trabajo se ejecutará cada que se abra una solicitud de cambios, pero el job run_if solo se ejecutará si el encabezado de la solicitud de cambios es una rama cuyo nombre inicie con releases/:

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Ejecutar tu flujo de trabajo con base en los archivos que cambiaron en una solicitud de cambios

Puedes utilizar el filtro paths o paths-ignore para configurar tu flujo de trabajo para que se ejecute cuando una solicitud de cambios cambie archivos específicos. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando una solicitud de cambios incluya un cambio en un archivo de JavaScript (.js):

on:
  pull_request_target:
    paths:
      - '**.js'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajos solo se ejecutará cuando se abra una solicitud de cambios que incluya un cambio en un archivo de JavaScript (.js) en una rama cuyo nombre inicie con releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

Ejecutar tu flujo de trabajo cuando se fusiona una solicitud de cambios

Cuando se fusiona una solicitud de cambios, esta se cierra automáticamente. Para ejecutar un flujo de trabajo cuando se fusiona una solicitud de cambios, utiliza el tipo de evento pull_request_target closed junto con una condicional que verifique el valor merged del mismo. Por ejemplo, el siguiente flujo de trabajo se ejecutará cada que se cierre una solicitud de cambios. El job if_merged solo se ejecutará si la solicitud de cambios también se fusionó.

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

subir

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
subirn/aConfirmación subida, a menos que se elimine una rama (cuando se trata de la rama por defecto)Ref actualizado

Nota: La carga disponible del webhook para las Acciones de GitHub no incluye los atributos añadidos, eliminados, y modificados en el objeto de confirmación. Puedes recuperar el objeto de confirmación completo utilizando la API. Para obtener información, consulta la sección "Confirmación" en la documentación de la API de GraphQL o "Obtén una confirmación" en la documentación de la API de REST.

Nota: No se creará ningún evento cuando subas más de tres etiquetas a la vez.

Ejecuta tu flujo de trabajo cuando subes una confirmación o etiqueta.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento push.

on:
  push

Ejecutar tu flujo de trabajo solo cuando ocurra una subida de información a ramas específicas

Puedes utilizar el filtro branches o branches-ignore para configurar tu flujo de trabajo para que solo se ejecute cuando se suben ramas específicas. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando alguien suba información a la rama main o a alguna que inicie con releases/.

on:
  push:
    branches:    
      - 'main'
      - 'releases/**'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajo solo se ejecutará cuando se haga una subida que incluya un cambio a un archivo de JavaScript (.js) a una rama cuyo nombre inicie con releases/:

on:
  push:
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

Ejecutar tu flujo de trabajo únicamente cuando ocurra una subida de etiquetas específicas

Puedes utilizar el filtro tags o tags-ignore para configurar que tu flujo de trabajo solo se ejecute cuando se suban etiquetas específicas. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando alguien suba una etiqueta que inicie con v1..

on:
  push:
    tags:        
      - v1.**

Ejecutar tu flujo de trabajo únicamente cuando una subida de información afecta archivos específicos

Puedes utilizar el filtro paths o paths-ignore para configurar que tu flujo de trabajo se ejecute cuando ocurra una subida de archivos específicos. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".

Por ejemplo, este flujo de trabajo se ejecutará cuando alguien suba un cambio a un archivo de JavaScript (.js):

on:
  push:
    paths:
      - '**.js'

Nota: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. Por ejemplo, el siguiente flujo de trabajo solo se ejecutará cuando se suba información que incluya un cambio a un archivo de JavaScript (.js) en una rama cuyo nombre inicie con releases/:

on:
  push:
    branches:    
      - 'releases/**'
    paths:
      - '**.js'

registry_package

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
registry_package- published
- updated
Confirmación del paquete publicadoRama o etiqueta del paquete publicado

Nota: Más de un tipo de actividad desencadena este evento. para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando ocurre actividad relacionada con el Registro del paquete de GitHub en tu repositorio. Para obtener más información, consulta la "Documentación del Registro del paquete de GitHub".

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un paquete ha sido publicado.

on:
  registry_package:
    types: [published]

lanzamiento

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
lanzamiento- published
- unpublished
- created
- edited
- deleted
- prereleased
- released
Última confirmación en el lanzamiento etiquetadoRef de etiqueta de lanzamiento refs/tags/<tag_name>

Nota: Más de un tipo de actividad desencadena este evento. Para obtener más información acerca de cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Los flujos de trabajo no se ejecutan para los tipos de actividad created, edited, o deleted en los borradores de lanzamiento. Cuando creas tu lanzamiento mediante el la IU del buscador de GitHub Enterprise Server, este podría guardarse automáticamente como borrador.

Nota: El tipo prereleased no se activará para los pre-lanzamientos publicados desde los borradores de lanzamientos, pero el tipo published sí lo hará. Si quieres que se ejecute un flujo de trabajo cuando se publiquen los lanzamientos estables y los pre-lanzamientos, mejor suscríbete a published en vez de a released y prereleased.

Ejecuta tu flujo de trabajo cuando ocurre una actividad de lanzamiento en tu repositorio. Para obtener más información sobre las API de lanzamiento, consulta la sección de "Lanzamiento" en la documentación de la API de GraphQL o "Lanzamientos" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando un lanzamiento ha sido publicado.

on:
  release:
    types: [published]

repository_dispatch

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
repository_dispatchPersonalizadoÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Puedes utilizar la API de GitHub Enterprise Server para activar un evento de webhook llamado repository_dispatch cuando quieras activar un flujo de trabajo para una actividad que suceda fuera de GitHub Enterprise Server. Para obtener más información, consulta la sección "Crear un evento de envío de repositorio".

Cuando haces una solicitud para crear un evento de repository_dispatch, debes especificar un event_type para describir el tipo de actividad. Predeterminadamente, todos los tipos de actividad repository_dispatch activan un flujo de trabajo para que se ejecute. Puedes utilizar la palabra clave types para limitar la ejecución de tu flujo de trabajo cuando se envíe un valor específico de event_type en la carga útil de webhook repository_dispatch.

on:
  repository_dispatch:
    types: [on-demand-test]

Nota: El valor event_type se limita a 100 caracteres.

Cualquier dato que envíes a través del parámetro client_payload estará disponible en el contexto github.event en tu flujo de trabajo. Por ejemplo, si envías este cuerpo de solicitud cuando creas un evento de despacho de repositorio:

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

luego, puedes acceder a la carga útil en un flujo de trabajo como este:

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

programación

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
n/an/aÚltima confirmación en la rama predeterminadaRama por defecto

Nota: El evento de schedule puede retrasarse durante periodos de cargas algas de ejecuciones de flujo de trabajo de GitHub Actions. Los tiempos de carga alta incluyen el inicio de cada hora. Para aminorar la posibilidad de los retrasos, programa tu flujo de trabajo para que se ejecute en una porción diferente de la hora.

El evento schedule te permite activar un flujo de trabajo en una hora programada.

Puedes programar un flujo de trabajo para que se ejecute en horarios UTC específicos usando sintaxis de cron POSIX. Los flujos de trabajo programados se ejecutan en la confirmación más reciente en la rama base o en la rama por defecto. El intervalo más corto en el que puedes programar flujos de trabajo es cada 5 minutos.

Este ejemplo activa el flujo de trabajo diariamente a las 5:30 y 17:30 UTC:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

Se puede activar un flujo de trabajo sencillo mediante eventos múltiples de schedule. Puedes acceder al evento de programación que activó el flujo de trabajo mediante el contexto github.event.schedule. Este ejemplo activa el flujo de trabajo para que se ejecute a las 5:30 UTC cada lunes a viernes, pero se salta el paso Not on Monday or Wednesday para los lunes y miércoles.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

La sintaxis de cron tiene cinco campos separados por un espacio, y cada campo representa una unidad de tiempo.

┌───────────── minuto (0 - 59)
│ ┌───────────── hora (0 - 23)
│ │ ┌───────────── día del mes (1 - 31)
│ │ │ ┌───────────── mes (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── día de la semana (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

Puedes usar estos operadores en cualquiera de los cinco campos:

OperadorDescripciónEjemplo
*Cualquier valor15 * * * * se ejecuta a cada minuto 15 de cada hora de cada día.
,Separador de la lista de valores2,10 4,5 * * * se ejecuta en el minuto 2 y 10 de la cuarta y quinta hora de cada día.
-Rango de valores30 4-6 * * * se ejecuta en el minuto 30 de la 4ta, 5ta y 6ta hora.
/Valores del paso20/15 * * * * se ejecuta cada 15 minutos a partir del minuto 20 hasta el minuto 59 (minutos 20, 35 y 50).

Nota: GitHub Actions no es compatible con la sintaxis que no es estándar @yearly, @monthly, @weekly, @daily, @hourly y @reboot.

Puedes usar contrab guru para generar tu sintaxis de cron y confirmar a qué hora se ejecutará. Para que puedas comenzar, hay también una lista de ejemplos de crontab guru.

Las notificaciones para los flujos de trabajo programados se envían al usuario que modificó por última vez la sintaxis de cron en el archivo de flujo de trabajo. Para obtener más información, consulta la sección "Notificaciones para las ejecuciones de flujo de trabajo".

estado

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
estadon/aÚltima confirmación en la rama predeterminadan/a

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando cambia el estado de una confirmación de Git. Por ejemplo, las confirmaciones pueden marcarse como error, failure, pending o success. Si quieres proporcionar más detalles sobre el cambio de estado, puede que quieras utilizar el evento check_run. Para obtener más información sobre las API de estado de confirmación, consulta la sección "Estado" en la documentación de la API de GraphQL o "Estados" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando se produzca el evento status.

on:
  status

Si quieres ejecutar un job en tu flujo de trabajo con base en el estado de confirmación nuevo, puedes utilizar el contexto github.event.state. Por ejemplo, el siguiente flujo de trabajo se activa cuando cambia un estado de confirmación, pero el job if_error_or_failure solo se ejecuta si el estado de confirmación nuevo es error o failure.

on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION

observar

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
observar- startedÚltima confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. Aunque solo el tipo de actividad started es compatible, el especificar el tipo de actividad mantendrá tu flujo de trabajo específico si se agregan más tipos de actividad en el futuro. Para obtener más información sobre cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Ejecuta tu flujo de trabajo cuando su repositorio se marcó como favorito. Para obtener más información sobre las API de solicitud de cambios, consulta la sección "addStar" en la documentación de la API de GraphQL o "Marcar como favorito" en la documentación de la API de REST.

Por ejemplo, puedes ejecutar un flujo de trabajo cuando alguien marca un repositorio como favorito, lo cual es el tipo de actividad started para un evento de observación.

on:
  watch:
    types: [started]

workflow_dispatch

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
workflow_dispatchn/aÚltima confirmacion en la rama de GITHUB_REFRama que recibió el envío

Para activar un flujo de trabajo manualmente, utiliza el evento workflow_dispatch. Puedes activar un flujo de trabajo manualmente utilizando la API de GitHub Enterprise Server, el CLI de GitHub o la interfaz de buscador de GitHub Enterprise Server. Para obtener más información, consulta la sección "Ejecutar un flujo de trabajo manualmente".

on: workflow_dispatch

Proporcionar entradas

Puedes configurar propiedades de entrada definidas personalmente, valores de entrada predeterminados y entradas requeridas para el evento directamente en tu flujo de trabajo. Cuando activas el evento, puedes proporcionar el ref y cualquier inputs. Cuando se ejecuta el flujod e trabajo, puedes acceder a los valores de entrada en el contexto de github.event.inputs. Para obtener más información, consulta "Contextos".

Este ejemplo define las entradas name y home y las imprime utilizando los contextos github.event.inputs.name y github.event.inputs.home. Si no se proporciona un home, se imprime el valor predeterminado 'The Octoverse'.

name: Manually triggered workflow
on:
  workflow_dispatch:
    inputs:
      name:
        description: 'Person to greet'
        required: true
        default: 'Mona the Octocat'
      home:
        description: 'location'
        required: false
        default: 'The Octoverse'

jobs:
  say_hello:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo Hello $NAME!
          echo -in $HOME
        env:
          NAME: ${{ github.event.inputs.name }}
          HOME: ${{ github.event.inputs.home }}

workflow_run

Carga del evento WebhookTipos de actividadGITHUB_SHAGITHUB_REF
workflow_run- completed
- requested
Última confirmación en la rama predeterminadaRama predeterminada

Nota: Más de un tipo de actividad desencadena este evento. El tipo de actividad requested no ocurre cuando se vuelve a ejecutar un flujo de trabajo. Para obtener más información sobre cada tipo de actividad, consulta la sección "Cargas útiles y eventos de webhook". Por defecto, todos los tipos de actividad desencadenan un flujo de trabajo a ejecutarse. Puedes limitar tus ejecuciones de flujo de trabajo a tipos de actividad específicos usando la palabra clave types. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".

Nota: Este evento solo activará una ejecución de flujo de trabajo si el archivo de flujo de trabajo está en la rama predeterminada.

Nota: No puedes utilizar workflow_run para concatenar más de tres niveles de flujos de trabajo. Por ejemplo, si intentas activar cinco flujos de trabajo (denominados de la B a la F) para que se ejecuten secuencialmente después de que el flujo de trabajo inicial A se ejecute (esto quiere decir: ABCDEF), los flujos de trabajo E y F no se ejecutarán.

Este evento ocurre cuando se solicita o completa una ejecución de flujo de trabajo. Te permite ejecutar un flujo de trabajo con base en una ejecución o compleción de otro de ellos. El flujo de trabajo que inició el evento workflow_run puede acceder a secretos y tokens de escritura, incluso si el flujo de trabajo anterior no podía hacerlo. Esto es útil en los casos en que el flujo de trabajo anterior no tiene privilegios intencionalmente, pero necesitas tomar una acción que requiere de privilegios en un flujo de trabajo subsecuente.

En este ejemplo, se configura un flujo de trabajo para que se ejecute después de que se complete el flujo de trabajo separado de "Run Tests".

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

Si especificas workflows múltiples para el evento workflow_run, solo uno de estos flujos de trabajo necesitará ejecutarse. Por ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cada que se complete el flujo de trabajo "Staging" o "Lab".

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

Ejecutar un flujo de trabajo con base en la conclusión de otro flujo de trabjo

Los flujos de trabajo se activan sin importar la conclusión del flujo previo. Si quieres ejecutar un job o paso con base en el resultado del flujo de trabajo desencadenante, puedes utilizar una condicional con la propiedad github.event.workflow_run.conclusion. Por ejemplo, esta ejecución de flujo de trabajo se ejecutará cada que otro flujo de nombre "Build" se complete, pero el job on-success solo se ejecutará si "Build" se completa con éxito y el job on-failure solo se ejecutará si el flujo de trabajo "Build" falla:

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

Ltimitar tu flujo de trabajo para que se ejecute con base a las ramas

Puedes utilizar el filtro branches o branches-ignore para especificar en qué ramas se debe ejecutar el flujo de trabajo activador para poder activar tu flujo de trabajo. Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions". Por ejemplo, un flujo de trabajo con el siguiente activador solo se ejecutará cuando el flujo de trabajo que se llama Build se ejecute en una rama llamada canary.

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

Utilizar datos desde el flujo de trabajo llamante

Puedes acceder a la carga útil del evento workflow_run que corresponde al flujo de trabajo que activó el tuyo. Por ejemplo, si tu flujo de trabajo activador genera artefactos, los flujos de trabajo que se activen con el evento workflow_run podrán acceder a estos artefactos.

El siguiente flujo de trabajo carga datos como un artefacto. (En este ejemplo simplificado, los datos son el número de la solicitud de cambios).

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:        
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v2
        with:
          name: pr_number
          path: pr/

Cuando se complete una ejecución del flujo de trabajo anterior, este activará una ejecución del siguiente. El siguiente flujo de trabajo utiliza el contexto github.event.workflow_run y la API de REST de GitHub Enterprise Server para descargar el artefacto que cargó el flujo de trabajo anterior, descomprime el artefacto descargado y comenta en la solicitud de cambios cuyo número se haya subido como un artefacto.

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v5
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v5
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });