Eventos que disparam fluxos de trabalho

Sobre eventos que acionam fluxos de trabalho

Os acionadores de fluxo de trabalho são eventos que fazem com que um fluxo de trabalho seja executado. Para obter mais informações sobre como usar gatilhos de fluxo de trabalho, confira "Acionando um fluxo de trabalho."

Alguns eventos têm vários tipos de atividades. Para esses eventos, você pode especificar quais tipos de atividade ativarão a execução de um fluxo de trabalho. Para obter mais informações sobre o que significa cada tipo de atividade, confira "Eventos e cargas de webhook."

branch_protection_rule

Executa o fluxo de trabalho quando as regras de proteção de branch no repositório do fluxo de trabalho são alteradas. Para obter mais informações sobre as regras de proteção do branch, confira "Sobre branches protegidos." Para obter informações sobre as APIs da regra de proteção de ramificação, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para ramificações e suas configurações."

Por exemplo, você poderá executar um fluxo de trabalho quando uma regra de proteção de branch for created ou deleted:

on:
  branch_protection_rule:
    types: [created, deleted]

check_run

Executa o fluxo de trabalho quando ocorre a atividade relacionada a uma execução de verificação. Uma execução de verificação é um teste individual que faz parte de um conjunto de verificações. Para obter mais informações, confira "Como usar a API REST para interagir com verificações". Para obter informações sobre as APIs de execução de verificação, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para execuções de verificação."

Por exemplo, você poderá executar um fluxo de trabalho quando uma execução de verificação for rerequested ou completed.

on:
  check_run:
    types: [rerequested, completed]

check_suite

Executa o fluxo de trabalho quando ocorre a atividade do conjunto de verificações. Um conjunto de verificações é uma coleção das execuções de verificação criadas para um commit específico. O conjunto de verificações resumem o status e a conclusão das execuções de verificação que estão no conjunto. Para obter mais informações, confira "Como usar a API REST para interagir com verificações". Para obter informações sobre as APIs de pacote de verificação, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para pacotes de verificação."

Por exemplo, você poderá executar um fluxo de trabalho quando um conjunto de verificações for completed.

on:
  check_suite:
    types: [completed]

create

Executa o fluxo de trabalho quando alguém cria uma referência Git (branch ou tag) no repositório do fluxo de trabalho. Para obter informações sobre as APIs usadas para criar uma referência do Git, confira "Mutações" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para referências Git."

Por exemplo, você poderá executar um fluxo de trabalho quando o evento create ocorrer.

on:
  create

delete

Executa o fluxo de trabalho quando alguém exclui uma referência Git (branch ou tag) no repositório do fluxo de trabalho. Para obter informações sobre as APIs usadas para excluir uma referência do Git, confira "Mutações" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para referências Git."

Por exemplo, você poderá executar um fluxo de trabalho quando o evento delete ocorrer.

on:
  delete

deployment

Executa o fluxo de trabalho quando alguém cria uma implantação no repositório do fluxo de trabalho. As implantações criadas com um SHA de commit podem não ter uma referência do Git. Para obter informações sobre as APIs usadas para criar uma implantação, confira "Mutações" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para repositórios".

Por exemplo, você poderá executar um fluxo de trabalho quando o evento deployment ocorrer.

on:
  deployment

deployment_status

Executa o fluxo de trabalho quando uma terceira parte fornece um status de implantação. As implantações criadas com um SHA de commit podem não ter uma referência do Git. Para obter informações sobre as APIs usadas para criar um status de implantação, confira "Mutações" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para implantações".

Por exemplo, você poderá executar um fluxo de trabalho quando o evento deployment_status ocorrer.

on:
  deployment_status

discussion

Executa o fluxo de trabalho quando uma discussão no repositório do fluxo de trabalho é criada ou modificada. Para as atividades relacionadas a comentários sobre uma discussão, use o evento discussion_comment. Para obter mais informações sobre discussões, confira "Sobre discussões". Para obter informações sobre a API do GraphQL, confira "Objetos."

Por exemplo, você poderá executar um fluxo de trabalho quando uma discussão for created, edited ou answered.

on:
  discussion:
    types: [created, edited, answered]

discussion_comment

Executa o fluxo de trabalho quando um comentário em uma discussão no repositório do fluxo de trabalho é criado ou modificado. Para as atividades relacionadas a uma discussão em vez de comentários sobre uma discussão, use o evento discussion. Para obter mais informações sobre discussões, confira "Sobre discussões". Para obter informações sobre a API do GraphQL, confira "Objetos."

