Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Acionando um fluxo de trabalho

Como acionar fluxos de trabalho de GitHub Actions automaticamente

Sobre acionadores de fluxo de trabalho

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 de GitHub Enterprise Cloud e acionam um evento repository_dispatch em GitHub Enterprise Cloud
  • 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.

Os gatilhos de fluxo de trabalho estão definidos com a chave on. Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

As etapas a seguir ocorrem para acionar a execução de um fluxo de trabalho:

  1. Um evento ocorre no seu repositório. O evento tem um SHA de commit associado e um ref de Git.

  2. GitHub Enterprise Cloud pesquisa no diretório .github/workflows no seu repositório para arquivos de fluxo de trabalho que estão presentes no commit SHA ou no ref do Git do evento.

  3. A execução de um fluxo de trabalho é acionada para todos fluxos de trabalho com valores on: que correspondem ao evento de acionamento. Alguns eventos também exigem que o arquivo do fluxo de trabalho esteja presente no branch padrão do repositório para ser executado.

    Cada execução de fluxo de trabalho usará a versão do fluxo de trabalho que está presente no SHA do commit ou na ref do Git do evento. Quando um fluxo de trabalho é executado, o GitHub Enterprise Cloud configura as variáveis de ambiente GITHUB_SHA (commit SHA) e GITHUB_REF (Git ref) no ambiente do executor. Para obter mais informações, consulte "Usando variáveis de ambiente".

Acionando um fluxo de trabalho a partir de um fluxo de trabalho

Ao usar o GITHUB_TOKEN do repositório para executar tarefas, os eventos acionados pelo GITHUB_TOKEN não criarão um novo fluxo de trabalho. Isso impede que você crie execuções de fluxo de trabalho recursivo. Por exemplo, se um fluxo de trabalho executar código pushes usando o GITHUB_TOKEN, um novo fluxo de trabalho não será executado mesmo quando o repositório contém um fluxo de trabalho configurado para ser executado quando ocorrerem eventos push. Para obter mais informações, consulte "Efetuando a autenticação com o GITHUB_TOKEN".

Se você deseja acionar um fluxo de trabalho de dentro de uma execução de fluxo de trabalho, você pode usar um token de acesso pessoal em vez de GITHUB_TOKEN para acionar eventos que exigem um token. Você deverá criar um token de acesso pessoal e armazená-lo como um segredo. Para minimizar seus custos de uso GitHub Actions, certifique-se de que você não cria execução de fluxo de trabalho recursivo ou não intencional. Para obter mais informações sobre a criação de um token de acesso pessoal, consulteCriando um token de acesso pessoal." Para mais informações sobre como armazenar um token de acesso pessoal como segredo, consulte "Criar e armazenar segredos criptografados".

Por exemplo, o fluxo de trabalho a seguir usa um token de acesso pessoal (armazenado como um segredo chamado MY_TOKEN) para adicionar uma etiqueta a um problema por meio de GitHub CLI. Todos os fluxos de trabalho que forem executados quando uma etiqueta é adicionada, serão executados assim que esta etapa for executada.

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"

Inversamente, o fluxo de trabalho a seguir usa GITHUB_TOKEN para adicionar uma etiqueta a um problema. Ele não acionará nenhum fluxo de trabalho executado quando uma etiqueta é adicionada.

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"

Usando eventos para acionar fluxos de trabalho

Use a chave on para especificar quais eventos acionam o seu fluxo de trabalho. Para obter mais informações sobre eventos que você pode usar, consulte "Eventos que acionam fluxos de trabalho."

Usando um evento único

Por exemplo, um fluxo de trabalho com o valor on a seguir será executado quando um push for feito para qualquer branch do repositório do fluxo de trabalho:

on: push

Usando eventos múltiplos

É 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 bifurcar o 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.

Usando tipos de atividade e filtros com vários eventos

