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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_run | - created - rerequested - completed - requested_action | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_suite | - completed | Última confirmación en la rama predeterminada | Rama 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. Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
create (crear) | n/a | Última confirmación en la rama o etiqueta creada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
delete | n/a | Última confirmación en la rama predeterminada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment | n/a | Confirmación de implementación | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment_status | n/a | Confirmación de implementación | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
bifurcación | n/a | Última confirmación en la rama predeterminada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
gollum | n/a | Última confirmación en la rama predeterminada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
comentario_propuesta | - created - edited - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
propuestas | - opened - edited - deleted - transferred - pinned - unpinned - closed - reopened - assigned - unassigned - labeled - unlabeled - locked - unlocked - milestoned - demilestoned | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
etiqueta | - created - edited - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
hito | - created - closed - opened - edited - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
page_build | n/a | Última confirmación en la rama predeterminada | n/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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project | - created - closed - reopened - edited - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_card | - created - moved - converted to an issue- edited - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_column | - created - updated - moved - deleted | Última confirmación en la rama predeterminada | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
public | n/a | Última confirmación en la rama predeterminada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_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_REF | Rama 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
. Para activar los flujos de trabajo de acuerdo a sus tipos de actividad, utiliza 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 ejecutarán en la actividad de pull_request
si la solicitud de cambios tiene un conflicto de fusión. The merge conflict must be resolved first.
Conversely, workflows with the pull_request_target
event will run even if the pull request has a merge conflict. Before using the pull_request_target
trigger, you should be aware of the security risks. For more information, see pull_request_target
.
Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated. For activity related to pull request reviews, pull request review comments, or pull request comments, use the pull_request_review
, pull_request_review_comment
, or issue_comment
events instead. For information about the pull request APIs, see "PullRequest" in the GraphQL API documentation or "Pull requests" in the REST API documentation.
Note that GITHUB_SHA
for this event is the last merge commit of the pull request merge branch. If you want to get the commit ID for the last commit to the head branch of the pull request, use github.event.pull_request.head.sha
instead.
For example, you can run a workflow when a pull request has been opened or reopened.
on:
pull_request:
types: [opened, reopened]
You can use the event context to further control when jobs in your workflow will run. For example, this workflow will run when a review is requested on a pull request, but the specific_review_requested
job will only run when a review by octo-team
is requested.
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.
You can use the branches
or branches-ignore
filter to configure your workflow to only run on pull requests that target specific branches. For more information, see "Workflow syntax for GitHub Actions."
For example, this workflow will run when someone opens a pull request that targets a branch whose name starts with releases/
:
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
Nota: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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'
To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the github.head_ref
context in a conditional. For example, this workflow will run whenever a pull request is opened, but the run_if
job will only execute if the head of the pull request is a branch whose name starts with 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
You can also configure your workflow to run when a pull request changes specific files. For more information, see "Workflow syntax for GitHub Actions."
For example, this workflow will run when a pull request includes a change to a JavaScript file (.js
):
on:
pull_request:
paths:
- '**.js'
Nota: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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
When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the pull_request
closed
event type along with a conditional that checks the merged
value of the event. For example, the following workflow will run whenever a pull request closes. The if_merged
job will only run if the pull request was also merged.
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
)
To run your workflow when a comment on a pull request (not on a pull request's diff) is created, edited, or deleted, use the issue_comment
event. For activity related to pull request reviews or pull request review comments, use the pull_request_review
or pull_request_review_comment
events.
revisión_solicitud de extracción
Carga del evento Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
revisión_solicitud de extracción | - submitted - edited - dismissed | Última confirmación de fusión en la rama GITHUB_REF | Rama de fusión de PR refs/pull/:prNumber/merge |
Note: Más de un tipo de actividad desencadena este evento. For information about each activity type, see "Webhook events and payloads." Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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".
Runs your workflow when a pull request review is submitted, edited, or dismissed. A pull request review is a group of pull request review comments in addition to a body comment and a state. For activity related to pull request review comments or pull request comments, use the pull_request_review_comment
or issue_comment
events instead. For information about the pull request review APIs, see "PullRequestReview" in the GraphQL API documentation or "Pull request reviews" in the REST API documentation.
For example, you can run a workflow when a pull request review has been edited
or dismissed
.
on:
pull_request_review:
types: [edited, dismissed]
Ejecutar un flujo de trabajo cuando se aprueba una solicitud de cambios
To run your workflow when a pull request has been approved, you can trigger your workflow with the submitted
type of pull_request_review
event, then check the review state with the github.event.review.state
property. For example, this workflow will run whenever a pull request review is submitted, but the approved
job will only run if the submitted review is an approving review:
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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
comentarios _revisiones_solicitudes de extracción | - created - edited - deleted | Última confirmación de fusión en la rama GITHUB_REF | Rama de fusión de PR refs/pull/:prNumber/merge |
Note: Más de un tipo de actividad desencadena este evento. For information about each activity type, see "Webhook events and payloads." Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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".
Runs your workflow when a pull request review comment is modified. A pull request review comment is a comment on a pull request's diff. For activity related to pull request reviews or pull request comments, use the pull_request_review
or issue_comment
events instead. For information about the pull request review comment APIs, see "PullRequestReviewComment" in the GraphQL API documentation or "Review comments" in the REST API documentation.
For example, you can run a workflow when a pull request review comment has been created
or deleted
.
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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_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ón | Rama base de la solicitud de extracción |
Note: Más de un tipo de actividad desencadena este evento. For information about each activity type, see "Webhook events and payloads." By default, a workflow only runs when a pull_request_target
event's activity type is opened
, synchronize
, or reopened
. Para activar los flujos de trabajo de acuerdo a sus tipos de actividad, utiliza la palabra clave types
. Para obtener más información, consulta "Sintaxis del flujo de trabajo para GitHub Actions".
Runs your workflow when activity on a pull request in the workflow's repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.
This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request
event does. This prevents execution of unsafe code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.
Warning: For workflows that are triggered by the pull_request_target
event, the GITHUB_TOKEN
is granted read/write repository permission unless the permissions
key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Adicionalmente, cualquier caché comparte el mismo alcance que la rama base. Para ayudar a prevenir el envenenamiento del caché, no debes guardarlo 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 cambios esté como assigned
, 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.
You can use the branches
or branches-ignore
filter to configure your workflow to only run on pull requests that target specific branches. For more information, see "Workflow syntax for GitHub Actions."
For example, this workflow will run when someone opens a pull request that targets a branch whose name starts with releases/
:
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
Nota: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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'
To run a job based on the pull request's head branch name (as opposed to the pull request's base branch name), use the github.head_ref
context in a conditional. For example, this workflow will run whenever a pull request is opened, but the run_if
job will only execute if the head of the pull request is a branch whose name starts with 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. For more information, see "Workflow syntax for GitHub Actions."
For example, this workflow will run when a pull request includes a change to a JavaScript file (.js
):
on:
pull_request_target:
paths:
- '**.js'
Nota: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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
When a pull request merges, the pull request is automatically closed. 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. For example, the following workflow will run whenever a pull request closes. The if_merged
job will only run if the pull request was also merged.
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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
subir | n/a | Confirmació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, consultala sección "Sintaxis de flujo de trabajo para 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: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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'
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, consultala sección "Sintaxis de flujo de trabajo para 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. For more information, see "Workflow syntax for 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: Si utilizas tanto el filtro de branches
como el de paths
, el flujo de trabajo solo se ejecutará cuando ambos se satisfagan. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
registry_package | - published - updated | Confirmación del paquete publicado | Rama 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
lanzamiento | - published - unpublished - created - edited - deleted - prereleased - released | Última confirmación en el lanzamiento etiquetado | Ref 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". Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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 un flujo de trabajo se ejecute cuando se publiquen los lanzamientos estables y los prelanzamientos, 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 está como published
.
on:
release:
types: [published]
repository_dispatch
Carga del evento Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
repository_dispatch | Personalizado | Última confirmación en la rama predeterminada | Rama 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
n/a | n/a | Última confirmación en la rama predeterminada | Rama 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 utilizar estos operadores en cualquiera de los cinco campos:
Operador | Descripción | Ejemplo |
---|---|---|
* | Cualquier valor | 15 * * * * se ejecuta a cada minuto 15 de cada hora de cada día. |
, | Separador de la lista de valores | 2,10 4,5 * * * se ejecuta en el minuto 2 y 10 de la cuarta y quinta hora de cada día. |
- | Rango de valores | 30 4-6 * * * se ejecuta en el minuto 30 de la 4ta, 5ta y 6ta hora. |
/ | Valores del paso | 20/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 no estándar de @yearly
, @monthly
, @weekly
, @daily
, @hourly
y @reboot
.
Puedes utilizar contrab guru para generar tu sintaxis de cron y confirmar a qué hora se ejecutará. To help you get started, there is also a list of crontab guru examples.
Notifications for scheduled workflows are sent to the user who last modified the cron syntax in the workflow file. For more information, see "Notifications for workflow runs."
estado
Carga del evento Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
estado | n/a | Última confirmación en la rama predeterminada | n/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.
Runs your workflow when the status of a Git commit changes. For example, commits can be marked as error
, failure
, pending
, or success
. If you want to provide more details about the status change, you may want to use the check_run
event. For information about the commit status APIs, see "Status" in the GraphQL API documentation or "Statuses" in the REST API documentation.
For example, you can run a workflow when the status
event occurs.
on:
status
If you want to run a job in your workflow based on the new commit state, you can use the github.event.state
context. For example, the following workflow triggers when a commit status changes, but the if_error_or_failure
job only runs if the new commit state is error
or 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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
observar | - started | Última confirmación en la rama predeterminada | Rama predeterminada |
Note: Más de un tipo de actividad desencadena este evento. Although only the started
activity type is supported, specifying the activity type will keep your workflow specific if more activity types are added in the future. For information about each activity type, see "Webhook events and payloads." Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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.
Runs your workflow when the workflow's repository is starred. For information about the pull request APIs, see "addStar" in the GraphQL API documentation or "Starring" in the REST API documentation.
For example, you can run a workflow when someone stars a repository, which is the started
activity type for a watch event.
on:
watch:
types: [started]
workflow_dispatch
Carga del evento Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_dispatch | n/a | Última confirmacion en la rama de GITHUB_REF | Rama que recibió el envío |
To manually trigger a workflow, use the workflow_dispatch
event. You can manually trigger a workflow run using the GitHub Enterprise Server API, CLI de GitHub, or GitHub Enterprise Server browser interface. For more information, see "Manually running a workflow."
on: workflow_dispatch
Proporcionar entradas
You can configure custom-defined input properties, default input values, and required inputs for the event directly in your workflow. When you trigger the event, you can provide the ref
and any inputs
. When the workflow runs, you can access the input values in the github.event.inputs
context. Para obtener más información, consulta "Contextos".
This example defines the name
and home
inputs and prints them using the github.event.inputs.name
and github.event.inputs.home
contexts. If a home
isn't provided, the default value 'The Octoverse' is printed.
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 Webhook | Tipos de actividad | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_run | - completed - requested | Última confirmación en la rama predeterminada | Rama predeterminada |
Note: Más de un tipo de actividad desencadena este evento. The requested
activity type does not occur when a workflow is re-run. For information about each activity type, see "Webhook events and payloads." Predeterminadamente, todos los tipos de actividad activan flujos de trabajo que pueden ejecutarse en este evento. 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.
Note: You can't use workflow_run
to chain together more than three levels of workflows. For example, if you attempt to trigger five workflows (named B
to F
) to run sequentially after an initial workflow A
has run (that is: A
→ B
→ C
→ D
→ E
→ F
), workflows E
and F
will not be run.
This event occurs when a workflow run is requested or completed. It allows you to execute a workflow based on execution or completion of another workflow. The workflow started by the workflow_run
event is able to access secrets and write tokens, even if the previous workflow was not. This is useful in cases where the previous workflow is intentionally not privileged, but you need to take a privileged action in a later workflow.
In this example, a workflow is configured to run after the separate "Run Tests" workflow completes.
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
If you specify multiple workflows
for the workflow_run
event, only one of the workflows needs to run. For example, a workflow with the following trigger will run whenever the "Staging" workflow or the "Lab" workflow completes.
on:
workflow_run:
workflows: [Staging, Lab]
types:
- completed
Ejecutar un flujo de trabajo con base en la conclusión de otro flujo de trabjo
A workflow run is triggered regardless of the conclusion of the previous workflow. If you want to run a job or step based on the result of the triggering workflow, you can use a conditional with the github.event.workflow_run.conclusion
property. For example, this workflow will run whenever a workflow named "Build" completes, but the on-success
job will only run if the "Build" workflow succeeded, and the on-failure
job will only run if the "Build" workflow failed:
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
You can use the branches
or branches-ignore
filter to specify what branches the triggering workflow must run on in order to trigger your workflow. For more information, see "Workflow syntax for GitHub Actions." For example, a workflow with the following trigger will only run when the workflow named Build
runs on a branch named canary
.
on:
workflow_run:
workflows: [Build]
types: [requested]
branches: [canary]
Utilizar datos desde el flujo de trabajo llamante
You can access the workflow_run
event payload that corresponds to the workflow that triggered your workflow. For example, if your triggering workflow generates artifacts, a workflow triggered with the workflow_run
event can access these artifacts.
The following workflow uploads data as an artifact. (In this simplified example, the data is the pull request number.)
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/
When a run of the above workflow completes, it triggers a run of the following workflow. The following workflow uses the github.event.workflow_run
context and the GitHub Enterprise Server REST API to download the artifact that was uploaded by the above workflow, unzips the downloaded artifact, and comments on the pull request whose number was uploaded as an artifact.
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!'
});