Triggering a workflow

About workflow triggers

Os acionadores de fluxo de trabalho são eventos que fazem com que um fluxo de trabalho seja executado. Esses eventos podem ser:

• Eventos que ocorrem no repositório do fluxo de trabalho
• Eventos que ocorrem fora do GitHub Enterprise Server e que disparam um evento repository_dispatch no GitHub Enterprise Server
• Horários agendados
• Manual

Por exemplo, você pode configurar o fluxo de trabalho para executar quando um push é feito no branch padrão do seu repositório, quando uma versão é criada, ou quando um problema é aberto.

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 exemplo, um fluxo de trabalho com o seguinte valor on será executado quando um push for feito em qualquer branch no repositório do fluxo de trabalho:

on: push

Using multiple events

É possível especificar um único evento ou vários eventos. Por exemplo, um fluxo de trabalho com o valor on a seguir será executado quando um push for feito em qualquer branch no repositório ou quando alguém criar um fork do repositório:

on: [push, fork]

Se você especificar vários eventos, apenas um desses eventos deverá ocorrer para acionar seu fluxo de trabalho. Se vários eventos de acionamento para o seu fluxo de trabalho ocorrerem ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas.

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. Se você especificar tipos de atividade ou filtros para um evento e seu fluxo de trabalho for acionado em vários eventos, você deverá configurar cada evento separadamente. Você deve acrescentar dois-pontos (:) a todos os eventos, incluindo eventos sem configuração.

Por exemplo, um fluxo de trabalho com o seguinte valor on será executado quando:

• Uma etiqueta foi criada
• Um push for feito para o branch main no repositório
• Um push é feito para um branch habilitado para GitHub Pages

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

Using event activity types

Alguns eventos têm tipos de atividade que oferecem mais controle sobre quando o fluxo de trabalho deve ser executado. Use on.<event_name>.types para definir o tipo de atividade de evento que vai disparar uma execução de fluxo de trabalho.

Por exemplo, o evento issue_comment tem os tipos de atividades created, edited e deleted. Se o fluxo de trabalho for disparado no evento label, ele será executado sempre que um rótulo for criado, editado ou excluído. Se você especificar o tipo de atividade created para o evento label, o fluxo de trabalho será executado quando um rótulo for criado, mas não quando um rótulo for editado ou excluído.

on:
  label:
    types:
      - created

Se você especificar vários tipos de atividades, apenas um desses tipos de atividade deverá ocorrer para acionar o fluxo de trabalho. Se vários tipos de atividade do evento de acionamento ocorrer em seu fluxo de trabalho ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas. Por exemplo, os acionadores de fluxo de trabalho a seguir quando um problema é aberto ou identificado. Se um problema com duas etiquetas for aberta, serão iniciadas três execuções de fluxos de trabalho: uma para o problema aberto e duas para os dois problemas etiquetados.

on:
  issues:
    types:
      - opened
      - labeled

Para obter mais informações sobre cada evento e os respectivos tipos de atividades, confira "Eventos que disparam fluxos de trabalho".

Using filters

Alguns eventos têm filtros que dão mais controle sobre quando seu fluxo de trabalho deve ser executado.

Por exemplo, o evento push tem um filtro branches que faz com que seu fluxo de trabalho seja executado somente quando ocorrer um push para um branch que corresponde ao filtro branches, em vez de quando ocorrer qualquer push.

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

Using filters to target specific branches for pull request events

Ao usar os eventos pull_request e pull_request_target, você pode configurar um fluxo de trabalho para ser executado somente para solicitações de pull direcionadas a branches específicos.

Use o filtro branches quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho.

Se você definir branches/branches-ignore e paths, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.

As palavras-chave branches e branches-ignore aceitam padrões glob que usam caracteres como *, **, +, ?, ! e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".

Exemplo: Incluindo branches

Os padrões definidos em branches são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request para uma solicitação de pull direcionada a:

• Um branch chamado main (refs/heads/main)
• Um branch chamado mona/octocat (refs/heads/mona/octocat)
• Um branch cujo nome começa com releases/, como releases/10 (refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:    
      - main
      - 'mona/octocat'
      - 'releases/**'

Exemplo: Excluir branches

Quando um padrão corresponder ao padrão branches-ignore, o fluxo de trabalho não será executado. Os padrões definidos em branches são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request, a menos que a solicitação de pull seja direcionada a:

• Um branch chamado mona/octocat (refs/heads/mona/octocat)
• Um branch cujo nome corresponde a 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'

Exemplo: Incluindo e excluindo branches

Não é possível usar branches e branches-ignore para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches com o caractere ! para indicar os branches que devem ser excluídos.

Se você definir um branch com o caractere !, também precisará definir, pelo menos, um branch sem o caractere !. Caso deseje apenas excluir os branches, use branches-ignore.

A ordem na qual você define os padrões é importante.

• Um padrão de correspondência negativa (precedido por !) após uma correspondência positiva excluirá a referência do Git.
• Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.

O fluxo de trabalho a seguir será executado em eventos pull_request para solicitações de pull direcionadas a releases/10 ou releases/beta/mona, mas não para solicitações de pull direcionadas a releases/10-alpha ou releases/beta/3-alpha, porque o padrão !releases/**-alpha negativo segue o padrão positivo.

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

Using filters to target specific branches or tags for push events

Ao usar o evento push, você pode configurar um fluxo de trabalho para ser executado em marcas ou em branches específicos.

Use o filtro branches quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho.

Use o filtro tags quando quiser incluir padrões de nomes de marcas ou quando quiser incluir e excluir padrões de nomes de marcas. Use o filtro tags-ignore quando quiser excluir apenas padrões de nomes de marcas. Não é possível usar os filtros tags e tags-ignore para o mesmo evento em um fluxo de trabalho.

Se você definir apenas tags/tags-ignore ou apenas branches/branches-ignore, o fluxo de trabalho não será executado para eventos que afetam a referência indefinida do Git. Se você não definir tags/tags-ignore nem branches/branches-ignore, o fluxo de trabalho será executado para eventos que afetam branches ou marcas. Se você definir branches/branches-ignore e paths, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.

As palavras-chave branches, branches-ignore, tags e tags-ignore aceitam padrões glob que usam caracteres como *, **, +, ?, ! e outros para corresponder a mais de um nome de marca ou de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".

Exemplo: Incluindo branches e tags

Os padrões definidos em branches e tags são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push para:

• Um branch chamado main (refs/heads/main)
• Um branch chamado mona/octocat (refs/heads/mona/octocat)
• Um branch cujo nome começa com releases/, como releases/10 (refs/heads/releases/10)
• Uma marca chamada v2 (refs/tags/v2)
• Uma marca cujo nome começa com 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.*

Exemplo: Excluindo branches e tags

Quando um padrão corresponder ao padrão branches-ignore ou tags-ignore, o fluxo de trabalho não será executado. Os padrões definidos em branches e tags são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push, a menos que o evento push seja para:

• Um branch chamado mona/octocat (refs/heads/mona/octocat)
• Um branch cujo nome corresponde a releases/**-alpha, como beta/3-alpha (refs/releases/beta/3-alpha)
• Uma marca chamada v2 (refs/tags/v2)
• Uma marca cujo nome começa com 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.*

Exemplo: Incluindo e excluindo branches e tags

Não é possível usar branches e branches-ignore para filtrar o mesmo evento em um fluxo de trabalho individual. Da mesma forma, não é possível usar tags e tags-ignore para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de branch para um evento individual, use o filtro branches ou tags com o caractere ! para indicar as marcas ou os branches que devem ser excluídos.

Se você definir um branch com o caractere !, também precisará definir, pelo menos, um branch sem o caractere !. Caso deseje apenas excluir os branches, use branches-ignore. Da mesma forma, se você definir uma marca com o caractere !, também precisará definir, pelo menos, uma marca sem o caractere !. Caso deseje apenas excluir as marcas, use tags-ignore.

A ordem na qual você define os padrões é importante.

• Um padrão de correspondência negativa (precedido por !) após uma correspondência positiva excluirá a referência do Git.
• Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.

O fluxo de trabalho a seguir será executado em pushes para releases/10 ou releases/beta/mona, mas não em releases/10-alpha ou releases/beta/3-alpha porque o padrão !releases/**-alpha negativo vem após o padrão positivo.

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

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

Ao usar os eventos push e pull_request, você pode configurar um fluxo de trabalho para ser executado com base nos caminhos de arquivo alterados. Os filtros de caminho não são avaliados em pushes de tags.

Use o filtro paths quando quiser incluir padrões de caminho de arquivo ou quando quiser incluir e excluir padrões de caminho de arquivo. Use o filtro paths-ignore quando quiser apenas excluir padrões de caminho de arquivo. Não é possível usar os filtros paths e paths-ignore para o mesmo evento em um fluxo de trabalho.

Se você definir branches/branches-ignore e paths, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.

As palavras-chave paths e paths-ignore aceitam padrões glob que usam os caracteres curinga * e ** para fazer a correspondência com mais de um nome de caminho. Para obter mais informações, confira a "Folha de referências de padrões de filtro".

Exemplo: Incluindo caminhos

Se, pelo menos, um caminho corresponder a um padrão no filtro paths, o fluxo de trabalho será executado. Por exemplo, o fluxo de trabalho a seguir será executado sempre que você efetuar push de um arquivo JavaScript (.js).

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

Exemplo: Excluindo caminhos

Quando todos os nomes de caminho corresponderem aos padrões de paths-ignore, o fluxo de trabalho não será executado. Se qualquer nome de caminho não corresponder aos padrões de paths-ignore, mesmo que alguns nomes de caminho correspondam aos padrões, o fluxo de trabalho será executado.

Um fluxo de trabalho com o filtro de caminho a seguir só será executado em eventos push que incluem, pelo menos, um arquivo fora do diretório docs na raiz do repositório.

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

Exemplo: Incluindo e excluindo caminhos

Não é possível usar paths e paths-ignore para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro paths com o caractere ! para indicar os caminhos que devem ser excluídos.

Se você definir um caminho com o caractere !, também precisará definir, pelo menos, um caminho sem o caractere !. Caso você deseje apenas excluir os caminhos, use paths-ignore.

A ordem de definição dos padrões é importante:

• Um padrão de correspondência negativa (precedido por !) após uma correspondência positiva excluirá o caminho do Git.
• Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.

Este exemplo é executado sempre que o evento push inclui um arquivo no diretório sub-project ou nos respectivos subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs. Por exemplo, um push que alterar sub-project/index.js ou sub-project/src/index.js vai disparar uma execução de fluxo de trabalho, mas um push que só altera sub-project/docs/readme.md não.

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

Comparações Git diff

O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e executando-os na lista paths-ignore ou paths. Se não houver arquivos alterados, o fluxo de trabalho não será executado.

O GitHub gera a lista de arquivos alterados usando diffs de dois pontos para pushes e diffs de três pontos para pull requests:

• Solicitações de pull: as comparações de três pontos são uma comparação entre a versão mais recente do branch do tópico e o commit em que o branch do tópico foi sincronizado pela última vez com o branch base.
• Pushes para branches existentes: uma comparação de dois pontos compara os SHAs principal e base diretamente um com o outro.
• Pushes para novos branches: uma comparação de dois pontos com o pai do ancestral do commit mais profundo enviado por push.

Os diffs limitam-se a 300 arquivos. Se houver arquivos alterados que não correspondam aos primeiros 300 arquivos retornados pelo filtro, o fluxo de trabalho não será executado. Talvez seja necessário criar filtros mais específicos para que o fluxo de trabalho seja executado automaticamente.

Para obter mais informações, confira "Sobre a comparação de branches em solicitações de pull".

Using filters to target specific branches for workflow run events

Ao usar o evento workflow_run, você pode especificar os branches nos quais o fluxo de trabalho de gatilho precisa ser executado para disparar o fluxo de trabalho.

Os filtros branches e branches-ignore aceitam padrões glob que usam caracteres como *, **, +, ?, ! e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões glob, confira a "Folha de referências de padrões de filtro".

Por exemplo, um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build for executado em um branch cujo nome começa com releases/:

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

Um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build for executado em um branch que não seja chamado canary:

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

Não é possível usar os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches com o caractere ! para indicar os branches que devem ser excluídos.

A ordem na qual você define os padrões é importante.

• Um padrão de correspondência negativa (precedido por !) após uma correspondência positiva excluirá o branch.
• Um padrão positivo correspondente após uma correspondência negativa incluirá o branch novamente.

Por exemplo, um fluxo de trabalho com o gatilho a seguir será executado quando o fluxo de trabalho chamado Build for executado em um branch chamado releases/10 ou releases/beta/mona que não será releases/10-alpha, releases/beta/3-alpha ou 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."