Por exemplo, você poderá executar um fluxo de trabalho quando um comentário de discussão for created ou deleted.

on:
  discussion_comment:
    types: [created, deleted]

fork

Executa o fluxo de trabalho quando alguém bifurca um repositório. Para obter informações sobre a API REST, confira "Pontos de extremidade de API REST para forks."

Por exemplo, você poderá executar um fluxo de trabalho quando o evento fork ocorrer.

on:
  fork

gollum

Executa o fluxo de trabalho quando alguém cria ou atualiza uma página wiki. Para obter mais informações, confira "Sobre wikis".

Por exemplo, você poderá executar um fluxo de trabalho quando o evento gollum ocorrer.

on:
  gollum

issue_comment

Executa o fluxo de trabalho quando um problema ou comentário de pull request é criado, editado ou excluído. Para obter informações sobre as APIs de comentários de problemas, confira "Objetos" na documentação da API do GraphQL ou "Eventos e cargas de webhook" na documentação da API REST.

Por exemplo, você poderá executar um fluxo de trabalho quando um comentário ou um problema de uma solicitação de pull for created ou deleted.

on:
  issue_comment:
    types: [created, deleted]

issue_comment apenas em problemas ou em solicitações de pull

O evento issue_comment ocorre em comentários sobre problemas e solicitações de pull. Você pode usar a propriedade github.event.issue.pull_request em um condicional para realizar uma ação diferente, dependendo se o objeto de gatilho foi um problema ou uma solicitação de pull.

Por exemplo, esse fluxo de trabalho executará o trabalho pr_commented somente se o evento issue_comment for originado de uma solicitação de pull. Ele executará o trabalho issue_commented somente se o evento issue_comment tiver se originado de um problema.

on: issue_comment

