Triggering a workflow

About workflow triggers

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 Enterprise Server y desencadenan un evento 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.

Workflow triggers are defined with the on key. For more information, see "Workflow syntax for GitHub Actions."

The following steps occur to trigger a workflow run:

1. An event occurs on your repository. The event has an associated commit SHA and Git ref.

2. GitHub Enterprise Server searches the .github/workflows directory in your repository for workflow files that are present in the associated commit SHA or Git ref of the event.

3. A workflow run is triggered for any workflows that have on: values that match the triggering event. Some events also require the workflow file to be present on the default branch of the repository in order to run.

   Each workflow run will use the version of the workflow that is present in the associated commit SHA or Git ref of the event. When a workflow runs, GitHub Enterprise Server sets the GITHUB_SHA (commit SHA) and GITHUB_REF (Git ref) environment variables in the runner environment. For more information, see "Using environment variables."

Triggering a workflow from a workflow

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository's GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur. For more information, see "Authenticating with the GITHUB_TOKEN."

If you do want to trigger a workflow from within a workflow run, you can use a personal access token instead of GITHUB_TOKEN to trigger events that require a token. You'll need to create a personal access token and store it as a secret. To minimize your GitHub Actions usage costs, ensure that you don't create recursive or unintended workflow runs. For more information about creating a personal access token, see "Creating a personal access token." For more information about storing a personal access token as a secret, see "Creating and storing encrypted secrets."

For example, the following workflow uses a personal access token (stored as a secret called MY_TOKEN) to add a label to an issue via GitHub CLI. Any workflows that run when a label is added will run once this step is performed.

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"

Conversely, the following workflow uses GITHUB_TOKEN to add a label to an issue. It will not trigger any workflows that run when a label is added.

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"

Using events to trigger workflows

Use the on key to specify what events trigger your workflow. For more information about events you can use, see "Events that trigger workflows."

Using a single event

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

Using multiple events

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.

Using activity types and filters with multiple events

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

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 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, vea "Eventos que desencadenan flujos de trabajo".

Using filters

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

Using filters to target specific branches for pull request events

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 obtener más información sobre los patrones globales, consulte la "Hoja de referencia rápida de patrones de filtro".

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'

Using filters to target specific branches or tags for push events

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 define branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando se cumplan los dos 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 obtener más información sobre los patrones globales, consulte la "Hoja de referencia rápida de patrones de filtro".

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'

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

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 defines branches/branches-ignore y paths, el flujo de trabajo solo se ejecutará cuando se cumplan ambos 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 la "Hoja de referencia de patrones de filtro".

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, consulta "Acerca de la comparación de ramas en las solicitudes de incorporación de cambios".

Using filters to target specific branches for workflow run events

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 obtener más información sobre los patrones globales, consulte la "Hoja de referencia rápida de patrones de filtro".

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'

Defining inputs for manually triggered workflows

When using the workflow_dispatch event, you can optionally specify inputs that are passed to the workflow.

The triggered workflow receives the inputs in the github.event.inputs context. For more information, see "Contexts."

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 }} 

Using event information

Information about the event that triggered a workflow run is available in the github.event context. The properties in the github.event context depend on the type of event that triggered the workflow. For example, a workflow triggered when an issue is labeled would have information about the issue and label.

Viewing all properties of an event

Reference the webhook event documentation for common properties and example payloads. For more information, see "Webhook events and payloads."

You can also print the entire github.event context to see what properties are available for the event that triggered your workflow:

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

Accessing and using event properties

You can use the github.event context in your workflow. For example, the following workflow runs when a pull request that changes package*.json, .github/CODEOWNERS, or .github/workflows/** is opened. If the pull request author (github.event.pull_request.user.login) is not octobot or dependabot[bot], then the workflow uses the GitHub CLI to label and comment on the pull request (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.'

For more information about contexts, see "Contexts." For more information about event payloads, see "Webhook events and payloads."

Further controlling how your workflow will run

If you want more granular control than events, event activity types, or event filters provide, you can use conditionals and environments to control whether individual jobs or steps in your workflow will run.

Using conditionals

You can use conditionals to further control whether jobs or steps in your workflow will run.

Example using a value in the event payload

For example, if you want the workflow to run when a specific label is added to an issue, you can trigger on the issues labeled event activity type and use a conditional to check what label triggered the workflow. The following workflow will run when any label is added to an issue in the workflow's repository, but the run_if_label_matches job will only execute if the label is named 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'

Example using event type

For example, if you want to run different jobs or steps depending on what event triggered the workflow, you can use a conditional to check whether a specific event type exists in the event context. The following workflow will run whenever an issue or pull request is closed. If the workflow ran because an issue was closed, the github.event context will contain a value for issue but not for pull_request. Therefore, the if_issue step will run but the if_pr step will not run. Conversely, if the workflow ran because a pull request was closed, the if_pr step will run but the if_issue step will not run.

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

For more information about what information is available in the event context, see "Using event information." For more information about how to use conditionals, see "Expressions."

Using environments to manually trigger workflow jobs

If you want to manually trigger a specific job in a workflow, you can use an environment that requires approval from a specific team or user. First, configure an environment with required reviewers. For more information, see "Using environments for deployment." Then, reference the environment name in a job in your workflow using the environment: key. Any job referencing the environment will not run until at least one reviewer approves the job.

For example, the following workflow will run whenever there is a push to main. The build job will always run. The publish job will only run after the build job successfully completes (due to needs: [build]) and after all of the rules (including required reviewers) for the environment called production pass (due to 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'

Available events

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