Acerca de los activadores de los flujos de trabajo
Los activadores de los flujos de trabajo son eventos que ocasionan que se ejecute un flujo de trabajo. Estos eventos pueden ser:
- Eventos que ocurren en el repositorio de tu flujo de trabajo
- Eventos que se producen fuera de GitHub AE y desencadenan un evento
repository_dispatch
en GitHub AE - Tiempos programados
- Manual
Por ejemplo, puedes configurar tu flujo de trabajo para que se ejecute cuando se realiza una subida a la rama predeterminada de tu repositorio, cuando se crea un lanzamiento o cuando se abre una propuesta.
Los desencadenadores de flujos de trabajo se definen con la clave on
. Para obtener más información, vea «Sintaxis del flujo de trabajo para Acciones de GitHub».
Los siguientes pasos se producen para activar una ejecución de flujo de trabajo:
-
Un eventto ocurre en tu repositorio. El evento tiene un SHA de confirmación asociado y una ref de Git.
-
GitHub AE busca en el directorio
.github/workflows
del repositorio los archivos de flujo de trabajo que están presentes en el SHA de confirmación asociado o en la referencia de Git del evento. -
Se desencadena una ejecución de flujos de trabajo para cualquier flujo de trabajo que tenga valores
on:
que coincidan con el evento desencadenador. Algunos eventos también requieren que el flujo de trabajo esté presente en la rama predeterminada del repositorio para poder ejecutarse.Cada ejecución de flujo de trabajo utiliza la versión de este que esté presente en el SHA de confirmación asociado o Git Ref del evento. Cuando se ejecuta un flujo de trabajo, GitHub AE establece las variables de entorno
GITHUB_SHA
(SHA de confirmación) yGITHUB_REF
(referencia de Git) en el entorno del ejecutor. Para obtener más información, vea «variables».
Activar un flujo de trabajo desde otro
Al usar GITHUB_TOKEN
del repositorio para realizar tareas, los eventos desencadenados por GITHUB_TOKEN
no crearán una nueva ejecución de flujo de trabajo. Esto impide que crees ejecuciones de flujo de trabajo recursivas por accidente. Por ejemplo, si una ejecución de flujo de trabajo inserta código mediante GITHUB_TOKEN
del repositorio, un nuevo flujo de trabajo no se ejecutará incluso cuando el repositorio contenga un flujo de trabajo configurado para ejecutarse cuando se produzcan eventos push
. Para obtener más información, vea "Autenticación automática de tokens".
Si quieres desencadenar un flujo de trabajo desde una ejecución de flujos de trabajo, puedes usar un token de acceso de instalación a GitHub App o un personal access token en lugar de GITHUB_TOKEN
para desencadenar eventos que requieran un token.
Si utilizas una GitHub App, tendrás que crear una GitHub App y almacenar el identificador de la aplicación y la clave privada como secretos. Para obtener más información, vea «Making authenticated API requests with a GitHub App in a GitHub Actions workflow». Si utilizas un personal access token, tendrás que crear un personal access token y almacenarlo como secreto. Para obtener más información sobre la creación de un personal access token, consulte "Managing your personal access tokens". Para obtener más información sobre cómo almacenar secretos, consulta "Secretos cifrados".
Para minimizar tus costos de uso de GitHub Actions, asegúrate de no crear ejecuciones de flujo de trabajo recurrentes o involuntarias.
Por ejemplo, el siguiente flujo de trabajo usa un personal access token (almacenado como un secreto denominado MY_TOKEN
) para agregar una etiqueta a una incidencia mediante GitHub CLI. Cualquier flujo de trabajo que se ejecute cuando una etiqueta se agrega se ejecutará una vez mediante este espejo.
on:
issues:
types:
- opened
jobs:
label_issue:
runs-on: ubuntu-latest
steps:
- env:
GITHUB_TOKEN: ${{ secrets.MY_TOKEN }}
ISSUE_URL: ${{ github.event.issue.html_url }}
run: |
gh issue edit $ISSUE_URL --add-label "triage"
Por su parte, el siguiente flujo de trabajo usa GITHUB_TOKEN
para agregar una etiqueta a una incidencia. No activará ningún flujo de trabajo que se ejecute cuando se agregue una etiqueta.
on:
issues:
types:
- opened
jobs:
label_issue:
runs-on: ubuntu-latest
steps:
- env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ISSUE_URL: ${{ github.event.issue.html_url }}
run: |
gh issue edit $ISSUE_URL --add-label "triage"
Utilizar eventos para activar flujos de trabajo
Use la clave on
para especificar qué eventos desencadenan el flujo de trabajo. Para obtener más información sobre los eventos que puede usar, vea "Eventos que desencadenan flujos de trabajo".
Utilizar un evento simple
Por ejemplo, un flujo de trabajo con el siguiente valor de on
se ejecutará cuando se realice una subida a cualquier rama en el repositorio del flujo de trabajo:
on: push
Utilizar eventos múltiples
Puedes especificar eventos sencillos o múltiples. Por ejemplo, un flujo de trabajo con el siguiente valor de on
se ejecutará cuando se realice una inserción en cualquier rama del repositorio o cuando alguien lo bifurque:
on: [push, fork]
Si especificas eventos múltiples, únicamente uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren eventos múltiples de activación para tu flujo de trabajo al mismo tiempo, se activarán las ejecuciones de flujo de trabajo múltiples.
Utilizar los tipos de actividad y filtros con eventos múltiples
Puedes utilizar tipos de actividad y filtros para controlar aún más cuándo se ejecutará tu flujo de trabajo. Para obtener más información, vea Uso de tipos de actividad de eventos y Uso de filtros. Si especificas los tipos de actividad o filtros para un evento y tu flujo de trabajo activa eventos múltiples, deberás configurar cada uno de ellos por separado. Debe agregar dos puntos (:
) a todos los eventos, incluidos aquellos sin configuración.
Por ejemplo, un flujo de trabajo con el valor on
siguiente se ejecutará cuando:
- Se crea una etiqueta
- Se hace una inserción a la rama
main
en el repositorio. - Se hace una subida a la rama habilitada por GitHub Pages
on:
label:
types:
- created
push:
branches:
- main
page_build:
Utilizar tipos de actividad de eventos
Algunos eventos tienen tipos de actividad que te proporcionan más control sobre cuándo debería ejecutarse tu flujo de trabajo. Use on.<event_name>.types
para definir el tipo de actividad de evento que desencadenará una ejecución de flujo de trabajo.
Por ejemplo, el evento issue_comment
tiene los tipos de actividad created
, edited
y deleted
. Si el flujo de trabajo desencadena el evento label
, se ejecutará cada vez que se cree, edite o elimine una etiqueta. Si especifica el tipo de actividad created
para el evento label
, el flujo de trabajo se ejecutará cuando se cree una etiqueta pero no cuando se edite o elimine.
on:
label:
types:
- created
Si especificas tipos de actividad múltiples, solo uno de ellos necesitará ocurrir para que se active tu flujo de trabajo. Si ocurren tipos de actividad de eventos activadores múltiples al mismo tiempo para tu flujo de trabajo, se activarán ejecuciones de flujo de trabajo múltiples. Por ejemplo, el siguiente flujo de trabajo se activa cuando se abre o etiqueta una propuesta. Si se abre una propuesta con dos etiquetas, iniciarán tres ejecuciones de flujo de trabajo: una para el evento de la propuesta abierta y dos para los eventos etiquetados de las dos propuestas.
on:
issues:
types:
- opened
- labeled
Para más información sobre cada evento y sus tipos de actividad, consulta "Eventos que desencadenan flujos de trabajo".
Utilizar filtros
Algunos eventos tienen filtros que te dan más control sobre qué flujo de trabajo debería ejecutarse.
Por ejemplo, el evento push
tiene un filtro branches
que hace que el flujo de trabajo solo se ejecute cuando se realice una inserción en una rama que coincida con el filtro branches
, en lugar de cuando se produzca cualquier inserción.
on:
push:
branches:
- main
- 'releases/**'
Utilizar filtros para apuntar a ramas específicas para los eventos de solicitudes de cambios
Al usar los eventos pull_request
y pull_request_target
, puede configurar un flujo de trabajo a fin de que solo se ejecute para las solicitudes de incorporación de cambios destinadas a ramas específicas.
Use el filtro branches
cuando quiera incluir patrones de nombre de rama, o bien cuando quiera incluirlos y excluirlos. Use el filtro branches-ignore
cuando solo quiera excluir patrones de nombre de rama. No puede usar los filtros branches
y branches-ignore
para el mismo evento de un flujo de trabajo.
Si define branches
/branches-ignore
y paths
, el flujo de trabajo solo se ejecutará cuando se cumplan los dos filtros.
Las palabras clave branches
y branches-ignore
aceptan patrones globales que usan caracteres como *
, **
, +
, ?
y !
, entre otros, para que coincidan con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita escapar a cada uno de estos caracteres especiales con \
. Para más información sobre los patrones globales, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".
Ejemplo: Incluir ramas
Los patrones definidos en branches
se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que exista un evento pull_request
para una solicitud de incorporación de cambios destinada a:
- Una rama denominada
main
(refs/heads/main
) - Una rama denominada
mona/octocat
(refs/heads/mona/octocat
) - Una rama cuyo nombre comienza por
releases/
, comoreleases/10
(refs/heads/releases/10
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
Ejemplo: Excluir ramas
Cuando un patrón coincide con el patrón branches-ignore
, el flujo de trabajo no se ejecutará. Los patrones definidos en branches
se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que haya un evento de pull_request
a menos de que la solicitud de incorporación de cambios esté destinada a:
- Una rama denominada
mona/octocat
(refs/heads/mona/octocat
) - Una rama cuyo nombre coincide con
releases/**-alpha
, comoreleases/beta/3-alpha
(refs/heads/releases/beta/3-alpha
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
Ejemplo: Incluir y excluir ramas
No puede usar branches
y branches-ignore
para filtrar el mismo evento en un único flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama para un solo evento, utilice el filtro branches
junto con el carácter !
para indicar qué ramas deberían excluirse.
Si define una rama con el carácter !
, también tendrá que definir al menos otra sin el carácter !
. Si solo quiere excluir ramas, use branches-ignore
en su lugar.
El orden en que defines los patrones importa.
- Un patrón negativo coincidente (con el prefijo
!
) después de una coincidencia positiva hará que se excluya la referencia de Git. - Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.
El flujo de trabajo siguiente se ejecutará en eventos pull_request
para las solicitudes de incorporación de cambios que tienen como destino releases/10
o releases/beta/mona
, pero no para las que tienen como destino releases/10-alpha
o releases/beta/3-alpha
porque el patrón negativo !releases/**-alpha
sigue el patrón positivo.
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
Utilizar filtros para apuntar a ramas o etiquetas específicas para los eventos de subida
Al usar el evento push
, puede configurar un flujo de trabajo para que se ejecute en ramas o etiquetas específicas.
Use el filtro branches
cuando quiera incluir patrones de nombre de rama, o bien cuando quiera incluirlos y excluirlos. Use el filtro branches-ignore
cuando solo quiera excluir patrones de nombre de rama. No puede usar los filtros branches
y branches-ignore
para el mismo evento de un flujo de trabajo.
Use el filtro tags
cuando quiera incluir los patrones de nombre de etiqueta, o bien cuando quiera incluirlos y excluirlos. Use el filtro tags-ignore
cuando solo quiera excluir patrones de nombre de etiqueta. No puede usar los filtros tags
y tags-ignore
para el mismo evento de un flujo de trabajo.
Si solo define tags
/tags-ignore
o branches
/branches-ignore
, el flujo de trabajo no se ejecutará para eventos que afecten a la referencia de Git no definida. Si no define tags
/tags-ignore
ni branches
/branches-ignore
, el flujo de trabajo se ejecutará para eventos que afecten a ramas o etiquetas. Si defines branches
/branches-ignore
y paths
/paths-ignore
, el flujo de trabajo solo se ejecutará cuando se cumplan ambos filtros.
Las palabras clave branches
, branches-ignore
, tags
y tags-ignore
aceptan patrones globales que usan caracteres como *
, **
, +
, ?
, !
y otros para que coincidan con más de un nombre de rama o etiqueta. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita escapar a cada uno de estos caracteres especiales con \
. Para más información sobre los patrones globales, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".
Ejemplo: Incluyendo ramas y etiquetas
Los patrones definidos en branches
y tags
se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que hubiera un evento push
para:
- Una rama denominada
main
(refs/heads/main
) - Una rama denominada
mona/octocat
(refs/heads/mona/octocat
) - Una rama cuyo nombre comienza por
releases/
, comoreleases/10
(refs/heads/releases/10
) - Una etiqueta denominada
v2
(refs/tags/v2
) - Una etiqueta cuyo nombre comienza por
v1.
, comov1.9.1
(refs/tags/v1.9.1
)
on:
push:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v2
- v1.*
Ejemplo: Excluir ramas y etiquetas
Cuando un patrón coincide con el patrón branches-ignore
o tags-ignore
, el flujo de trabajo no se ejecutará. Los patrones definidos en branches
y tags
se evalúan con el nombre de referencia de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutará siempre que haya un evento push
, a menos que el evento push
sea para:
- Una rama denominada
mona/octocat
(refs/heads/mona/octocat
) - Una rama cuyo nombre coincide con
releases/**-alpha
, comobeta/3-alpha
(refs/releases/beta/3-alpha
) - Una etiqueta denominada
v2
(refs/tags/v2
) - Una etiqueta cuyo nombre comienza por
v1.
, comov1.9
(refs/tags/v1.9
)
on:
push:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
# Sequence of patterns matched against refs/tags
tags-ignore:
- v2
- v1.*
Ejemplo: incluir y excluir ramas y etiquetas
No puede usar branches
y branches-ignore
para filtrar el mismo evento en un único flujo de trabajo. Del mismo modo, no puede usar tags
y tags-ignore
para filtrar el mismo evento en un único flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama o etiqueta para un solo evento, use el filtro branches
o tags
junto con el carácter !
para indicar qué ramas o etiquetas se deberían excluir.
Si define una rama con el carácter !
, también tendrá que definir al menos otra sin el carácter !
. Si solo quiere excluir ramas, use branches-ignore
en su lugar. Del mismo modo, si define una etiqueta con el carácter !
, también tendrá que definir al menos otra sin el carácter !
. Si solo quiere excluir etiquetas, use tags-ignore
en su lugar.
El orden en que defines los patrones importa.
- Un patrón negativo coincidente (con el prefijo
!
) después de una coincidencia positiva hará que se excluya la referencia de Git. - Un patrón positivo de coincidencia luego de una coincidencia negativa volverá a incluir la ref de Git.
El siguiente flujo de trabajo se ejecutará en inserciones en releases/10
o releases/beta/mona
, pero no en releases/10-alpha
o releases/beta/3-alpha
, porque el patrón !releases/**-alpha
negativo sigue el patrón positivo.
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
Utilizar filtros para apuntar a rutas específicas para los eventos de subida o solicitudes de cambios
Al usar los eventos push
y pull_request
, puedes configurar un flujo de trabajo para su ejecución en función de las rutas de acceso de archivo que se cambien. Los filtros de ruta no se evalúan para subidas de etiquetas.
Usa el filtro paths
cuando quieras incluir patrones de ruta de acceso de archivos o cuando quieras tanto incluirlos como excluirlos. Usa el filtro paths-ignore
cuando solo quieras excluir patrones de ruta de acceso de archivos. No puede usar los filtros paths
y paths-ignore
para el mismo evento de un flujo de trabajo.
Si define branches
/branches-ignore
y paths
/paths-ignore
, el flujo de trabajo solo se ejecutará cuando se cumplan los dos filtros.
Las palabras clave paths
y paths-ignore
aceptan patrones globales que usan los caracteres comodín *
y **
para coincidir con más de un nombre de ruta de acceso. Para obtener más información, consulta el "Sintaxis del flujo de trabajo para Acciones de GitHub".
Ejemplo: Incluyendo rutas
Si al menos una ruta de acceso coincide con un patrón en el filtro paths
, se ejecuta el flujo de trabajo. Por ejemplo, el flujo de trabajo siguiente se ejecutaría cada vez que envíes cambios de un archivo JavaScript (.js
).
on:
push:
paths:
- '**.js'
Nota: Si se omite un flujo de trabajo debido a un filtrado de ruta, filtrado de rama o mensaje de confirmación, las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado "Pendiente". Se bloqueará la fusión mediante combinación de una solicitud de incorporación de cambios que requiera esas comprobaciones para realizarse correctamente. Para obtener más información, vea «Solución de problemas para verificaciones de estado requeridas».
Ejemplo: Exclusión de rutas de acceso
Cuando todos los nombres de ruta de acceso coincidan con los patrones de paths-ignore
, el flujo de trabajo no se ejecutará. Si alguno de los nombres de ruta de acceso no coincide con los patrones de paths-ignore
, aunque algunos nombres de ruta coincidan con estos, el flujo de trabajo se ejecutará.
Un flujo de trabajo con el siguiente filtro de ruta de acceso solo se ejecutará en los eventos push
que incluyan al menos un archivo externo al directorio docs
en la raíz del repositorio.
on:
push:
paths-ignore:
- 'docs/**'
Ejemplo: Inclusión y exclusión de rutas de acceso
No puedes usar paths
y paths-ignore
para filtrar el mismo evento en un único flujo de trabajo. Si quieres tanto incluir como excluir patrones de ruta de acceso para un solo evento, usa el filtro paths
junto con el carácter !
para indicar qué rutas de acceso se deben excluir.
Si defines una ruta de acceso con el carácter !
, también debes definir al menos una ruta de acceso sin el carácter !
. Si solo quieres excluir rutas de acceso, usa paths-ignore
en su lugar.
El orden en que defines los patrones importa:
- El tener una coincidencia de patrón negativo (con el prefijo
!
) después de una coincidencia positiva hará que se excluya la ruta de acceso. - Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta.
Este ejemplo se ejecuta cada vez que el evento push
incluye un archivo en el directorio sub-project
o sus subdirectorios, a menos que el archivo esté en el directorio sub-project/docs
. Por ejemplo, una inserción que haya cambiado sub-project/index.js
o sub-project/src/index.js
desencadenará una ejecución de flujo de trabajo, pero una inserción que solo cambie sub-project/docs/readme.md
no lo hará.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Comparaciones de diferencias de Git
Nota: Si insertas más de 1000 confirmaciones o si GitHub no genera las diferencias debido a que se agota el tiempo de espera, el flujo de trabajo siempre se ejecutará.
El filtro determina si un flujo de trabajo debe ejecutarse al evaluar los archivos modificados y ejecutarlos en comparación con la lista de paths-ignore
o paths
. Si no hay archivos modificados, no se ejecutará el flujo de trabajo.
GitHub genera la lista de archivos modificados usando diferencias de dos puntos para las subidas y de tres puntos para las solicitudes de extracción:
- Solicitudes de incorporación de cambios: las diferencias de tres puntos son una comparación entre la versión más reciente de la rama de tema y la confirmación en la que la rama de tema se sincronizó por última vez con la rama base.
- Inserción en ramas existentes: una diferencia de dos puntos compara los SHA base y principal directamente entre sí.
- Inserción en ramas nuevas: una diferencia de dos puntos comparada con el elemento primario del antecesor de la confirmación insertada más profunda.
Los diffs se limitan a 300 archivos. Si hay archivos que cambiaron y no se empataron en los primeros 300 archivos que devuelve el filtro, el flujo de trabajo no se ejecutará. Puede que necesites crear filtros más específicos para que el flujo de trabajo se ejecute automáticamente.
Para obtener más información, vea «Acerca de comparar ramas en solicitudes de extracción».
Utilizar filtros para apuntar a ramas específicas para los eventos de ejecución de flujos de trabajo
Cuando utilice el evento workflow_run
, puede especificar qué ramas debe ejecutar el flujo de trabajo activador para que se active tu flujo.
Los filtros branches
y branches-ignore
aceptan patrones globales que usan caracteres como *
, **
, +
, ?
y !
, entre otros, para que coincidan con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quiere una coincidencia literal, necesita escapar a cada uno de estos caracteres especiales con \
. Para más información sobre los patrones globales, consulta "Sintaxis del flujo de trabajo para Acciones de GitHub".
Por ejemplo, un flujo de trabajo con el siguiente activador solo se ejecutará cuando el flujo de trabajo Build
se ejecute en una rama cuyo nombre empiece por releases/
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
Un flujo de trabajo con el siguiente activador solo se ejecutará cuando el flujo de trabajo Build
se ejecute en una rama cuyo nombre empiece por canary
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches-ignore:
- "canary"
No puede usar los filtros branches
y branches-ignore
para el mismo evento de un flujo de trabajo. Si quiere tanto incluir como excluir patrones de rama para un solo evento, utilice el filtro branches
junto con el carácter !
para indicar qué ramas deberían excluirse.
El orden en que defines los patrones importa.
- El tener una coincidencia de patrón negativo (con prefijo
!
) después de una coincidencia positiva hará que se excluya la rama. - El tener un patrón de coincidencia positivo después de una coincidencia negativa hará que se incluya la rama nuevamente.
Por ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cuando el flujo de trabajo Build
se ejecute en una cuyo nombre sea releases/10
o releases/beta/mona
, pero no releases/10-alpha
, releases/beta/3-alpha
ni main
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
- '!releases/**-alpha'
Definir entradas para los flujos de trabajo que se activan manualmente
Cuando se usa el evento workflow_dispatch
, puede especificar opcionalmente entradas que se pasan al flujo de trabajo. El flujo de trabajo desencadenado recibe las entradas en el contexto inputs
. Para más información, vea "Contextos".
Nota: El flujo de trabajo también recibirá las entradas en el contexto github.event.inputs
. La información de los contextos inputs
y github.event.inputs
son idénticos, salvo que el contexto inputs
conserva los valores booleanos como tales en lugar de convertirlos en cadenas.
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
print_tags:
description: 'True to print to STDOUT'
required: true
type: boolean
tags:
description: 'Test scenario tags'
required: true
type: string
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
print-tag:
runs-on: ubuntu-latest
if: ${{ inputs.print_tags }}
steps:
- name: Print the input tag to STDOUT
run: echo The tags are ${{ inputs.tags }}
``` ```yaml
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
print_tags:
description: 'True to print to STDOUT'
required: true
type: boolean
tags:
description: 'Test scenario tags'
required: true
type: string
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
print-tag:
runs-on: ubuntu-latest
if: ${{ inputs.print_tags }}
steps:
- name: Print the input tag to STDOUT
run: echo The tags are ${{ inputs.tags }}
Definir entradas, salidas y secretos para los flujos de trabajo reutilizables
Puedes definir entradas y secretos que deben recibir los flujos de trabajo reutilizables desde un flujo de trabajo llamante. También puedes especificar las salidas que un flujo de trabajo reutilizable pondrá a disposición de un flujo de trabajo llamante. Para obtener más información, vea «Reutilización de flujos de trabajo».
Utilizar la información de los eventos
La información sobre el evento que ha desencadenado una ejecución de flujo de trabajo está disponible en el contexto github.event
. Las propiedades del contexto github.event
dependen del tipo de evento que ha desencadenado el flujo de trabajo. Por ejemplo, un flujo de trabajo que se activa cuando se etiqueta una propuesta tendrá la información sobre la propuesta y etiqueta.
Ver todas las propiedades de un evento
Referencia la documentación de evento de webhook para las propiedades comunes y cargas útiles de ejemplo. Para obtener más información, vea «Eventos y cargas de webhook».
También puede imprimir todo el contexto github.event
para ver qué propiedades están disponibles para el evento que ha desencadenado el flujo de trabajo:
jobs:
print_context:
runs-on: ubuntu-latest
steps:
- env:
EVENT_CONTEXT: ${{ toJSON(github.event) }}
run: |
echo $EVENT_CONTEXT
Acceder y utilizar las propiedades de evento
Puede usar el contexto github.event
en el flujo de trabajo. Por ejemplo, el siguiente flujo de trabajo se ejecuta cuando se abre una solicitud de incorporación de cambios que cambia package*.json
, .github/CODEOWNERS
o .github/workflows/**
. Si el creador de la solicitud de incorporación de cambios (github.event.pull_request.user.login
) no es octobot
ni dependabot[bot]
, el flujo de trabajo usa GitHub CLI para etiquetar y comentar la solicitud de incorporación de cambios (github.event.pull_request.number
).
on:
pull_request:
types:
- opened
paths:
- '.github/workflows/**'
- '.github/CODEOWNERS'
- 'package*.json'
jobs:
triage:
if: >-
github.event.pull_request.user.login != 'octobot' &&
github.event.pull_request.user.login != 'dependabot[bot]'
runs-on: ubuntu-latest
steps:
- name: "Comment about changes we can't accept"
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR: ${{ github.event.pull_request.html_url }}
run: |
gh pr edit $PR --add-label 'invalid'
gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'
Para obtener más información sobre los contextos, consulta "Contextos". Para obtener más información sobre las cargas útiles de los eventos, consulte "Eventos y cargas de webhook".
Controlar aún más la forma en la que se ejecutará tu flujo de trabajo
Si quieres un control más pormenorizado que el que proporcionan los eventos, los tipos de actividad de eventos o los filtros de eventos, puedes utilizar condicionales y entornos para controlar si se ejecutarán trabajos o pasos individuales en el flujo de trabajo.
Utilziar condicionales
Puedes utilizar condicionales para controlar aún más si se ejecutarán los jobs o pasos de tu flujo de trabajo.
Ejemplo utilizando un valor en la carga útil del evento
Por ejemplo, si quiere que el flujo de trabajo se ejecute cuando se agregue una etiqueta específica a una incidencia, puede desencadenar el tipo de actividad de evento issues labeled
y usar un condicional para comprobar qué etiqueta ha desencadenado el flujo de trabajo. El siguiente flujo de trabajo se ejecutará cuando se agregue cualquier etiqueta a una incidencia en el repositorio del flujo de trabajo, pero el trabajo run_if_label_matches
solo se ejecutará si la etiqueta se denomina bug
.
on:
issues:
types:
- labeled
jobs:
run_if_label_matches:
if: github.event.label.name == 'bug'
runs-on: ubuntu-latest
steps:
- run: echo 'The label was bug'
Ejemplo utilizando un tipo de evento
Por ejemplo, si quieres ejecutar jobs o pasos diferentes dependiendo de qué evento activó el flujo de trabajo, puedes utilizar una condicional para verificar si un tipo de evento específico existe en el contexto del mismo. El siguiente flujo de trabajo se ejecutará cada que se cierre una propuesta o solicitud de cambios. Si el flujo de trabajo se ha ejecutado porque se ha cerrado una incidencia, el contexto github.event
contendrá un valor para issue
, pero no para pull_request
. Por lo tanto, el paso if_issue
se ejecutará, pero el paso if_pr
no. Por el contrario, si el flujo de trabajo se ha ejecutado porque se ha cerrado una solicitud de incorporación de cambios, el paso if_pr
se ejecutará, pero el paso if_issue
no.
on:
issues:
types:
- closed
pull_request:
types:
- closed
jobs:
state_event_type:
runs-on: ubuntu-latest
steps:
- name: if_issue
if: github.event.issue
run: |
echo An issue was closed
- name: if_pr
if: github.event.pull_request
run: |
echo A pull request was closed
Para obtener más información sobre qué información está disponible en el contexto del evento, vea "Uso de información de eventos". Para obtener más información sobre cómo usar condicionales, vea "Expresiones".
Utilizar ambientes para activar jobs de flujos de trabajo manualmente
Si quieres activar manualmente un job específico en un flujo de trabajo, puedes utilizar un ambiente que requiera aprobación de un equipo o usuario específico. Primero, configura un ambiente con revisores requeridos. Para obtener más información, vea «Utilizar ambientes para el despliegue». Después, haga referencia al nombre del entorno en un trabajo del flujo de trabajo mediante la clave environment:
. No se ejecutará ningún job que referencie el ambiente hasta que por lo menos un revisor lo apruebe.
Por ejemplo, el siguiente fluljo de trabajo se ejecutará siempre que haya una subida a la rama principal (main). El trabajo build
siempre se ejecutará. El trabajo publish
solo se ejecutará después de que el trabajo build
se complete correctamente (debido a needs: [build]
) y después de que se pasen todas las reglas (incluidos los revisores necesarios) para el entorno denominado production
(debido a environment: production
).
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: build
echo 'building'
publish:
needs: [build]
runs-on: ubuntu-latest
environment: production
steps:
- name: publish
echo 'publishing'
Los entornos, las reglas de protección de entorno y los secretos de entorno se encuentran disponibles en los repositorios públicos para todos los productos. Para acceder a entornos, secretos de entorno y ramas de implementación de repositorios privados o internos, debe usar GitHub Pro, GitHub Team, o GitHub Enterprise. Para acceder a otras reglas de protección de entornos en los repositorios privados o internos, debe utilizar GitHub Enterprise.
Eventos disponibles
Para ver la lista completa de eventos disponibles, consulte "Eventos que desencadenan flujos de trabajo".