jobs:
  pr_commented:
    # This job only runs for pull request comments
    name: PR comment
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on PR $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

  issue_commented:
    # This job only runs for issue comments
    name: Issue comment
    if: ${{ !github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo A comment on issue $NUMBER
        env:
          NUMBER: ${{ github.event.issue.number }}

issues

Executa o fluxo de trabalho quando um problema no repositório do fluxo de trabalho é criado ou modificado. Para as atividades relacionadas a comentários em um problema, use o evento issue_comment. Para obter mais informações sobre problemas, confira "Sobre issues." Para obter informações sobre as APIs de problemas, consulte "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para issues."

Por exemplo, você poderá executar um fluxo de trabalho quando um problema for opened, edited ou milestoned.

on:
  issues:
    types: [opened, edited, milestoned]

label

Executa o fluxo de trabalho quando uma etiqueta no repositório do fluxo de trabalho é criada ou modificada. Para saber mais sobre rótulos, confira "Gerenciar etiquetas". Para obter informações sobre as APIs de rótulo, consulte "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para rótulos."

Caso deseje executar seu fluxo de trabalho quando um rótulo for adicionado ou removido de um problema, uma solicitação de pull ou uma discussão, use os tipos de atividades labeled ou unlabeled para os eventos issues, pull_request, pull_request_target ou discussion.

Por exemplo, você poderá executar um fluxo de trabalho quando um rótulo for created ou deleted.

on:
  label:
    types: [created, deleted]

milestone

Executa o fluxo de trabalho quando um marco no repositório do fluxo de trabalho é criado ou modificado. Para obter mais informações sobre marcos, confira "Sobre marcos." Para obter informações sobre as APIs de etapas, consulte "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para marcos."

Caso deseje executar seu fluxo de trabalho quando um problema for adicionado ou removido de um marco, use os tipos de atividades milestoned ou demilestoned para o evento issues.

Por exemplo, você poderá executar um fluxo de trabalho quando um marco for opened ou deleted.

on:
  milestone:
    types: [opened, deleted]

page_build

Executa o fluxo de trabalho quando alguém faz push em um branch que é a fonte de publicação para GitHub Pages, se o GitHub Pages estiver habilitado no repositório. Para obter mais informações sobre as fontes de publicação do GitHub Pages, confira "Configurar uma fonte de publicação para o site do GitHub Pages." Para obter informações sobre a API REST, confira "Pontos de extremidade da API REST para repositórios."

Por exemplo, você poderá executar um fluxo de trabalho quando o evento page_build ocorrer.

on:
  page_build

project

Executa o fluxo de trabalho quando um projeto (clássico) é criado ou modificado. Para as atividades relacionadas a cartões ou a colunas em um projeto (clássico), use os eventos project_card ou project_column. Para obter mais informações sobre projetos (clássicos), confira "Sobre projects (classic)". Para obter informações sobre as APIs de projeto (clássico), confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para o Projects (classic)".

Por exemplo, você poderá executar um fluxo de trabalho quando um projeto for created ou deleted.

on:
  project:
    types: [created, deleted]

project_card

Executa o fluxo de trabalho quando um cartão em um projeto (clássico) é criado ou modificado. Para atividades relacionadas a projetos (clássicos) ou colunas em um projeto (clássico), use o evento project ou project_column em vez disso. Para obter mais informações sobre projetos (clássicos), confira "Sobre projects (classic)". Para obter informações sobre as APIs de cartões de projetos, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para cartões do Project (classic)".

Por exemplo, você poderá executar um fluxo de trabalho quando um cartão de projeto for created ou deleted.

on:
  project_card:
    types: [created, deleted]

project_column

Executa o fluxo de trabalho quando uma coluna em um projeto (clássico) é criada ou modificada. Para atividades relacionadas a projetos (clássicos) ou cartões em um projeto (clássico), use o evento project ou project_card em vez disso. Para obter mais informações sobre projetos (clássicos), confira "Sobre projects (classic)". Para obter informações sobre as APIs de colunas de projetos, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para o Projects (classic)".

Por exemplo, você poderá executar um fluxo de trabalho quando uma coluna de projeto for created ou deleted.

on:
  project_column:
    types: [created, deleted]

public

Executa o fluxo de trabalho quando o repositório do fluxo de trabalho é alterado de privado para público. Para obter informações sobre a API REST, confira "Pontos de extremidade da API REST para repositórios."

Por exemplo, você poderá executar um fluxo de trabalho quando o evento public ocorrer.

on:
  public

pull_request

Executa o fluxo de trabalho quando ocorre uma atividade em uma pull request no repositório do fluxo de trabalho. Por exemplo, se nenhum tipo de atividade for especificado, o fluxo de trabalho será executado quando uma pull request é aberta ou reaberta, ou quando o branch principal da pull request é atualizado. Para as atividades relacionadas a revisões de solicitação de pull, a comentários de revisão de uma solicitação de pull ou a comentários de uma pull request, use os eventos pull_request_review, pull_request_review_comment ou issue_comment. Para obter informações sobre as APIs de solicitação de pull, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para pull requests."

Observe que o GITHUB_SHA desse evento é o último commit de mesclagem do branch de mesclagem da pull request. Caso deseje obter a ID de commit do último commit no branch principal da pull request, use github.event.pull_request.head.sha.

Por exemplo, você pode executar um fluxo de trabalho quando uma pull request for aberta ou reaberta.

on:
  pull_request:
    types: [opened, reopened]

Você pode usar o contexto do evento para controlar ainda mais quando os trabalhos no seu fluxo de trabalho serão executados. Por exemplo, esse fluxo de trabalho será executado quando uma revisão for solicitada em uma pull request, mas o trabalho specific_review_requested só será executado quando uma revisão por octo-team for solicitada.

on:
  pull_request:
    types: [review_requested]
jobs:
  specific_review_requested:
    runs-on: ubuntu-latest
    if: ${{ github.event.requested_team.name == 'octo-team'}}
    steps:
      - run: echo 'A review from octo-team was requested'

Executar o fluxo de trabalho de pull_request com base no branch de cabeçalho ou no branch base de uma pull request

Você pode usar o filtro branches ou branches-ignore para configurar seu fluxo de trabalho para que ele seja executado somente em solicitações de pull direcionadas a branches específicos. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando alguém abrir uma solicitação de pull direcionada a um branch cujo nome começa com releases/:

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Para executar um trabalho com base no nome do branch de cabeçalho da solicitação de pull (em vez do nome do branch base da solicitação de pull), use o contexto github.head_ref em um condicional. Por exemplo, este fluxo de trabalho será executado sempre que uma solicitação de pull for aberta, mas o trabalho run_if só será executado se o cabeçalho da solicitação de pull for um branch cujo nome começa com releases/:

on:
  pull_request:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Executar o fluxo de trabalho de pull_request com base em arquivos alterados em uma solicitação de pull

Também é possível configurar o fluxo de trabalho para ser executado quando uma pull request alterar arquivos específicos. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando uma solicitação de pull incluir uma alteração em um arquivo JavaScript (.js):

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

on:
  pull_request:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Executar o fluxo de trabalho de pull_request quando ocorrer uma mesclagem de solicitação de pull

Quando uma pull request faz merge, a pull request é automaticamente fechada. Para executar um fluxo de trabalho quando uma pull request é mesclada, use o tipo de evento pull_request closed com um condicional que verifica o valor merged do evento. Por exemplo, o fluxo de trabalho a seguir será executado sempre que uma pull request for fechada. O trabalho if_merged só será executado se a pull request também tiver sido mesclada.

on:
  pull_request:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

Fluxos de trabalho em repositórios com fork

Por padrão, os fluxos de trabalho não são executados em repositórios com fork. É preciso habilitar o GitHub Actions na guia Actions do repositório com fork.

Com exceção do GITHUB_TOKEN, os segredos não são transmitidos para o executor quando um fluxo de trabalho é disparado de um repositório com fork. O GITHUB_TOKEN tem permissões somente leitura em solicitações de pull de repositórios com forks. Para obter mais informações, confira "Autenticação automática de token".

Eventos de pull request para repositórios bifurcados

Para solicitações de pull de um repositório com fork para o repositório base, o GitHub Enterprise Server envia os eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review e pull_request_target para o repositório base. Nenhum evento de solicitação de pull ocorre no repositório com fork.

Para solicitações de pull de um repositório com forks para um repositório privado, os fluxos de trabalho só são executados quando eles são habilitados, confira "Gerenciando as configurações do GitHub Actions para um repositório".

pull_request_comment (use issue_comment)

Para executar o fluxo de trabalho quando um comentário em uma solicitação de pull (não na comparação de uma solicitação de pull) é criado, editado ou excluído, use o evento issue_comment. Para as atividades relacionadas a revisões de solicitação de pull ou a comentários de revisão de uma solicitação de pull, use os eventos pull_request_review ou pull_request_review_comment.

pull_request_review

Executa o fluxo de trabalho quando uma revisão de pull request é enviada, editada ou ignorada. Uma revisão de pull request é um grupo de comentários de revisão de pull request, além de um comentário e estado de texto. Para as atividades relacionadas a comentários de revisão de uma solicitação de pull ou a comentários de uma solicitação de pull, use os eventos pull_request_review_comment ou issue_comment. Para obter informações sobre as APIs de revisão de solicitação de pull, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para pull requests."

Por exemplo, você poderá executar um fluxo de trabalho quando uma revisão de solicitação de pull for edited ou dismissed.

on:
  pull_request_review:
    types: [edited, dismissed]

Executando um fluxo de trabalho quando uma pull request é aprovada

Para executar o fluxo de trabalho quando uma solicitação de pull tiver sido aprovada, dispare o fluxo de trabalho com o tipo submitted de evento pull_request_review e verifique o estado de revisão com a propriedade github.event.review.state. Por exemplo, este fluxo de trabalho será executado sempre que uma revisão de solicitação de pull for enviada, mas o trabalho approved só será executado se a revisão enviada for uma revisão de aprovação:

on:
  pull_request_review:
    types: [submitted]

jobs:
  approved:
    if: github.event.review.state == 'approved'
    runs-on: ubuntu-latest
    steps:
      - run: echo "This PR was approved"

Fluxos de trabalho em repositórios com fork

Por padrão, os fluxos de trabalho não são executados em repositórios com fork. É preciso habilitar o GitHub Actions na guia Actions do repositório com fork.

Com exceção do GITHUB_TOKEN, os segredos não são transmitidos para o executor quando um fluxo de trabalho é disparado de um repositório com fork. O GITHUB_TOKEN tem permissões somente leitura em solicitações de pull de repositórios com forks. Para obter mais informações, confira "Autenticação automática de token".

Eventos de pull request para repositórios bifurcados

Para solicitações de pull de um repositório com fork para o repositório base, o GitHub Enterprise Server envia os eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review e pull_request_target para o repositório base. Nenhum evento de solicitação de pull ocorre no repositório com fork.

Para solicitações de pull de um repositório com forks para um repositório privado, os fluxos de trabalho só são executados quando eles são habilitados, confira "Gerenciando as configurações do GitHub Actions para um repositório".

pull_request_review_comment

Executa o fluxo de trabalho quando um comentário de revisão de pull request é modificado. Um comentário de revisão de pull request é um comentário no diff de uma pull request. Para as atividades relacionadas a revisões de solicitação de pull ou a comentários de uma solicitação de pull, use os eventos pull_request_review ou issue_comment. Para obter informações sobre as APIs dos comentários da revisão de solicitação de pull, consulte "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para pull requests."

Por exemplo, você poderá executar um fluxo de trabalho quando um comentário de revisão de uma solicitação de pull for created ou deleted.

on:
  pull_request_review_comment:
    types: [created, deleted]

Fluxos de trabalho em repositórios com fork

Por padrão, os fluxos de trabalho não são executados em repositórios com fork. É preciso habilitar o GitHub Actions na guia Actions do repositório com fork.

Com exceção do GITHUB_TOKEN, os segredos não são transmitidos para o executor quando um fluxo de trabalho é disparado de um repositório com fork. O GITHUB_TOKEN tem permissões somente leitura em solicitações de pull de repositórios com forks. Para obter mais informações, confira "Autenticação automática de token".

Eventos de pull request para repositórios bifurcados

Para solicitações de pull de um repositório com fork para o repositório base, o GitHub Enterprise Server envia os eventos pull_request, issue_comment, pull_request_review_comment, pull_request_review e pull_request_target para o repositório base. Nenhum evento de solicitação de pull ocorre no repositório com fork.

Para solicitações de pull de um repositório com forks para um repositório privado, os fluxos de trabalho só são executados quando eles são habilitados, confira "Gerenciando as configurações do GitHub Actions para um repositório".

pull_request_target

Executa o fluxo de trabalho quando ocorre uma atividade em uma pull request no repositório do fluxo de trabalho. Por exemplo, se nenhum tipo de atividade for especificado, o fluxo de trabalho será executado quando uma pull request é aberta ou reaberta, ou quando o branch principal da pull request é atualizado.

Esse evento é executado no contexto da base da pull request, em vez de no contexto do commit de mesclagem, como o evento pull_request faz. Isso impede a execução de código inseguro do cabeçalho da pull request que poderia alterar seu repositório ou roubar quaisquer segredos que você usa no fluxo de trabalho. Este evento permite que seu fluxo de trabalho faça coisas como etiquetar ou comentar nas pull requests a partir das bifurcações. Evite usar este evento se você precisar criar ou executar o código a partir da pull request.

Para garantir a segurança do repositório, branches com nomes que correspondem a determinados padrões (como aqueles que se parecem com SHAs) podem não disparar fluxos de trabalho com o evento pull_request_target.

Por exemplo, você poderá executar um fluxo de trabalho quando uma solicitação de pull for assigned, opened, synchronize ou reopened.

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

Executar o fluxo de trabalho de pull_request_target com base no branch de cabeçalho ou no branch base de uma solicitação de pull

Você pode usar o filtro branches ou branches-ignore para configurar seu fluxo de trabalho para que ele seja executado somente em solicitações de pull direcionadas a branches específicos. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando alguém abrir uma solicitação de pull direcionada a um branch cujo nome começa com releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Para executar um trabalho com base no nome do branch de cabeçalho da solicitação de pull (em vez do nome do branch base da solicitação de pull), use o contexto github.head_ref em um condicional. Por exemplo, este fluxo de trabalho será executado sempre que uma solicitação de pull for aberta, mas o trabalho run_if só será executado se o cabeçalho da solicitação de pull for um branch cujo nome começa com releases/:

on:
  pull_request_target:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Executar o fluxo de trabalho de pull_request_target com base em arquivos alterados em uma solicitação de pull

Você pode usar o filtro paths ou paths-ignore para configurar o fluxo de trabalho para ser executado quando uma solicitação de pull alterar arquivos específicos. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando uma solicitação de pull incluir uma alteração em um arquivo JavaScript (.js):

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

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Executar o fluxo de trabalho de pull_request_target quando ocorrer uma mesclagem de solicitação de pull

Quando uma pull request faz merge, a pull request é automaticamente fechada. Para executar um fluxo de trabalho quando uma pull request é mesclada, use o tipo de evento pull_request_target closed com um condicional que verifica o valor merged do evento. Por exemplo, o fluxo de trabalho a seguir será executado sempre que uma pull request for fechada. O trabalho if_merged só será executado se a pull request também tiver sido mesclada.

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged

push

Executa o fluxo de trabalho quando você efetua push em um commit ou tag ou quando cria um repositório a partir de um modelo.

Por exemplo, você poderá executar um fluxo de trabalho quando o evento push ocorrer.

on:
  push

Executando o fluxo de trabalho apenas quando um push para branches específicos ocorre

Você pode usar o filtro branches ou branches-ignore para configurar seu fluxo de trabalho para ser executado somente quando branches específicos forem enviados por push. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando alguém efetuar push para main ou para um branch que começa com releases/.

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Executando o fluxo de trabalho somente quando ocorre um push de tags específicas

Você pode usar o filtro tags ou tags-ignore para configurar seu fluxo de trabalho para ser executado somente quando marcas específicas forem enviadas por push. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando alguém efetuar push de uma marca que começa com v1..

on:
  push:
    tags:
      - v1.**

Executando seu fluxo de trabalho apenas quando um push afeta arquivos específicos

Você pode usar o filtro paths ou paths-ignore para configurar o fluxo de trabalho para ser executado quando ocorrer um push para arquivos específicos. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".

Por exemplo, este fluxo de trabalho será executado quando alguém efetuar push de uma alteração para um arquivo JavaScript (.js):

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

on:
  push:
    branches:
      - 'releases/**'
    paths:
      - '**.js'

registry_package

jobs:
    job_name:
        if: $true

Executa o fluxo de trabalho quando uma atividade relacionada ao GitHub Packages ocorre no seu repositório. Para obter mais informações, confira "Documentação do GitHub Packages".

Por exemplo, você pode executar um fluxo de trabalho quando uma nova versão do pacote foi published.

on:
  registry_package:
    types: [published]

release

Executa o fluxo de trabalho quando a atividade de da versão no repositório ocorre. Para obter informações sobre as APIs de lançamento, confira "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para lançamentos e ativos de lançamento" na documentação da API REST.

Por exemplo, você poderá executar um fluxo de trabalho quando uma versão for published.

on:
  release:
    types: [published]

repository_dispatch

Você pode usar a API do GitHub Enterprise Server para disparar um evento de webhook chamado repository_dispatch quando você deseja disparar um fluxo de trabalho para a atividade que ocorre fora do GitHub Enterprise Server. Para obter mais informações, confira "Pontos de extremidade da API REST para repositórios".

Ao fazer uma solicitação para criar um evento repository_dispatch, você precisa especificar um event_type para descrever o tipo de atividade. Por padrão, todos os tipos de atividade repository_dispatch disparam a execução de um fluxo de trabalho. Você pode usar a palavra-chave types para limitar o fluxo de trabalho a ser executado quando um valor event_type específico é enviado na carga do webhook repository_dispatch.

on:
  repository_dispatch:
    types: [test_result]

Todos os dados enviados por meio do parâmetro client_payload ficarão disponíveis no contexto github.event no seu fluxo de trabalho. Por exemplo, se você enviar esse texto de solicitação quando criar um evento de despacho de repositório:

{
  "event_type": "test_result",
  "client_payload": {
    "passed": false,
    "message": "Error: timeout"
  }
}

então você poderá acessar a carga em um fluxo de trabalho assim:

on:
  repository_dispatch:
    types: [test_result]

jobs:
  run_if_failure:
    if: ${{ !github.event.client_payload.passed }}
    runs-on: ubuntu-latest
    steps:
      - env:
          MESSAGE: ${{ github.event.client_payload.message }}
        run: echo $MESSAGE

schedule

O evento schedule permite disparar um fluxo de trabalho em um horário agendado.

Você pode agendar um fluxo de trabalho para ser executado em horários UTC específicos usando a sintaxe cron POSIX. Fluxos de trabalho agendados executados no último commit no branch padrão ou branch de base. O intervalo mais curto que você pode executar fluxos de trabalho agendados é a cada 5 minutos.

Este exemplo aciona o fluxo de trabalho todos os dias às 17:30 e 17:30 UTC:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '30 5,17 * * *'

Um fluxo de trabalho individual pode ser disparado por vários eventos schedule. Você pode acessar o evento de agendamento que disparou o fluxo de trabalho por meio do contexto github.event.schedule. Este exemplo dispara o fluxo de trabalho a ser executado às 5h30 UTC todas as segundas e quintas, mas ignora a etapa Not on Monday or Wednesday às segundas e quartas.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5 * * 2,4'

jobs:
  test_schedule:
    runs-on: ubuntu-latest
    steps:
      - name: Not on Monday or Wednesday
        if: github.event.schedule != '30 5 * * 1,3'
        run: echo "This step will be skipped on Monday and Wednesday"
      - name: Every time
        run: echo "This step will always run"

A sintaxe cron tem cinco campos separados por um espaço, e cada campo representa uma unidade de tempo.

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *

Você pode usar estes operadores em qualquer um dos cinco campos:

Você pode usar o crontab guru para ajudar a gerar a sintaxe cron e confirmar a hora em que ela será executada. Para ajudar você a começar, há também uma lista de exemplos do crontab guru.

As notificações de fluxos de trabalho agendados são enviadas ao usuário que modificou a sintaxe cron no arquivo do fluxo de trabalho. Para obter mais informações, confira "Notificações para execução de fluxo de trabalho".

status

Executa o fluxo de trabalho quando o status do commit de Git é alterado. Por exemplo, os commits podem ser marcados como error, failure, pending ou success. Caso deseje fornecer mais detalhes sobre a alteração de status, o ideal é usar o evento check_run. Para obter informações sobre as APIs de status do commit, consulte "Objetos" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para commits".

Por exemplo, você poderá executar um fluxo de trabalho quando o evento status ocorrer.

on:
  status

Caso deseje executar um trabalho no seu fluxo de trabalho com base no novo estado de commit, use o contexto github.event.state. Por exemplo, o fluxo de trabalho a seguir é disparado quando um status de commit é alterado, mas o trabalho if_error_or_failure só é executado se o novo estado de commit é error ou failure.

on:
  status
jobs:
  if_error_or_failure:
    runs-on: ubuntu-latest
    if: >-
      github.event.state == 'error' ||
      github.event.state == 'failure'
    steps:
      - env:
          DESCRIPTION: ${{ github.event.description }}
        run: |
          echo The status is error or failed: $DESCRIPTION

watch

Executa o fluxo de trabalho quando o repositório do fluxo de trabalho é favoritado. Para obter informações sobre as APIs de solicitação de pull, confira "Mutações" na documentação da API do GraphQL ou "Pontos de extremidade da API REST para estrela."

Por exemplo, você poderá executar um fluxo de trabalho quando alguém adiciona um repositório aos favoritos, que é o tipo de atividade started para um evento de inspeção.

on:
  watch:
    types: [started]

workflow_call

workflow_call é usado para indicar que um fluxo de trabalho pode ser chamado por outro fluxo de trabalho. Quando um fluxo de trabalho é disparado com o evento workflow_call, a carga do evento no fluxo de trabalho chamado é a mesma carga do evento do fluxo de trabalho de chamada. Para obter mais informações, confira "Reutilizar fluxos de trabalho".

O exemplo abaixo só executa o fluxo de trabalho quando é chamado a partir de outro fluxo de trabalho:

on: workflow_call

workflow_dispatch

Para permitir que um fluxo de trabalho seja disparado manualmente, configure o evento workflow_dispatch. Você pode acionar manualmente uma execução de fluxo de trabalho usando a API do GitHub Enterprise Server, GitHub CLI ou a interface do nevegador de GitHub Enterprise Server. Para obter mais informações, confira "Executar um fluxo de trabalho manualmente".

on: workflow_dispatch

Fornecendo entradas

É possível configurar as propriedades de entrada definidas por personalização, os valores-padrão de entrada e as entradas obrigatórias para o evento diretamente no seu fluxo de trabalho. Ao disparar o evento, você pode fornecer a ref e qualquer inputs. Quando o fluxo de trabalho é executado, você pode acessar os valores de entrada no contexto inputs. Para obter mais informações, confira "Acessar informações contextuais sobre execuções de fluxo de trabalho".

Esse exemplo define entradas chamadas logLevel, tags e environment. Você passa os valores destas entradas para o fluxo de trabalho quando o executa. Em seguida, esse fluxo de trabalho imprime os valores no log usando as propriedades do contexto inputs.logLevel, inputs.tags e inputs.environment.

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
        - info
        - warning
        - debug
      tags:
        description: 'Test scenario tags'
        required: false
        type: boolean
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  log-the-inputs:
    runs-on: ubuntu-latest
    steps:
      - run: |
          echo "Log level: $LEVEL"
          echo "Tags: $TAGS"
          echo "Environment: $ENVIRONMENT"
        env:
          LEVEL: ${{ inputs.logLevel }}
          TAGS: ${{ inputs.tags }}
          ENVIRONMENT: ${{ inputs.environment }}

Se você executar este fluxo de trabalho em um navegador, você deverá inserir valores para as entradas necessárias manualmente antes de o fluxo de trabalho ser executado.

Você também pode passar entradas quando executar um fluxo de trabalho a partir de um script ou usando GitHub CLI. Por exemplo:

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

Para saber mais, confira as informações sobre o GitHub CLI em "Executar um fluxo de trabalho manualmente."

workflow_run

Este evento ocorre quando uma execução do fluxo de trabalho é solicitada ou concluída. Ele permite que você execute um fluxo de trabalho baseado na execução ou conclusão de outro fluxo de trabalho. O fluxo de trabalho iniciado pelo evento workflow_run pode acessar segredos e gravar tokens, mesmo que o fluxo de trabalho anterior não tenha essa permissão. Isso é útil em casos em que o fluxo de trabalho anterior não é intencionalmente privilegiado, mas você precisa tomar uma ação privilegiada em um fluxo de trabalho posterior.

Neste exemplo, um fluxo de trabalho está configurado para ser executado após o fluxo de trabalho "Executar Testes" separado ser concluído.

on:
  workflow_run:
    workflows: [Run Tests]
    types:
      - completed

Se você especificar vários workflows para o evento workflow_run, apenas um dos fluxos de trabalho precisará ser executado. Por exemplo, um fluxo de trabalho com o seguinte gatilho será executado sempre que o fluxo de trabalho "Staging" ou "Lab" forem concluídos.

on:
  workflow_run:
    workflows: [Staging, Lab]
    types:
      - completed

Executando um fluxo de trabalho com base na conclusão de outro fluxo de trabalho

A execução de um fluxo de trabalho é acionada independentemente da conclusão do fluxo de trabalho anterior. Caso deseje executar um trabalho ou uma etapa com base no resultado do fluxo de trabalho disparado, use uma condição com a propriedade github.event.workflow_run.conclusion. Por exemplo, este fluxo de trabalho será executado sempre que um fluxo de trabalho chamado "Build" for concluído, mas o trabalho on-success só será executado se o fluxo de trabalho "Build" for bem-sucedido, e o trabalho on-failure só será executado se o fluxo de trabalho "Build" falhar:

on:
  workflow_run:
    workflows: [Build]
    types: [completed]

jobs:
  on-success:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    steps:
      - run: echo 'The triggering workflow passed'
  on-failure:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
    steps:
      - run: echo 'The triggering workflow failed'

Limitando seu fluxo de trabalho para ser executado com base em branches

Você pode usar o filtro branches ou branches-ignore para especificar os branches em que o fluxo de trabalho de gatilho precisa ser executado para disparar o fluxo de trabalho. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions". Por exemplo, um fluxo de trabalho com o gatilho a seguir só será executado quando o fluxo de trabalho chamado Build for executado em um branch chamado canary.

on:
  workflow_run:
    workflows: [Build]
    types: [requested]
    branches: [canary]

Usando dados do fluxo de trabalho acionador

Você pode acessar a carga do evento workflow_run que corresponde ao fluxo de trabalho que disparou seu fluxo de trabalho. Por exemplo, se o fluxo de trabalho de disparo gerar artefatos, um fluxo de trabalho disparado com o evento workflow_run poderá acessar esses artefatos.

O seguinte fluxo de trabalho faz o upload de dados como um artefato. (Neste exemplo simplificado, os dados são o número da pull request.)

name: Upload data

on:
  pull_request:

jobs:
  upload:
    runs-on: ubuntu-latest

    steps:
      - name: Save PR number
        env:
          PR_NUMBER: ${{ github.event.number }}
        run: |
          mkdir -p ./pr
          echo $PR_NUMBER > ./pr/pr_number
      - uses: actions/upload-artifact@v3
        with:
          name: pr_number
          path: pr/

Quando uma execução do fluxo de trabalho acima é concluída, ela aciona a execução de um fluxo de trabalho seguinte. O fluxo de trabalho a seguir usa o contexto github.event.workflow_run e a API REST do GitHub Enterprise Server para baixar o artefato que foi carregado pelo fluxo de trabalho acima, descompacta o zip do artefato baixado e adiciona comentários à solicitação de pull cujo número foi carregado como um artefato.

name: Use the data

on:
  workflow_run:
    workflows: [Upload data]
    types:
      - completed

jobs:
  download:
    runs-on: ubuntu-latest
    steps:
      - name: 'Download artifact'
        uses: actions/github-script@v6
        with:
          script: |
            let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
               owner: context.repo.owner,
               repo: context.repo.repo,
               run_id: context.payload.workflow_run.id,
            });
            let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
              return artifact.name == "pr_number"
            })[0];
            let download = await github.rest.actions.downloadArtifact({
               owner: context.repo.owner,
               repo: context.repo.repo,
               artifact_id: matchArtifact.id,
               archive_format: 'zip',
            });
            let fs = require('fs');
            fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip pr_number.zip

      - name: 'Comment on PR'
        uses: actions/github-script@v6
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            let fs = require('fs');
            let issue_number = Number(fs.readFileSync('./pr_number'));
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: issue_number,
              body: 'Thank you for the PR!'
            });