É possível usar tipos de atividade e filtros para controlar ainda mais quando o fluxo de trabalho será executado. Para obter mais informações, consulte Usando tipos de atividade do evento e Usando filtros. 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 anexar dois pontos (:) a todos os eventos, incluindo eventos sem configuração.

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

  • Uma etiqueta foi criada
  • Um push é feito noo branch principal do repositório
  • Um push é feito para um branch habilitado para GitHub Pages
on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

Usando tipos de atividade do evento

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 do evento que acionará a execução de um fluxo de trabalho.

Por exemplo, o evento issue_comment tem os tipos de atividade criado, editado e excluído. Se o seu fluxo de trabalho for acionado no evento etiqueta, ele será executado sempre que uma etiqueta for criada, editada ou excluída. Se você especificar o tipo de atividade criado para o evento etiqueta, seu fluxo de trabalho será executado quando uma etiqueta for criada, mas não quando uma etiqueta for editada ou excluída.

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

Para obter mais informações sobre cada evento e seus tipos de atividades, consulte "Eventos que acionam fluxos de trabalho".

Usando filtros

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 de branches que faz com que o fluxo de trabalho seja executado apenas quando um push para um branch que corresponde ao filtro de branches ocorre, ao invés de quando qualquer push ocorre.

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

Usando filtros para direcionar branches específicos para eventos de pull request

Ao usar os eventos de pull_request e pull_request_target, é possível configurar um fluxo de trabalho para que seja executado somente para pull requests que apontem para branches específicos.

Use o filtro branches quando você deseja incluir padrões de nomes de branches ou quando você deseja incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore quando você deseja excluir apenas padrões de nome de branches. Você não pode usar ambos os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho.

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

As palavras-chave branches e branches-ignore aceitam padrões do glob que usam caracteres como *, **, +, ?, ! e outros para combinar com mais de um nome de branch. Se um nome contiver qualquer um desses caracteres e você quiser uma correspondência literal, você deverá escapar de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

Exemplo: Incluindo branches

