Observação: no momento, não há suporte para os executores hospedados no GitHub no GitHub Enterprise Server. Você pode ver mais informações sobre o suporte futuro planejado no GitHub public roadmap.
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 do GitHub Enterprise Server e que disparam um evento
repository_dispatch
no GitHub Enterprise Server - Horários agendados
- Manual
Por exemplo, você pode configurar o fluxo de trabalho para executar quando um push é feito no branch padrão do seu repositório, quando uma versão é criada, ou quando um problema é aberto.
Os gatilhos de fluxo de trabalho são definidos com a chave on
. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".
As etapas a seguir ocorrem para acionar a execução de um fluxo de trabalho:
-
Um evento ocorre no seu repositório. O evento tem um SHA de commit associado e um ref de Git.
-
O GitHub Enterprise Server pesquisa, no diretório
.github/workflows
na raiz do seu repositório, os arquivos de fluxo de trabalho que estão presentes no SHA do commit associado ou na referência do Git do evento. -
A execução de um fluxo de trabalho é disparada para todos os fluxos de trabalho que têm valores
on:
correspondentes ao evento de gatilho. 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 define as variáveis de ambiente
GITHUB_SHA
(SHA do commit) eGITHUB_REF
(referência do Git) no ambiente do executor. Para obter mais informações, confira "Store information in variables".
Acionando um fluxo de trabalho a partir de um fluxo de trabalho
Quando você usar o GITHUB_TOKEN
do repositório para executar tarefas, eventos disparados pelo GITHUB_TOKEN
, com exceção do workflow_dispatch
e do repository_dispatch
, não criarão uma execução de fluxo de trabalho. Isso impede que você crie execuções de fluxo de trabalho recursivo. Por exemplo, se uma execução de fluxo de trabalho efetuar push do código usando o GITHUB_TOKEN
do repositório, um novo fluxo de trabalho não será executado mesmo quando o repositório contiver um fluxo de trabalho configurado para ser executado quando os eventos do push
ocorrerem. Para obter mais informações, confira "Autenticação automática de token".
Para disparar um fluxo de trabalho de dentro de uma execução de fluxo de trabalho, use um token de acesso de instalação do GitHub App ou um personal access token em vez de GITHUB_TOKEN
a fim de disparar eventos que exigem um token.
Se você usar um GitHub App, será necessário criar um GitHub App e armazenar a ID do aplicativo e a chave privada como segredos. Para obter mais informações, confira "Fazer solicitações de API autenticadas com um Aplicativo do GitHub em um fluxo de trabalho do GitHub Actions". Se você usar um personal access token, precisará criar um personal access token e armazená-lo como um segredo. Para obter mais informações sobre como criar um personal access token, confira "Gerenciar seus tokens de acesso pessoal". Para saber mais sobre como armazenar segredos, confira "Usar segredos em ações do GitHub".
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.
Por exemplo, o fluxo de trabalho a seguir usa um personal access token (armazenado como um segredo chamado MY_TOKEN
) para adicionar um rótulo a um problema por meio da 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:
GH_TOKEN: ${{ secrets.MY_TOKEN }}
ISSUE_URL: ${{ github.event.issue.html_url }}
run: |
gh issue edit $ISSUE_URL --add-label "triage"
Por outro lado, o fluxo de trabalho a seguir usa GITHUB_TOKEN
para adicionar um rótulo 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:
GH_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 os eventos que disparam o fluxo de trabalho. Para obter mais informações sobre os eventos que podem ser usados, confira "Eventos que disparam fluxos de trabalho".
Usando um evento único
Por exemplo, um fluxo de trabalho com o seguinte valor on
será executado quando um push for feito em qualquer branch no repositório do fluxo de trabalho:
on: push
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 criar um fork do repositório:
on: [push, fork]
Se você especificar vários eventos, apenas um desses eventos deverá ocorrer para acionar seu fluxo de trabalho. Se vários eventos de acionamento para o seu fluxo de trabalho ocorrerem ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas.
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, confira Como usar tipos de atividade de evento e Como usar 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 acrescentar dois-pontos (:
) a todos os eventos, incluindo eventos sem configuração.
Por exemplo, um fluxo de trabalho com o seguinte valor on
será executado quando:
- Uma etiqueta foi criada
- Um push for feito para o branch
main
no repositório - Um push é feito para um branch habilitado para GitHub Pages
on:
label:
types:
- created
push:
branches:
- main
page_build:
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 de evento que vai disparar uma execução de fluxo de trabalho.
Por exemplo, o evento issue_comment
tem os tipos de atividades created
, edited
e deleted
. Se o fluxo de trabalho for disparado no evento label
, ele será executado sempre que um rótulo for criado, editado ou excluído. Se você especificar o tipo de atividade created
para o evento label
, o fluxo de trabalho será executado quando um rótulo for criado, mas não quando um rótulo for editado ou excluído.
on:
label:
types:
- created
Se você especificar vários tipos de atividades, apenas um desses tipos de atividade deverá ocorrer para acionar o fluxo de trabalho. Se vários tipos de atividade do evento de acionamento ocorrer em seu fluxo de trabalho ao mesmo tempo, várias execuções de fluxo de trabalho serão acionadas. Por exemplo, os acionadores de fluxo de trabalho a seguir quando um problema é aberto ou identificado. Se um problema com duas etiquetas for aberta, serão iniciadas três execuções de fluxos de trabalho: uma para o problema aberto e duas para os dois problemas etiquetados.
on:
issues:
types:
- opened
- labeled
Para obter mais informações sobre cada evento e seus tipos de atividade, confira "Eventos que disparam 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 branches
que faz com que seu fluxo de trabalho seja executado somente quando ocorrer um push para um branch que corresponde ao filtro branches
, em vez de quando ocorrer qualquer push.
on:
push:
branches:
- main
- 'releases/**'
Usando filtros para direcionar branches específicos para eventos de pull request
Ao usar os eventos pull_request
e pull_request_target
, você pode configurar um fluxo de trabalho para ser executado somente para solicitações de pull direcionadas a branches específicos.
Use o filtro branches
quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore
quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho.
Se você definir branches
/branches-ignore
e paths
/paths-ignore
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave branches
e branches-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira o "Sintaxe de fluxo de trabalho para o GitHub Actions".
Exemplo: Incluindo branches
Os padrões definidos em branches
são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request
para uma solicitação de pull direcionada a:
- Um branch chamado
main
(refs/heads/main
) - Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome começa com
releases/
, comoreleases/10
(refs/heads/releases/10
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
Você não deverá usar a filtragem de caminho ou ramificação para ignorar execuções de fluxo de trabalho se for necessário passar o fluxo de trabalho antes da mesclagem. Para obter mais informações, confira "Ignorar execuções de fluxo de trabalho" e "Regras disponíveis para conjuntos de regras."
Se um fluxo de trabalho for ignorado devido à filtragem de ramificação, à filtragem de caminho ou a uma mensagem de confirmação, as verificações associadas a esse fluxo de trabalho permanecerão no estado "Pendente". Uma solicitação de pull que exige que essas verificações sejam bem-sucedidas não poderá ser mesclada.
Exemplo: Excluir branches
Quando um padrão corresponder ao padrão branches-ignore
, o fluxo de trabalho não será executado. Os padrões definidos em branches-ignore
são avaliados em relação ao nome da referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento pull_request
, a menos que a solicitação de pull seja direcionada a:
- Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome corresponde a
releases/**-alpha
, comoreleases/beta/3-alpha
(refs/heads/releases/beta/3-alpha
)
on:
pull_request:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
Exemplo: Incluindo e excluindo branches
Não é possível usar branches
e branches-ignore
para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches
com o caractere !
para indicar os branches que devem ser excluídos.
Se você definir um branch com o caractere !
, também precisará definir, pelo menos, um branch sem o caractere !
. Caso deseje apenas excluir os branches, use branches-ignore
.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá a referência do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.
O fluxo de trabalho a seguir será executado em eventos pull_request
para solicitações de pull direcionadas a releases/10
ou releases/beta/mona
, mas não para solicitações de pull direcionadas a releases/10-alpha
ou releases/beta/3-alpha
, porque o padrão !releases/**-alpha
negativo segue o padrão positivo.
on:
pull_request:
branches:
- 'releases/**'
- '!releases/**-alpha'
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 marcas ou em branches específicos.
Use o filtro branches
quando quiser incluir padrões de nomes de branches ou quando quiser incluir e excluir padrões de nomes de branches. Use o filtro branches-ignore
quando quiser excluir apenas padrões de nomes de branches. Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho.
Use o filtro tags
quando quiser incluir padrões de nomes de marcas ou quando quiser incluir e excluir padrões de nomes de marcas. Use o filtro tags-ignore
quando quiser excluir apenas padrões de nomes de marcas. Não é possível usar os filtros tags
e tags-ignore
para o mesmo evento em um fluxo de trabalho.
Se você definir apenas tags
/tags-ignore
ou apenas branches
/branches-ignore
, o fluxo de trabalho não será executado para eventos que afetam a referência indefinida do Git. Se você não definir tags
/tags-ignore
nem branches
/branches-ignore
, o fluxo de trabalho será executado para eventos que afetam branches ou marcas. Se você definir branches
/branches-ignore
e paths
/paths-ignore
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave branches
, branches-ignore
, tags
e tags-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de marca ou de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira o "Sintaxe de fluxo de trabalho para o GitHub Actions".
Exemplo: Incluindo branches e tags
Os padrões definidos em branches
e tags
são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push
para:
- Um branch chamado
main
(refs/heads/main
) - Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome começa com
releases/
, comoreleases/10
(refs/heads/releases/10
) - Uma marca chamada
v2
(refs/tags/v2
) - Uma marca cujo nome começa com
v1.
, comov1.9.1
(refs/tags/v1.9.1
)
on:
push:
# Sequence of patterns matched against refs/heads
branches:
- main
- 'mona/octocat'
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v2
- v1.*
Exemplo: Excluindo branches e tags
Quando um padrão corresponder ao padrão branches-ignore
ou tags-ignore
, o fluxo de trabalho não será executado. Os padrões definidos em branches
e tags
são avaliados em relação ao nome de referência do Git. Por exemplo, o seguinte fluxo de trabalho será executado sempre que houver um evento push
, a menos que o evento push
seja para:
- Um branch chamado
mona/octocat
(refs/heads/mona/octocat
) - Um branch cujo nome corresponde a
releases/**-alpha
, comoreleases/beta/3-alpha
(refs/heads/releases/beta/3-alpha
) - Uma marca chamada
v2
(refs/tags/v2
) - Uma marca cujo nome começa com
v1.
, comov1.9
(refs/tags/v1.9
)
on:
push:
# Sequence of patterns matched against refs/heads
branches-ignore:
- 'mona/octocat'
- 'releases/**-alpha'
# Sequence of patterns matched against refs/tags
tags-ignore:
- v2
- v1.*
Exemplo: Incluindo e excluindo branches e tags
Não é possível usar branches
e branches-ignore
para filtrar o mesmo evento em um fluxo de trabalho individual. Da mesma forma, não é possível usar tags
e tags-ignore
para filtrar o mesmo evento em um fluxo de trabalho individual. Caso deseje incluir e excluir padrões de branch para um evento individual, use o filtro branches
ou tags
com o caractere !
para indicar as marcas ou os branches que devem ser excluídos.
Se você definir um branch com o caractere !
, também precisará definir, pelo menos, um branch sem o caractere !
. Caso deseje apenas excluir os branches, use branches-ignore
. Da mesma forma, se você definir uma marca com o caractere !
, também precisará definir, pelo menos, uma marca sem o caractere !
. Caso deseje apenas excluir as marcas, use tags-ignore
.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá a referência do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá a Git ref novamente.
O fluxo de trabalho a seguir será executado em pushes para releases/10
ou releases/beta/mona
, mas não em releases/10-alpha
ou releases/beta/3-alpha
porque o padrão !releases/**-alpha
negativo vem após o padrão positivo.
on:
push:
branches:
- 'releases/**'
- '!releases/**-alpha'
Usando filtros para direcionar caminhos específicos para pull requests uu eventos de push
Ao usar os eventos push
e pull_request
, você pode configurar um fluxo de trabalho para ser executado com base nos caminhos de arquivo alterados. Os filtros de caminho não são avaliados em pushes de tags.
Use o filtro paths
quando quiser incluir padrões de caminho de arquivo ou quando quiser incluir e excluir padrões de caminho de arquivo. Use o filtro paths-ignore
quando quiser apenas excluir padrões de caminho de arquivo. Não é possível usar os filtros paths
e paths-ignore
para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro paths
prefixado o caractere !
para indicar os caminhos que devem ser excluídos.
Note
A ordem de definição dos padrões paths
é importante:
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá o caminho do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.
Se você definir branches
/branches-ignore
e paths
/paths-ignore
, o fluxo de trabalho só será executado quando ambos os filtros forem atendidos.
As palavras-chave paths
e paths-ignore
aceitam padrões glob que usam os caracteres curinga *
e **
para fazer a correspondência com mais de um nome de caminho. Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o GitHub Actions".
Exemplo: Incluindo caminhos
Se, pelo menos, um caminho corresponder a um padrão no filtro paths
, o fluxo de trabalho será executado. Por exemplo, o fluxo de trabalho a seguir será executado sempre que você efetuar push de um arquivo JavaScript (.js
).
on:
push:
paths:
- '**.js'
Você não deverá usar a filtragem de caminho ou ramificação para ignorar execuções de fluxo de trabalho se for necessário passar o fluxo de trabalho antes da mesclagem. Para obter mais informações, confira "Ignorar execuções de fluxo de trabalho" e "Regras disponíveis para conjuntos de regras."
Se um fluxo de trabalho for ignorado devido à filtragem de caminho, à filtragem de ramificação ou a uma mensagem de confirmação, as verificações associadas a esse fluxo de trabalho permanecerão no estado "Pendente". Uma solicitação de pull que exige que essas verificações sejam bem-sucedidas não poderá ser mesclada.
Exemplo: Excluindo caminhos
Quando todos os nomes de caminho corresponderem aos padrões de paths-ignore
, o fluxo de trabalho não será executado. Se qualquer nome de caminho não corresponder aos padrões de paths-ignore
, mesmo que alguns nomes de caminho correspondam aos padrões, o fluxo de trabalho será executado.
Um fluxo de trabalho com o filtro de caminho a seguir só será executado em eventos push
que incluem, pelo menos, um arquivo fora do diretório docs
na raiz do repositório.
on:
push:
paths-ignore:
- 'docs/**'
Exemplo: Incluindo e excluindo caminhos
Não é possível usar paths
e paths-ignore
para filtrar o mesmo evento em um só fluxo de trabalho. Caso deseje incluir e excluir padrões de caminho para um evento individual, use o filtro paths
prefixado o caractere !
para indicar os caminhos que devem ser excluídos.
Se você definir um caminho com o caractere !
, também precisará definir, pelo menos, um caminho sem o caractere !
. Caso você deseje apenas excluir os caminhos, use paths-ignore
.
A ordem de definição dos padrões paths
é importante:
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá o caminho do Git. - Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.
Este exemplo é executado sempre que o evento push
inclui um arquivo no diretório sub-project
ou nos respectivos subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs
. Por exemplo, um push que alterar sub-project/index.js
ou sub-project/src/index.js
vai disparar uma execução de fluxo de trabalho, mas um push que só altera sub-project/docs/readme.md
não.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Comparações Git diff
Note
Se você efetuar push de mais de mil commits ou se o GitHub não gerar a comparação devido a um tempo de espera, o fluxo de trabalho sempre será executado.
O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e executando-os na lista paths-ignore
ou paths
. Se não houver arquivos alterados, o fluxo de trabalho não será executado.
O GitHub gera a lista de arquivos alterados usando diffs de dois pontos para pushes e diffs de três pontos para pull requests:
- Solicitações de pull: as comparações de três pontos são uma comparação entre a versão mais recente do branch do tópico e o commit em que o branch do tópico foi sincronizado pela última vez com o branch base.
- Pushes para branches existentes: uma comparação de dois pontos compara os SHAs principal e base diretamente um com o outro.
- Pushes para novos branches: uma comparação de dois pontos com o pai do ancestral do commit mais profundo enviado por push.
Os diffs limitam-se a 300 arquivos. Se houver arquivos alterados que não correspondam aos primeiros 300 arquivos retornados pelo filtro, o fluxo de trabalho não será executado. Talvez seja necessário criar filtros mais específicos para que o fluxo de trabalho seja executado automaticamente.
Para obter mais informações, confira "Sobre como comparar branches nas pull requests".
Usando filtros para direcionar branches específicos para eventos de execução de fluxo de trabalho
Ao usar o evento workflow_run
, você pode especificar os branches nos quais o fluxo de trabalho de gatilho precisa ser executado para disparar o fluxo de trabalho.
Os filtros branches
e branches-ignore
aceitam padrões glob que usam caracteres como *
, **
, +
, ?
, !
e outros para corresponder a mais de um nome de branch. Se um nome contiver um desses caracteres e você quiser ter uma correspondência literal, faça escape de cada um desses caracteres especiais com \
. Para obter mais informações sobre padrões glob, confira o "Sintaxe de fluxo de trabalho para o GitHub Actions".
Por exemplo, um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build
for executado em um branch cujo nome começa com releases/
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
Um fluxo de trabalho com o seguinte gatilho só será executado quando o fluxo de trabalho chamado Build
for executado em um branch que não seja chamado canary
:
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches-ignore:
- "canary"
Não é possível usar os filtros branches
e branches-ignore
para o mesmo evento em um fluxo de trabalho. Caso deseje incluir e excluir padrões de branch para um só evento, use o filtro branches
com o caractere !
para indicar os branches que devem ser excluídos.
A ordem na qual você define os padrões é importante.
- Um padrão de correspondência negativa (precedido por
!
) após uma correspondência positiva excluirá o branch. - Um padrão positivo correspondente após uma correspondência negativa incluirá o branch novamente.
Por exemplo, um fluxo de trabalho com o gatilho a seguir será executado quando o fluxo de trabalho chamado Build
for executado em um branch chamado releases/10
ou releases/beta/mona
que não será releases/10-alpha
, releases/beta/3-alpha
ou main
.
on:
workflow_run:
workflows: ["Build"]
types: [requested]
branches:
- 'releases/**'
- '!releases/**-alpha'
Definindo entradas para fluxos de trabalho acionados manualmente
Ao usar o evento workflow_dispatch
, opcionalmente, você pode especificar as entradas que são transmitidas para o fluxo de trabalho.
Esse gatilho só recebe eventos quando o arquivo de fluxo de trabalho está na ramificação padrão.
O fluxo de trabalho disparado recebe as entradas no contexto do inputs
. Para obter mais informações, confira "Contextos".
Observações:
- O fluxo de trabalho também receberá as entradas no contexto de
github.event.inputs
. As informações no contextoinputs
e no contextogithub.event.inputs
são idênticas, exceto que o contextoinputs
preserva valores boolianos como boolianos em vez de convertê-los em cadeias de caracteres. O tipochoice
é resolvido para uma cadeia de caracteres e é uma única opção selecionável. - O número máximo de propriedades de nível superior para
inputs
é 10. - O conteúdo máximo para
inputs
é de 65.535 caracteres.
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: ${{ inputs.print_tags }}
steps:
- name: Print the input tag to STDOUT
run: echo The tags are ${{ 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, confira "Reutilizar fluxos de trabalho".
Usando informações do evento
As informações sobre o evento que disparou 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 disparou 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, confira "Eventos e cargas de webhook".
Imprima também o contexto github.event
inteiro para ver quais propriedades estão disponíveis para o evento que disparou 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
Use o contexto github.event
no fluxo de trabalho. Por exemplo, o fluxo de trabalho a seguir é executado quando uma solicitação de pull que altera package*.json
, .github/CODEOWNERS
ou .github/workflows/**
é aberta. Se o autor da solicitação de pull (github.event.pull_request.user.login
) não for octobot
nem dependabot[bot]
, o fluxo de trabalho usará a GitHub CLI para rotular a solicitação de pull e adicionar comentários a ela (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:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
PR: ${{ github.event.pull_request.html_url }}
run: |
gh pr edit $PR --add-label 'invalid'
gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'
Para obter mais informações sobre contextos, confira "Accessing contextual information about workflow runs". Para obter mais informações sobre cargas do evento, confira "Eventos e cargas de webhook".
Controlando ainda mais como seu fluxo de trabalho será executado
Se você quiser um controle mais granular do que o fornecido por eventos, tipos de atividade do evento ou filtros de evento, use condicionais e ambientes para controlar se trabalhos ou etapas individuais serão executados no fluxo de trabalho.
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
Por exemplo, caso você deseje que o fluxo de trabalho seja executado quando um rótulo específico for adicionado a um problema, dispare o tipo de atividade do evento issues labeled
e use um condicional para verificar qual rótulo disparou o fluxo de trabalho. O fluxo de trabalho a seguir será executado quando qualquer rótulo for adicionado a um problema no repositório do fluxo de trabalho, mas o trabalho run_if_label_matches
só será executado se o rótulo for chamado 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 tiver sido executado porque um problema foi fechado, o contexto github.event
conterá um valor para issue
, mas não para pull_request
. Portanto, a etapa if_issue
será executada, mas a etapa if_pr
não. Por outro lado, se o fluxo de trabalho for executado porque uma solicitação de pull foi fechada, 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 as informações que estão disponíveis no contexto do evento, confira "Como usar as informações do evento". Para obter mais informações sobre como usar condicionais, confira "Evaluate expressions in workflows and actions".
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, confira "Gerenciar ambientes para implantação". Em seguida, referencie o nome do ambiente em um trabalho no fluxo de trabalho usando 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 publish
só será executado depois que o trabalho build
for concluído com sucesso (devido a needs: [build]
) e depois de todas as regras (incluindo os revisores obrigatórios) para o ambiente chamado production
forem 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'
Ambientes, segredos de ambiente e regras de proteção de implantação estão disponíveis em repositórios públicos para todos os planos atuais do GitHub. Eles não estão disponíveis em planos herdados, como Bronze, Prata ou Ouro. Para acesso a ambientes, segredos de ambiente e branches de implantação em repositórios privados ou internos, você deve usar GitHub Pro, GitHub Team ou GitHub Enterprise.
Eventos disponíveis
Para obter uma lista completa de eventos disponíveis, confira "Eventos que disparam fluxos de trabalho".