Triggering a workflow

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 ocurren fuera de GitHub Enterprise Server y activan un evento de repository_dispatch en GitHub Enterprise Server
• 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 activadores de los flujos de trabajo se definen con la clave on. Para obtener más información, consulta la sección "Sintaxis del flujo de trabajo para las GitHub Actions".

Los siguientes pasos se producen para activar una ejecución de flujo de trabajo:

1. Un eventto ocurre en tu repositorio. El evento tiene un SHA de confirmación asociado y una ref de Git.

2. GitHub Enterprise Server busca el directorio .github/workflows en tu repositorio para el caso de los archivos de flujo de trabajo que están presentes en el SHA de confirmación asociado o Git Ref del evento.

3. Un flujo de trabajo se activará para cualquier flujo de trabajo que tenga valores de on: que empaten con el evento que s eactivó. 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 Enterprise Server establece las variables de entorno GITHUB_SHA (confirmar SHA) y GITHUB_REF (referencia de Git) en el entorno del ejecutor. Para obtener más información, consulta "Usar variables de entorno".

Activar un flujo de trabajo desde otro

Cuando utilizas el repositorio GITHUB_TOKEN para realizar tareas, los eventos que activa el GITHUB_TOKEN no crearán una ejecución de flujo de trabajo nueva. Esto impide que crees ejecuciones de flujo de trabajo recursivas por accidente. Por ejemplo, si un flujo de trabajo sube código utilizando el GITHUB_TOKEN del repositorio, no se ejecutará un nuevo flujo de trabajo aún si el repositorio contiene alguno configurado para ejecutarse cuando ocurran eventos de subida de información. Para obtener más información, consulta "Autenticar con el GITHUB_TOKEN".

Si no quieres activar un flujo de trabajo dentro una ejecución de flujo de trabajo, puedes utilizar un token de acceso personal en vez de un GITHUB_TOKEN para activar los eventos que requieren tu token. Necesitaras crear un token de acceso personal y almacenarlo como un secreto. Para minimizar tus costos de uso de GitHub Actions, asegúrate de no crear ejecuciones de flujo de trabajo recurrentes o involuntarias. Para obtener más información acerca de cómo crear un token de acceso personal, consulta la sección "Crear un token de acceso personal". Para obtener más información sobre cómo almacenr un token de acceso personal como secreto, consulta la sección "Crear y almacenar secretos cifrados".

Por ejemplo, el siguiente flujo de trabajo utiliza un token de acceso personal (almacenado como secreto y llamado MY_TOKEN) para agregar una etiqueta a una propuesta de cambios a través del cli.CLI de GitHub. 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 el contrario, el siguiente flujo de trabajo utiliza un GITHUB_TOKEN para agregar una etiqueta a una propuesta. 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

Utiliza la clave on para especificar qué eventos activan tu flujo de trabajo. For more information about events you can use, see "Events that trigger workflows."

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 haga una subida a 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

You can use activity types and filters to further control when your workflow will run. For more information, see Using event activity types and Using filters. 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. Debes agregar dos puntos (:) a todos los eventos, incluyendo aquellos sin configuración.

Por ejemplo, un flujo de trabajo con el siguiente valor on se ejecutará cuando:

• Se crea una etiqueta
• Se hace una subida a la rama main en el repositorio
• Se hace una subida a la rama habilitada por Páginas de GitHub

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

Using event activity types

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 to define the type of event activity that will trigger a workflow run.

Por ejemplo, el evento issue_comment tiene los tipos de actividad created, edited y deleted. Si tu flujo de trabajo activa el evento label, este se ejecutará cada que se cree, edite o borre una etiqueta. Si especificas el tipo de actividad created para el evento label, tu flujo de trabajo se ejecutará cuando se cree una etiqueta pero no cuando esta se borre o edite.

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:
  issue:
    types:
      - opened
      - labeled

Para obtener más información acerca de 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 ocasiona que tu flujo de trabajo se ejecute únicamente cuando ocurra una subida a una rama que empate con el filtro branches, en vez de cuando ocurra una subida.

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

Using filters to target specific branches for pull request events

