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 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 la sección "Autenticarse 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. Para obtener más información sobre los eventos que puedes utilizar, consulta la sección "Eventos que activan 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 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

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, consulta las secciones Utilizar tipos de actividad de eventos y Utilizar 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. 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:

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. Utiliza on.<event_name>.types para definir el tipo de actividad de evento qeu activará una ejecución de flujo de trabajo.

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/**'

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, 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 empata 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 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 los eventos de pull_request para aquellas solicitudes de cambios que apunten a releases/10 o a releases/beta/mona, pero no para aquellas que apunten a releases/10-alpha o releases/beta/3-alpha, ya que 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

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 defines únicamente tags/tags-ignore o solo branches/branches-ignore, el flujo de trabajo no se ejecutará para los eventos que afecten una Git ref indefinida. Si no defines tags/tags-ignore ni branches/branches-ignore, el flujo de trabajo se ejecutará para los eventos que afectan ya sea ramas o etiquetas. 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'

Utilizar filtros para apuntar a rutas específicas para los eventos de subida o solicitudes de cambios

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. Utiliza el filtro paths-ignore cuando solo quieras excluir los patrones de ruta de archivo. No puedes utilizar tanto el filtro de paths como el de paths-ignore juntos en el mismo evento en un flujo de trabajo.

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

Las palabras clave paths y paths-ignore aceptan patrones globales que utilicen los caracteres de comodín * y ** para empatar con más de un nombre de ruta. 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. Por ejemplo, el siguiente flujo de trabajo se ejecutaría siempre que subieras un archivo de JavaScript (.js).

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

Ejemplo: Excluir las rutas

Cuando todos los nombres de ruta coincidan con los patrones en paths-ignore, el flujo de trabajo no se ejecutará. Si alguno de los nombres de ruta no empatan con los patrones en paths-ignore, incluso si algunos de ellos sí lo hacen, el flujo de trabajo se ejecutará.

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/**'

Ejemplo: Incluir y excluir rutas

No puedes utilizar paths y paths-ignore para filtrar el mismo evento en un solo flujo de trabajo. Si quieres tanto incluir como excluir patrones de ruta para un solo evento, utiliza el filtro de paths en conjunto con el carácter ! para indicar qué rutas deben excluirse.

Si defines una ruta con el carácter !, también debes definir por lo menos una ruta sin el carácter !. Si solo quieres excluir rutas, utiliza paths-ignore en su lugar.

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

Utilizar filtros para apuntar a ramas específicas para los eventos de ejecución de flujos de trabajo

Cuando utilices el evento workflow_run, puedes especificar qué ramas debe ejecutar el flujo de trabajo activador para que se active tu flujo.

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

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 inicie con 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 llamado Build se ejecute en una rama que no se llame 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.

• 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 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'

Definir entradas para los flujos de trabajo que se activan manualmente

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

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

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning' 
      print_tags:
        description: 'True to print to STDOUT'
        required: true 
      tags:
        description: 'Test scenario tags'
        required: true 

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if:  ${{ github.event.inputs.print_tags == 'true' }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ github.event.inputs.tags }} 

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. Para obtener más información, consulta la sección "Eventos y cargas útiles de los webhooks".

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.

Ejemplo utilizando un valor en la carga útil del evento

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'

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 ejecutó debido a que se cerró una propuesta, el contexto github.event contendrá un valor para la issue pero no para la pull_request. Por lo tanto, el paso de if_issue se ejecutará, pero el de if_pr no lo hará. Por el contrario, si el flujo de trabajo se ejecutó porque se cerró una solicitud de cambios, el paso de if_pr se ejecutará pero el de if_issue no lo hará.

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é tipo de información está disponible ene l contexto del evento, consulta la sección "Utilizar la información de los eventos". Para obtener más información sobre cómo utilizar las condicionales, consulta la sección "Expresiones".

Eventos disponibles

Para encontrar una lista completa de todos los eventos disponibles, consulta la sección "Eventos que activan flujos de trabajo".