Activar un flujo de trabajo

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:

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

2. 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.

3. 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) y GITHUB_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/, 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 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, como releases/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/, como releases/10 (refs/heads/releases/10)
• Una etiqueta denominada v2 (refs/tags/v2)
• Una etiqueta cuyo nombre comienza por v1., 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 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, como beta/3-alpha (refs/releases/beta/3-alpha)
• Una etiqueta denominada v2 (refs/tags/v2)
• Una etiqueta cuyo nombre comienza por v1., 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 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'

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

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".

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'

Eventos disponibles

Para ver la lista completa de eventos disponibles, consulte "Eventos que desencadenan flujos de trabajo".