Os padrões definidos em branches são avaliados com base no nome do ref do Git. Por exemplo, o fluxo de trabalho a seguir seria executado sempre que houvesse um evento pull_request para um direcionamento de pull request:

  • Uma branch denominado principal (refs/heads/main)
  • Uma branch denominado 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 corresponde ao padrão branches-ignore, o fluxo de trabalho não será executado. Os padrões definidos em branches são avaliados com base no nome do ref do Git. Por exemplo, o fluxo de trabalho a seguir seria executado sempre que houver um evento pull_request, a menos que o pull request esteja apontando para:

  • Uma branch denominado mona/octocat (refs/heads/mona/octocat)
  • Uma branch cujo nome corresponde a releases/**-alpha, como beta/3-alpha (refs/releases/beta/3-alpha)
on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:    
      - 'mona/octocat'
      - 'releases/**-alpha'

Exemplo: Incluindo e excluindo branches

Você não pode usar branches e branches-ignore para filtrar o mesmo evento em um único fluxo de trabalho. Se você deseja incluir e excluir padrões de branch para um único evento, use o filtro branches junto com o caractere ! para indicar quais branches devem ser excluídos.

Se você definir um branch com o caractere !, você deverá definir pelo menos um branch sem o caractere !. Se você deseja apenas excluir branches, use branches-ignore.

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

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

The following workflow will run on pull_request events for pull requests that target releases/10 or releases/beta/mona, but not for pull requests that target releases/10-alpha or releases/beta/3-alpha because the negative pattern !releases/**-alpha follows the positive pattern.

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

Usando filtros para direcionar branches ou tags específicas para eventos de push

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

Use o filtro branches quando você deseja incluir padrões de nomes de branches ou quando você deseja incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore quando você deseja excluir apenas padrões de nome de branches. Você não pode usar ambos os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho.

Use o filtro tags quando você deseja incluir padrões de nomes de tags ou quando você deseja incluir e excluir padrões de nomes de tags. Use o filtro tags-ignore quando você deseja excluir apenas padrões de nome de tag. 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 o ref indefinido do Git. Se você não definir tags/tags-ignore ou branches/branches-ignore, o fluxo de trabalho será executado para eventos que afetam branches ou tags. Se você definir os branches/branches-ignore e caminhos, o fluxo de trabalho só será executado quando ambos os filtros forem satisfeitos.

As palavras-chave branches, branches-ignore, tags, and tags-ignore aceitam padrões do glob que usam caracteres como *, **, +, ?, ! e outros para corresponder a mais de um nome do branch ou tag. Se um nome contiver qualquer um desses caracteres e você quiser uma correspondência literal, você deverá escapar de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

Exemplo: Incluindo branches e tags

Os padrões definidos nos branches e tags são avaliados relativamente ao nome do Git ref. Por exemplo, o fluxo de trabalho seguinte seria executado sempre que houver um evento push para:

  • Uma branch denominado principal (refs/heads/main)
  • Uma branch denominado mona/octocat (refs/heads/mona/octocat)
  • Um branch cujo nome começa com releases/, como releases/10 (refs/heads/releases/10)
  • Uma tag denominada v2 (refs/tags/v2)
  • Uma tag 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 corresponde ao padrão de branches-ignore ou tags-ignore o fluxo de trabalho não será executado. Os padrões definidos nos branches e tags são avaliados relativamente ao nome do Git ref. Por exemplo, o fluxo de trabalho a seguir seria executado a cada evento de push, a menos que o evento push seja para:

  • Uma branch denominado mona/octocat (refs/heads/mona/octocat)
  • Uma branch cujo nome corresponde a releases/**-alpha, como beta/3-alpha (refs/releases/beta/3-alpha)
  • Uma tag denominada v2 (refs/tags/v2)
  • Uma tag 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

Você não pode usar branches e branches-ignore para filtrar o mesmo evento em um único fluxo de trabalho. Da mesma forma, você não pode usar tags e tags-ignore para filtrar o mesmo evento em um único fluxo de trabalho. Se você deseja incluir e excluir padrões de branches ou tags para um único evento, use o filtro branches ou tags junto com o caractere ! para indicar quais branches ou tags devem ser excluídos.

Se você definir um branch com o caractere !, você deverá definir pelo menos um branch sem o caractere !. Se você deseja apenas excluir branches, use branches-ignore. Da mesma forma, se você definir uma tag com o caractere !, você também deverá definir pelo menos uma tag sem o caractere !. Se você deseja apenas excluir tags, use tags-ignore.

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

  • Um padrão negativo (precedido por !) depois de uma correspondência positiva excluirá o Git ref.
  • 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, pois o padrão negativo !releases/**-alpha está na sequência do padrão positivo.

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

Usando filtros para direcionar caminhos específicos para pull requests uu eventos de push

Ao usar os eventos push e pull_request, é possível configurar um fluxo de trabalho para ser executado com base em quais caminhos de arquivo são alterados. Os filtros de caminho não são avaliados em pushes de tags.

Use filtro caminhos quando você quiser incluir padrões de caminho dos arquivos ou quando quiser que ambos incluam e excluam padrões de caminhos dos arquivos. Use o filtro paths-ignore quando você deseja excluir apenas padrões de caminho do arquivo. Você não pode usar os dois filtros caminhos e paths-ignore para o mesmo evento em um fluxo de trabalho.

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

As palavras-chave paths e paths-ignore aceitam padrões do glob que usam os caracteres curinga * e ** para coincidir com mais de um nome de caminho. Para obter mais informações, consulte a "Folha de consulta de filtro padrão".

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 seria executado sempre que você fizer push de um arquivo JavaScript (.js).

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

Observação: Se um fluxo de trabalho for ignorado devido à filtragem do caminho, a filtragem do caminho ou mensagem de commit as verificações associadas a esse fluxo de trabalho permanecerão em um estado "Pendente". Um pull request que requer que essas verificações sejam bem sucedidas será bloqueado do merge. For more information, see "Handling skipped but required checks."

Exemplo: Excluindo caminhos

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

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

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

Exemplo: Incluindo e excluindo caminhos

Você não pode usar caminhos e paths-ignore para filtrar o mesmo evento em um único fluxo de trabalho. Se você deseja incluir e excluir padrões de caminho para um único evento, use o filtro caminhos junto com o caractere ! para indicar quais caminhos devem ser excluídos.

Se você definir um caminho com o caractere !, você deverá definir pelo menos um caminho sem o caractere !. Se você deseja apenas excluir caminhos, use paths-ignore.

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

  • Um padrão negativo (precedido por !) depois de uma correspondência positiva excluirá o caminho.
  • 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 seus subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs. Por exemplo, um push que alterou sub-project/index.js ou sub-project/src/index.js acionará uma execução de fluxo de trabalho, mas um push que altere somentesub-project/docs/readme.md não acionará.

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

Comparações Git diff

Observação: Se você fizer push de mais de 1.000 commits, ou se GitHub não gerar o diff devido a um tempo limite, o fluxo de trabalho sempre será executado.

O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e comparando-os à lista de 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:

  • Pull requests: diffs de três pontos são uma comparação entre a versão mais recente do branch de tópico e o commit onde o branch de tópico foi sincronizado pela última vez com o branch de base.
  • Pushes para branches existentes: um diff de dois pontos compara os SHAs head e base, um com o outro.
  • Pushes para novos branches: um diff de dois pontos compara o principal do ancestral do commit mais extenso que foi feito 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, consulte "Sobre comparação de branches em pull requests".

Usando filtros para direcionar branches específicos para eventos de execução de fluxo de trabalho

Ao usar o evento workflow_run, é possível especificar em quais branches o fluxo de trabalho de acionamento deve ser executado para acionar o seu fluxo de trabalho.

Os filtros branches e branches-ignore aceitam padrões do glob que usam caracteres como *, **, +, ?, ! e outros para combinar com mais de um nome de branch. Se um nome contiver qualquer um desses caracteres e você quiser uma correspondência literal, você deverá escapar de cada um desses caracteres especiais com \. Para obter mais informações sobre padrões de glob, consulte a "Folha de informações para filtrar padrões".

Por exemplo, um fluxo de trabalho com o acionamento a seguir só será executado quando o fluxo de trabalho denominado Build for executado em um branch cujo nome comece com releases/:

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

Um fluxo de trabalho com o acionamento a seguir só será executado quando o fluxo de trabalho denominado Build for executado em um branch que não seja denominado canary:

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

Você não pode usar ambos os filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho. Se você deseja incluir e excluir padrões de branch para um único evento, use o filtro branches junto com o caractere ! para indicar quais branches devem ser excluídos.

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

  • Um padrão negativo correspondente (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 acionamento a seguir será executado quando o fluxo de trabalho denominado Build for executado em um branch denominado releases/10 ou releases/beta/mona mas não será executado em releases/10-alpha, releases/beta/3-alpha ou principal.

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

Definindo entradas para fluxos de trabalho acionados manualmente

Ao usar o evento workflow_dispatch, você pode, opcionalmente, especificar as entradas que são passadas para o fluxo de trabalho.

O fluxo de trabalho acionado recebe as entradas no contexto github.event.inputs. Para obter mais informações, consulte "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:  ${{ github.event.inputs.print_tags == 'true' }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ github.event.inputs.tags }} 

Definindo entradas, saídas e segredos para fluxos de trabalho reutilizáveis

É possível definir entradas e segredos que um fluxo de trabalho reutilizável deve receber de um fluxo de trabalho chamado. Também é possível especificar saídas que um fluxo de trabalho reutilizável disponibilizará para um fluxo de trabalho chamado. Para obter mais informações, consulte "Reutilizando fluxos de trabalho".

Usando informações do evento

As informações sobre o evento que desencadeou uma execução de fluxo de trabalho estão disponíveis no contexto github.event. As propriedades no contexto github.event dependem do tipo de evento que acionou o fluxo de trabalho. Por exemplo, um fluxo de trabalho acionado quando um problema está etiquetado teria informações sobre o problema e a etiqueta.

Visualizando todas as propriedades de um evento

Referência à documentação de evento de webhook para propriedades comuns e cargas de exemplo. Para obter mais informações, consulte "Eventos e cargas de Webhook".

Você também pode imprimir o contexto inteiro de github.event para ver quais propriedades estão disponíveis para o evento que acionou o seu fluxo de trabalho:

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

Acessando e usando as propriedades do evento

Você pode usar o contexto github.event no fluxo de trabalho. Por exemplo, o fluxo de trabalho a seguir é executado quando um pull request que muda package*.json, .github/CODEOWNERS ou .github/workflows/** é aberto. Se o autor do pull request (github.event.pull_request.user.login) não for octobot ou dependabot[bot], o fluxo de trabalho usará o GitHub CLI para etiquetar e comentar no 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/**`. Nós não permitimos contribuições para esses arquivos. Consulte nossas [diretrizes de contribuição](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) para saber quais contribuições são aceitas.'

Para obter mais informações sobre os contextos, consulte "Contextos". Para obter mais informações sobre cargas de eventos, consulte "Eventos Webhook e cargas".

Controlando ainda mais como seu fluxo de trabalho será executado

Se você quiser mais controle granular do que os eventos, tipos de atividade do evento ou filtros de evento fornecem, você poderá usar condicionais e ambientes para controlar se os trabalhos ou etapas individuais no seu fluxo de trabalho serão executados.

Usando condicionais

Você pode usar condicionais para controlar ainda mais se os trabalhos ou etapas no seu fluxo de trabalho serão executados.

Exemplo de uso de um valor na carga do evento

Se você quiser, por exemplo, que o fluxo de trabalho seja executado quando uma etiqueta específica for adicionada a um problema, você poderá acionar o tipo de atividade do evento issues labeled e usar uma condicional para verificar qual etiqueta acionou o fluxo de trabalho. O fluxo de trabalho a seguir será executado quando qualquer etiqueta for adicionada a um problema no repositório do fluxo de trabalho, mas a o trabalho run_if_label_matches só será executado se a etiqueta tiver o nome de 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'

Exemplo de uso do tipo de evento

Por exemplo, se você deseja executar diferentes tarefas ou etapas, dependendo de qual evento acionou o fluxo de trabalho, você poderá usar uma condicional para verificar se um tipo de evento específico existe no contexto do evento. O fluxo de trabalho seguinte será executado sempre que um problema ou pull request for fechado. Se o fluxo de trabalho foi executado porque um problema foi fechado, o github.event conterá um valor para problema mas não para pull_request. Portanto, a etapa if_issue será executada mas oa etapa if_pr não será executada. Por outro lado, se o fluxo de trabalho foi executado porque um pull request foi fechado, a etapa if_pr será executada mas a etapa if_issue não será executada.

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 obter mais informações sobre quais informações estão disponíveis no contexto do evento, consulte "Usando informações do evento". Para obter mais informações sobre como usar condicionais, consulte "Expressões".

Usando ambientes para acionar trabalhos de fluxo de trabalho manualmente

Se você quiser acionar manualmente uma tarefa específica em um fluxo de trabalho, você pode usar um ambiente que exige a aprovação de uma equipe ou usuário específico. Primeiro, configure um ambiente com os revisores necessários. Para obter mais informações, consulte "Usando ambientes para implantação". Em seguida, faça referência ao nome do ambiente em um trabalho no seu fluxo de trabalho usando o a chave environment:. Qualquer trabalho que faz referência ao ambiente não será executado até que pelo menos um revisor aprove o trabalho.

Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um push para o principal. O trabalho build sempre será executado. O trabalho publicar será executado somente após a conclusão do trabalho de criar (devido a needs: [build]) e após todas as regras (incluindo os revisores necessários) para o ambiente denominado produção serem aprovadas (devido 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'

Environments, environment protection rules, and environment secrets are available in public repositories for all products. For access to environments in private repositories, you must use GitHub Enterprise. Para obter mais informações, consulte os "produtos do GitHub".

Eventos disponíveis

Para obter uma lista completa de eventos disponíveis, consulte "Eventos que acionam fluxos de trabalho".