Al usar los eventos pull_request y pull_request_target, puedes configurar un flujo de trabajo para que se ejecute únicamente para las solicitudes de cambio que apuntan a ramas específicas.

Utiliza el filtro branches cuando quieras incluir patrones de nombre de rama o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro branches-ignore cuando solo quieras excluir los patrones de nombre de rama. No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo.

Si defines branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando ambos filtros se hayan satisfecho.

Las palabras clave branches y branches-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quieres una coincidencia literal, necesitas escapar a cada uno de estos caracteres especiales con \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

Ejemplo: Incluir ramas

Los patrones que se definen en branches se evalúan contra el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que exista un evento pull_request para una solicitud de cambios que apunte a:

• Una rama de nombre main (refs/heads/main)
• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre inicie con releases/, tal como releases/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 empata con el de branches-ignore, el flujo de trabajo no se ejecutará. Los patrones que se definen en branches se evalúan contra el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que haya un evento de pull_request a menos de que la solicitud de cambios apunte a:

• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre empate con releases/**-alpha, tal como beta/3-alpha (refs/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 puedes utilizar branches y branches-ignore para filtrar el mismo evento en un mismo flujo de trabajo. Si quieres tanto incluir como excluir patrones de rama para un solo evento, utiliza el filtro branches junto con el carácter ! para indicar qué ramas deberían excluirse.

Si defines una rama con el carácter !, también debes definir por lo mismo una rama sin el carácter !. Si solo quieres excluir ramas, utiliza branches-ignore en su lugar.

El orden en que defines los patrones importa.

• Un patrón negativo de coincidencia (con prefijo !) luego de una coincidencia positiva excluirá la ref 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 eventos de pull_request para las solicitudes de cambio que apunten a releases/10 o releases/beta/mona, pero para aquellas que empaten con releases/10-alpha o releases/beta/3-alpha, ya que el patrón negativo !releases/**-alpha sigue al patrón positivo.

on:
  pull_request:
    branches:    
      - 'releases/**'
      - '!releases/**-alpha'

Using filters to target specific branches or tags for push events

Cuando utilices el evento push, podrás configurar un flujo de trabajo para que se ejecute en ramas o etiquetas específicas.

Utiliza el filtro branches cuando quieras incluir patrones de nombre de rama o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro branches-ignore cuando solo quieras excluir los patrones de nombre de rama. No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo.

Utiliza el filtro de tags cuando quieras incluir los patrones de nombre de etiqueta o cuando quieras tanto incluirlos como excluirlos. Utiliza el filtro tags-ignore cuando solo quieras excluir los patrones de nombre de etiqueta. No puedes utilizar ambos filtros, tags y tags-ignore, para el mismo evento en un flujo de trabajo.

Si solo defines tags/tag-ignore o solo branches/branches-ignore, el flujo de trabajo no se ejecutará para los eventos que afectan la ref de Git indefinida. Si no defines ni tags/tag-ignore ni branches/branches-ignore, el flujo de trabajo se ejecutará para los eventos que no afecten a ninguna rama o etiqueta. Si defines branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando ambos filtros se hayan satisfecho.

Las palabras clave branches, branches-ignore, tags, y tags-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de una rama o nombre de etiqueta. Si un nombre contiene cualquiera de estos caracteres y quieres tener una coincidencia literal, necesitas escapar cada uno de estos caracteres especiales con una \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

Ejemplo: Incluyendo ramas y etiquetas

Los patrones definidos en branches y tags se evalúan con el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que hubiera un evento de push para:

• Una rama de nombre main (refs/heads/main)
• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre inicie con releases/, tal como releases/10 (refs/heads/releases/10)
• Una etiqueta de nombre v2 (refs/tags/v2)
• Una etiqueta cuyo nombre inicie con v1., tal como v1.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 empata con el de branches-ignore o tags-ignore, no se ejecutará el flujo de trabajo. Los patrones definidos en branches y tags se evalúan con el nombre de ref de Git. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que haya un evento push, a menos de que el evento push sea para:

• Una rama de nombre mona/octocat (refs/heads/mona/octocat)
• Una rama cuyo nombre empate con releases/**-alpha, tal como beta/3-alpha (refs/releases/beta/3-alpha)
• Una etiqueta de nombre v2 (refs/tags/v2)
• Una etiqueta cuyo nombre inicie con v1., tal como v1.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 puedes utilizar branches y branches-ignore para filtrar el mismo evento en un solo flujo de trabajo. De forma similar, no puedes utilizar tags y tags-ignore para filtrar el mismo evento en un solo flujo de trabajo. Si quieres incluir y excluir patrones de etiquetas o ramas para un solo evento, utiliza el filtro branches o tags junto con el carácter ! para indicar qué ramas o etiquetas deberían excluirse.

Si defines una rama con el carácter !, también debes definir por lo mismo una rama sin el carácter !. Si solo quieres excluir ramas, utiliza branches-ignore en su lugar. Del mismo modo, si defines una etiqueta con el carácter !, también debes definir por lo menos una etiqueta sin el carácter !. Si solo quieres excluir las etiquetas, utiliza tags-ignore en su lugar.

El orden en que defines los patrones importa.

• Un patrón negativo de coincidencia (con prefijo !) luego de una coincidencia positiva excluirá la ref 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 las subidas a releases/10 o releases/beta/mona, pero no en releases/10-alpha o releases/beta/3-alpha porque el patrón negativo !releases/**-alpha le sigue al patrón positivo.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Using filters to target specific paths for pull request or push events

Cuando utilices los eventos push y pull_request, puedes configurar un flujo de trabajo para que se ejecute con base en qué rutas de archivo cambiaron. Los filtros de ruta no se evalúan para subidas de etiquetas.

Utiliza el filtro paths cuando quieras incluir los patrones de ruta de archivo o cuando quieras tanto incluirlos como excluirlos. Use the paths-ignore filter when you only want to exclude file path patterns. You cannot use both the paths and paths-ignore filters for the same event in a workflow.

If you define both branches/branches-ignore and paths, the workflow will only run when both filters are satisfied.

The paths and paths-ignore keywords accept glob patterns that use the * and ** wildcard characters to match more than one path name. Para obtener más información, consulta "Hoja de referencia de patrones de filtro".

Ejemplo: Incluyendo rutas

Si al menos una ruta coincide con un patrón del filtro de rutas, se ejecuta el flujo de trabajo. For example, the following workflow would run anytime you push a JavaScript file (.js).

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

Example: Excluding paths

Cuando todos los nombres de ruta coincidan con los patrones en paths-ignore, el flujo de trabajo no se ejecutará. If any path names do not match patterns in paths-ignore, even if some path names match the patterns, the workflow will run.

Un flujo de trabajo con el siguiente filtro de ruta solo se ejecutará en los eventos de subida que incluyan al menos un archivo externo al directorio docs en la raíz del repositorio.

on:
  push:
    paths-ignore:
      - 'docs/**'

Example: Including and excluding paths

You can not use paths and paths-ignore to filter the same event in a single workflow. If you want to both include and exclude path patterns for a single event, use the paths filter along with the ! character to indicate which paths should be excluded.

If you define a path with the ! character, you must also define at least one path without the ! character. If you only want to exclude paths, use paths-ignore instead.

El orden en que defines los patrones importa:

• Una coincidencia de patrón negativo (con prefijo !) luego de una coincidencia positiva excluirá la ruta.
• Un patrón de coincidencia positiva luego de una coincidencia negativa excluirá nuevamente la ruta.

Este ejemplo se ejecuta cada vez que el evento de subida 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 subida que haya cambiado sub-project/index.js o sub-project/src/index.js desencadenará una ejecución de flujo de trabajo, pero una subida que cambie solo sub-project/docs/readme.md no lo hará.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Comparaciones de diferencias de Git

El filtro determina si un flujo de trabajo se debe ejecutar al evaluar los archivos modificados y al ejecutarlos comparándolos 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 extracción: 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, cuando la rama de tema se sincronizó por última vez con la rama base.
• Subidas a ramas existentes: una diferencia de dos puntos compara las SHA de encabezado y de base directamente entre sí.
• Subidas a ramas nuevas: una diferencia de dos puntos comparada con el padre del antepasado de la confirmación más profunda subida.

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, consulta "Acerca de comparar ramas en las solicitudes de extracción".

Using filters to target specific branches for workflow run events

When using the workflow_run event, you can specify what branches the triggering workflow must run on in order to trigger your workflow.

Los filtros de branches y branches-ignore aceptan patrones globales que utilizan caracteres como *, **, +, ?, ! y otros para empatar con más de un nombre de rama. Si un nombre contiene cualquiera de estos caracteres y quieres tener una coincidencia literal, necesitas escapar cada uno de estos caracteres especiales con una \. Para obtener más información sobre los patrones globales, consulta "Hoja de información para filtrar patrones".

For example, a workflow with the following trigger will only run when the workflow named Build runs on a branch whose name starts with releases/:

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

A workflow with the following trigger will only run when the workflow named Build runs on a branch that is not named canary:

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

No puedes utilizar tanto el filtro branches como branches-ignore para el mismo evento en un flujo de trabajo. Si quieres tanto incluir como excluir patrones de rama para un solo evento, utiliza el filtro branches junto con el carácter ! para indicar qué ramas deberían excluirse.

El orden en que defines los patrones importa.

• A matching negative pattern (prefixed with !) after a positive match will exclude the branch.
• A matching positive pattern after a negative match will include the branch again.

Por ejemplo, un flujo de trabajo con el siguiente activador se ejecutará cuando el flujo de trabajo llamado Build se ejecute en una rama que se llame releases/10 o releases/beta/mona pero no en las de nombre releases/10-alpha, releases/beta/3-alpha o main.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Defining inputs for manually triggered workflows

Cuando se utiliza el evento workflow_dispatch, puedes especificar opcionalmente entradas que se pasan al flujo de trabajo.

El flujo de trabajo que se activa recibe las entradas en el contexto de github.event.inputs. Para obtener más información, consulta "Contextos".

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning' 
      tags:
        description: 'Test scenario tags'
        required: false 

jobs:
  print-tag:
    runs-on: ubuntu-latest

    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tag is ${{ github.event.inputs.tag }} 

Utilizar la información de los eventos

La información acerca del evento que activó una ejecución de flujo de trabajo se encuentra disponible en el contexto github.event. Las propiedades en el contexto github.event dependen del tipo de evento que activó 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. For more information, see "Webhook events and payloads."

También puedes imprimir todo el contexto github.event para ver qué propiedades están disponibles para el evento que activó tu 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

Puedes utilizar el contexto github.event en tu flujo de trabajo. Por ejemplo, el siguiente flujo de trabajo se ejecuta cuando se abre una solicitud de cambios que cambia a package*.json, .github/CODEOWNERS o .github/workflows/**. Si el autor de la solicitud de cambios (github.event.pull_request.user.login) no es octobot o dependabot[bot], entonces el flujo de trabajo utilizará el CLI de GitHub para etiquetar y comentar en la solicitud 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/**`. No permitimos contribuciones a estos archivos. Por favor, revisa nuestros [lineamientos de contribución](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) para ver qué tipo de contribuciones se aceptan.'

Para obtener más información sobre los contextos, consulta la sección "Contextos". Para obtener más información sobre las cargas útiles de los eventos, consulta la sección "Eventos y cargas útiles de los webhooks".

Controlar aún más la forma en la que se ejecutará tu flujo de trabajo

Si quieres un control más granular que el que proporcionan los eventos, tipos de actividad de eventos o filtros de evento, puedes utilizar condicionales para controlar si se ejecutarán los jobs o pasos individuales en tu 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. Por ejemplo, si quieres que el flujo de trabajo se ejecute cuando se agrega una etiqueta específica a una propuesta, puedes activar el tipo de actividad de evento issues labeled y utilizar una condicional para verificar qué etiqueta activó el flujo de trabajo. El siguiente flujo de trabajo se ejecutará cuando se agregue cualquier etiqueta a una propuesta en su repositorio, pero el job run_if_label_matches solo se ejecutará si la etiqueta se nombra 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'

Para obtener más información, consulta la sección "Expresiones".

Eventos disponibles

For a full list of available events, see "Events that trigger workflows."