Acionando um fluxo de trabalho

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 Server e acionam um evento repository_dispatch em 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.

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 Server 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 Server 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 corresponda 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

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.

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

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'

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

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.

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

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

Eventos disponíveis

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