Observação: GitHub Actions estava disponível para GitHub Enterprise Server 2.22 como um beta limitado. O beta terminou. GitHub Actions está agora geralmente disponível em GitHub Enterprise Server 3.0 ou posterior. Para obter mais informações, consulte as observações sobre a versão GitHub Enterprise Server 3.0.
- Para obter mais informações sobre a atualização para GitHub Enterprise Server 3.0 ou posterior, consulte "Atualizar GitHub Enterprise Server".
- Para obter mais informações sobre a configuração de GitHub Actions após atualizar, consulte a documentação para GitHub Enterprise Server 3.0.
Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.
Sobre sintaxe YAML para fluxos de trabalho
Arquivos de fluxo de trabalho usam sintaxe YAML e devem ter uma extensão de arquivo .yml
ou .yaml
. Se você é novo no YAML e deseja aprender mais, consulte "Aprenda YAML em Y minutes".
Você deve armazenar os arquivos de fluxo de trabalho no diretório .github/workflows
do seu repositório.
name
Nome do fluxo de trabalho. O GitHub exibe os nomes dos fluxos de trabalho na página de ações do repositório. Se você omitir o nome
, o GitHub irá defini-lo como o caminho do arquivo do fluxo de trabalho relativo à raiz do repositório.
on
Obrigatório. O nome do evento de GitHub que aciona o fluxo de trabalho. Você pode fornecer uma única string
de evento, um array
de eventos, um array
de types
(tipos) de eventos ou um map
(mapa) de configuração de eventos que programe um fluxo de trabalho ou restrinja a execução do fluxo de trabalho a alterações em determinados arquivos, tags ou branches. Para obter uma lista de eventos disponíveis, consulte "Eventos que acionam fluxos de trabalho".
Exemplo: Usando um único evento
# Triggered when code is pushed to any branch in a repository
on: push
Exemplo: Usando uma lista de eventos
# Triggers the workflow on push or pull request events
on: [push, pull_request]
Exemplo: Usando vários eventos com tipos de atividade ou configuração
Se você precisar especificar tipos de atividade ou configuração para um evento, você deve configurar cada evento separadamente. Você deve anexar dois pontos (:
) a todos os eventos, incluindo eventos sem configuração.
on:
# Trigger the workflow on push or pull request,
# but only for the main branch
push:
branches:
- main
pull_request:
branches:
- main
# Also trigger on page_build, as well as release created events
page_build:
release:
types: # This configuration does not affect the page_build event above
- created
on.<event_name>.types
Seleciona os tipos de atividades que acionarão a execução de um fluxo de trabalho. A maioria dos eventos GitHub são acionados por mais de um tipo de atividade. Por exemplo, o evento para o recurso release (versão) é acionado quando uma versão é published
(publicada), unpublished
(a publicação é cancelada), created
(criada), edited
(editada), deleted
(excluída) ou prereleased
(versão prévia). A palavra-chave types
(tipos) permite que você limite a atividade que faz com que o fluxo de trabalho seja executado. Quando somente um tipo de atividade aciona um evento de webhook, a palavra-chave types
(tipos) é desnecessária.
É possível usar um array de types
(tipos) de evento. Para obter mais informações sobre cada evento e seus tipos de atividades, consulte "Eventos que acionam fluxos de trabalho".
# Trigger the workflow on release activity
on:
release:
# Only use the types keyword to narrow down the activity types that will trigger your workflow.
types: [published, created, edited]
on.<push|pull_request>.<branches|tags>
Ao usar os eventos push
e pull_request
, é possível configurar um fluxo de trabalho para ser executado em branches ou tags específicos. Para um evento de pull_request
, são avaliados apenas os branches e tags na base. Se você definir apenas tags
ou branches
, o fluxo de trabalho não será executado para eventos que afetam o Git ref indefinido.
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, definir o padrão mona/octocat
nos branches
corresponde ao Git ref refs/heads/mona/octocat
. O padrão releases/**
corresponderá ao Git ref refs/heads/releases/10
.
on:
push:
# Sequence of patterns matched against refs/heads
branches:
# Push events on main branch
- main
# Push events to branches matching refs/heads/mona/octocat
- 'mona/octocat'
# Push events to branches matching refs/heads/releases/10
- 'releases/**'
# Sequence of patterns matched against refs/tags
tags:
- v1 # Push events to v1 tag
- v1.* # Push events to v1.0, v1.1, and v1.9 tags
Exemplo: Ignorando branches e tags
Sempre que um padrão corresponde ao padrão branches-ignore
ou tags-ignore
, o fluxo de trabalho não será executado. Os padrões definidos em branches-ignore
e tags-ignore
são avaliados relativamente ao nome do Git ref. Por exemplo, definir o padrão mona/octocat
nos branches
corresponde ao Git ref refs/heads/mona/octocat
. O padrão releases/**-alpha
em branches
corresponderá ao Git ref refs/releases/beta/3-alpha
.
on:
push:
# Sequence of patterns matched against refs/heads
branches-ignore:
# Do not push events to branches matching refs/heads/mona/octocat
- 'mona/octocat'
# Do not push events to branches matching refs/heads/releases/beta/3-alpha
- 'releases/**-alpha'
# Sequence of patterns matched against refs/tags
tags-ignore:
- v1.* # Do not push events to tags v1.0, v1.1, and v1.9
Excluir branches e tags
Você pode usar dois tipos de filtros para impedir a execução de um fluxo de trabalho em pushes e pull requests para tags e branches.
branches
oubranches-ignore
- não é possível usar os dois filtrosbranches
ebranches-ignore
para o mesmo evento em um fluxo de trabalho. Use o filtrobranches
quando você precisa filtrar branches para correspondências positivas e excluir branches. Use o filtrobranches-ignore
quando você só precisa excluir nomes de branches.tags
outags-ignore
- não é possível usar os dois filtrostags
etags-ignore
para o mesmo evento em um fluxo de trabalho. Use o filtrotags
quando você precisa filtrar tags para correspondências positivas e excluir tags. Use o filtrotags-ignore
quando você só precisa excluir nomes de tags.
Exemplo: Usando padrões positivos e negativos
Você pode excluir tags
e branches
usando o caractere !
. 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'
on.<push|pull_request>.paths
Ao usar os eventos push
e pull_request
, é possível configurar um fluxo de trabalho para ser executado quando pelo menos um arquivo não corresponde a paths-ignore
ou pelo menos um arquivo modificado corresponde ao paths
configurado. Flitros de caminho não são avaliados em pushes para tags.
As palavras-chave paths-ignore
e paths
aceitam padrões 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: Ignorando caminhos
Quando todos os caminhos de nome correspondem a padrões em paths-ignore
, o fluxo de trabalho não será executado. O GitHub avalia os padrões definidos em paths-ignore
com relação ao nome do caminho. 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 caminhos
Se pelo menos um caminho corresponder a um padrão no filtro paths
, o fluxo de trabalho será executado. Para acionar uma compilação sempre que você fizer push de um arquivo JavaScript, você pode usar um padrão curinga.
on:
push:
paths:
- '**.js'
Excluir caminhos
Você pode excluir caminhos com dois tipos de filtros. Não é possível usar ambos os filtros para o mesmo evento em um fluxo de trabalho.
paths-ignore
- use o filtropaths-ignore
quando você precisa somente excluir nomes de caminhos.paths
- use o filtropaths
quando você precisa filtrar caminhos para correspondências positivas e excluir caminhos.
Exemplo: Usando padrões positivos e negativos
Você pode excluir paths
usando o caractere !
. A ordem de definição dos padrões é importante:
- Um padrão negativo (precedido por
!
) depois de uma correspondência positiva excluirá o caminho. - Um padrão positivo correspondente após uma correspondência negativa incluirá o caminho novamente.
Este exemplo é executado sempre que o evento push
inclui um arquivo no diretório sub-project
ou seus subdiretórios, a menos que o arquivo esteja no diretório sub-project/docs
. Por exemplo, um push que alterou sub-project/index.js
ou sub-project/src/index.js
acionará uma execução de fluxo de trabalho, mas um push que altere somentesub-project/docs/readme.md
não acionará.
on:
push:
paths:
- 'sub-project/**'
- '!sub-project/docs/**'
Comparações Git diff
Observação: Se você fizer push de mais de 1.000 commits, ou se GitHub não gerar o diff devido a um tempo limite, o fluxo de trabalho sempre será executado.
O filtro determina se um fluxo de trabalho deve ser executado avaliando os arquivos alterados e comparando-os à lista de paths-ignore
ou paths
. Se não houver arquivos alterados, o fluxo de trabalho não será executado.
O GitHub gera a lista de arquivos alterados usando diffs de dois pontos para pushes e diffs de três pontos para pull requests:
- Pull requests: diffs de três pontos são uma comparação entre a versão mais recente do branch de tópico e o commit onde o branch de tópico foi sincronizado pela última vez com o branch de base.
- Pushes para branches existentes: um diff de dois pontos compara os SHAs head e base, um com o outro.
- Pushes para novos branches: um diff de dois pontos compara o principal do ancestral do commit mais extenso que foi feito push.
Os diffs limitam-se a 300 arquivos. Se houver arquivos alterados que não correspondam aos primeiros 300 arquivos retornados pelo filtro, o fluxo de trabalho não será executado. Talvez seja necessário criar filtros mais específicos para que o fluxo de trabalho seja executado automaticamente.
Para obter mais informações, consulte "Sobre comparação de branches em pull requests".
on.workflow_dispatch.inputs
Ao usar o evento workflow_dispatch
, você pode, opcionalmente, especificar as entradas que são passadas para o fluxo de trabalho. As entradas de fluxo de trabalho são especificadas no mesmo formato que as entradas de ações. Para obter mais informações sobre o formato, consulte "Sintaxe de Metadados para o GitHub Actions".
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
tags:
description: 'Test scenario tags'
required: false
O fluxo de trabalho acionado recebe as entradas no contexto github.event.inputs
. Para obter mais informações, consulte "Contextos".
on.schedule
É possível programar um fluxo de trabalho para ser executado em horários de UTC específicos usando a sintaxe de 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 programados é uma vez 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 * * *'
Para obter mais informações sobre a sintaxe cron, consulte "Eventos que acionam fluxos de trabalho".
env
Um mapa
das variáveis de ambiente que estão disponíveis para as etapas de todos os trabalhos do fluxo de trabalho. Também é possível definir variáveis de ambiente que estão disponíveis apenas para as etapas de um único trabalho ou para uma única etapa. Para obter mais informações, consulte jobs.<job_id>.env
e jobs.<job_id>.steps[*].env
.
Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.
Exemplo
env:
SERVER: production
padrões
Um mapa
das configurações-padrão que serão aplicadas a todos os trabalhos do fluxo de trabalho. Você também pode definir as configurações-padrão disponíveis para um trabalho. Para obter mais informações, consulte jobs.<job_id>.defaults
.
Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.
defaults.run
Você pode fornecer opções-padrão de shell
e working-directory
para todas as etapas de executar
em um fluxo de trabalho. Você também pode definir as configurações-padrão para execução
apenas disponíveis para um trabalho. Para obter mais informações, consulte jobs.<job_id>.defaults.run
. Você não pode usar contextos ou expressões nesta palavra-chave.
Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.
Exemplo
defaults:
run:
shell: bash
working-directory: scripts
jobs
A execução de um fluxo de trabalho consiste em um ou mais trabalhos. Por padrão, os trabalhos são executados paralelamente. Para executar trabalhos sequencialmente, você pode definir dependências em outros trabalhos usando a palavra-chave jobs.<job_id>.needs
.
Cada trabalho é executado em um ambiente de executor especificado por runs-on
.
Você pode executar quantos trabalhos desejar, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte "Limites de uso e cobrança" para executores hospedados em GitHub e "Sobre executores auto-hospedados" para limites de uso de executores auto-hospedados.
Se você precisar encontrar o identificador exclusivo de um trabalho e execução em um fluxo de trabalho, você poderá usar a API GitHub. Para obter mais informações, consulte "Trabalhos do fluxo de trabalho".
jobs.<job_id>
Cada trabalho deve ter um id associado. A chave job_id
é uma string, e seu valor é um mapa dos dados de configuração do trabalho. Você deve substituir <job_id>
por uma string exclusiva para o objeto jobs
. <job_id>
deve começar por uma letra ou _
, além de conter somente caracteres alfanuméricos, -
ou _
.
Exemplo
jobs:
my_first_job:
name: My first job
my_second_job:
name: My second job
jobs.<job_id>.name
Nome do trabalho no GitHub.
jobs.<job_id>.needs
Identifica todos os trabalhos a serem concluídos com êxito antes da execução deste trabalho. Esse código pode ser uma string ou array de strings. Se houver falha em um trabalho, todos os trabalhos que dependem dele serão ignorados, a menos que os trabalhos usem uma expressão condicional que faça o trabalho continuar.
Exemplo: Exigindo que trabalhos dependentes sejam bem-sucedidos
jobs:
job1:
job2:
needs: job1
job3:
needs: [job1, job2]
Neste exemplo, job1
deve ser concluído com êxito antes do início de job2
, e job3
aguarda a conclusão de job1
e job2
.
Os trabalhos neste exemplo são executados sequencialmente:
job1
job2
job3
Exemplo: Não exigindo que os trabalhos dependentes sejam bem-sucedidos
jobs:
job1:
job2:
needs: job1
job3:
if: always()
needs: [job1, job2]
Neste exemplo, job3
usa a expressão condicional always()
para que ela sempre seja executada depois de job1
e job2
terem sido concluídos, independentemente de terem sido bem sucedidos. Para obter mais informações, consulte "Expressões".
jobs.<job_id>.runs-on
Obrigatório. O tipo de máquina na qual se executa o trabalho. A máquina pode ser ou um executor hospedado em GitHub ou um executor auto-hospedado.
Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.
Runners hospedados no GitHub
Se você usar um executor hospedado no GitHub, cada trabalho será executado em uma nova instância de um ambiente virtual especificado por runs-on
.
Os tipos de executor disponíveis para GitHub são:
Ambiente virtual | Etiqueta de fluxo de trabalho YAML | Observações |
---|---|---|
Windows Server 2022[beta] | windows-2022 |
The windows-latest label currently uses the Windows Server 2019 runner image.
|
Windows Server 2019 | windows-latest ou windows-2019 |
|
Windows Server 2016 | windows-2016 |
|
Ubuntu 20.04 | ubuntu-latest ou ubuntu-20.04 |
|
Ubuntu 18.04 | ubuntu-18.04 |
|
macOS Big Sur 11 | macos-11 |
The macos-latest label currently uses the macOS 10.15 runner image.
|
macOS Catalina 10.15 | macos-latest or macos-10.15 |
Note: Beta Images are provided "as-is", "with all faults" and "as available" and are excluded from the service level agreement and warranty. Beta Images may not be covered by customer support.
Exemplo
runs-on: ubuntu-latest
Para obter mais informações, consulte "Ambientes virtuais para executores hospedados em GitHub".
Executores auto-hospedados
Para especificar um executor auto-hospedado para o seu trabalho, configure runs-on
no seu arquivo de fluxo de trabalho com etiquetas de executores auto-hospedados.
All self-hosted runners have the self-hosted
label. Using only this label will select any self-hosted runner. To select runners that meet certain criteria, such as operating system or architecture, provide an array of labels that begins with self-hosted
(this must be listed first) and then includes additional labels as needed.
Exemplo
runs-on: [self-hosted, linux]
Para obter mais informações, consulte "Sobre executores auto-hospedados" e "Usar executores auto-hospedados em um fluxo de trabalho."
jobs.<job_id>.outputs
Um mapa
de saídas para um trabalho. As saídas de trabalho estão disponíveis para todos os trabalhos downstream que dependem deste trabalho. Para obter mais informações sobre a definição de dependências de trabalhos, consulte jobs.<job_id>.needs
.
As saídas de trabalho são strings e saídas de trabalho que contêm expressões são avaliadas no executor ao final de cada trabalho. As saídas que contêm segredos são eliminadas no executor e não são enviadas para GitHub Actions.
Para usar as saídas de trabalho em um trabalho dependente, você poderá usar o contexto needs
. Para obter mais informações, consulte "Contextos".
Exemplo
jobs:
job1:
runs-on: ubuntu-latest
# Map a step output to a job output
outputs:
output1: ${{ steps.step1.outputs.test }}
output2: ${{ steps.step2.outputs.test }}
steps:
- id: step1
run: echo "::set-output name=test::hello"
- id: step2
run: echo "::set-output name=test::world"
job2:
runs-on: ubuntu-latest
needs: job1
steps:
- run: echo ${{needs.job1.outputs.output1}} ${{needs.job1.outputs.output2}}
jobs.<job_id>.env
Um map
(mapa) das variáveis de ambiente que estão disponíveis para todos as etapas do trabalho. Também é possível definir variáveis de ambiente para todo o fluxo de trabalho ou uma etapa individual. Para obter mais informações, consulte env
e jobs.<job_id>.steps[*].env
.
Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.
Exemplo
jobs:
job1:
env:
FIRST_NAME: Mona
jobs.<job_id>.defaults
Um mapa
com as configurações- padrão que serão aplicadas a todas as etapas do trabalho. Você também pode definir as configurações-padrão para todo o fluxo de trabalho. Para obter mais informações, consulte padrão
.
Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.
jobs.<job_id>.defaults.run
Forneça o shell
e working-directory
para todas as etapas do trabalho executar
. Não são permitidos contexto e expressão nesta seção.
Você pode fornecer as opções-padrão de shell
e working-directory
para todas as etapas de execução
de um trabalho. Você também pode definir as configurações-padrão para execução
para todo o fluxo de trabalho. Para obter mais informações, consulte jobs.defaults.run
. Você não pode usar contextos ou expressões nesta palavra-chave.
Quando mais de uma configuração padrão é definida com o mesmo nome, GitHub usa a configuração padrão mais específica. Por exemplo, uma configuração padrão definida em uma tarefa irá substituir uma configuração padrão que tem o mesmo nome definido em um fluxo de trabalho.
Exemplo
jobs:
job1:
runs-on: ubuntu-latest
defaults:
run:
shell: bash
working-directory: scripts
jobs.<job_id>.if
Você pode usar a condicional if
(se) para evitar que um trabalho seja executado a não ser que determinada condição seja atendida. Você pode usar qualquer contexto e expressão compatível para criar uma condicional.
Quando você usa expressões em uma condicional if
você pode omitir a sintaxe da expressão (${{ }}
) porque GitHub calcula automaticamente a condição if
como expressão. Para obter mais informações, consulte "Expressões".
jobs.<job_id>.steps
Trabalhos contêm sequências de tarefas chamadas steps
. As etapas podem executar comandos, executar trabalhos de configuração ou executar ações no seu repositório, em repositórios públicos, ou ações publicadas em registros do Docker. Nem todas as etapas executam ações, mas todas as ações são executadas como etapas. Cada etapa é executada em seu próprio processo no ambiente do executor, tendo acesso ao espaço de trabalho e ao sistema de arquivos. Como as etapas são executadas em seus próprios processos, as alterações nas variáveis de ambiente não são preservadas entre as etapas. O GitHub fornece etapas integradas para configurar e concluir trabalhos.
Você pode executar quantas etapas quiser, desde que esteja dentro dos limites de uso do fluxo de trabalho. Para obter mais informações, consulte "Limites de uso e cobrança" para executores hospedados em GitHub e "Sobre executores auto-hospedados" para limites de uso de executores auto-hospedados.
Exemplo
name: Greeting from Mona
on: push
jobs:
my-job:
name: My Job
runs-on: ubuntu-latest
steps:
- name: Print a greeting
env:
MY_VAR: Hi there! My name is
FIRST_NAME: Mona
MIDDLE_NAME: The
LAST_NAME: Octocat
run: |
echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.
jobs.<job_id>.steps[*].id
Identificador exclusivo da etapa. Você pode usar id
para fazer referência à etapa em contextos. Para obter mais informações, consulte "Contextos".
jobs.<job_id>.steps[*].if
Você pode usar a condicional if
(se) para evitar que uma etapa trabalho seja executada a não ser que determinada condição seja atendida. Você pode usar qualquer contexto e expressão compatível para criar uma condicional.
Quando você usa expressões em uma condicional if
você pode omitir a sintaxe da expressão (${{ }}
) porque GitHub calcula automaticamente a condição if
como expressão. Para obter mais informações, consulte "Expressões".
Exemplo: Usando contextos
Essa etapa somente é executada quando o tipo de evento é uma pull_request
e a ação do evento é unassigned
(não atribuída).
steps:
- name: My first step
if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
run: echo This event is a pull request that had an assignee removed.
Exemplo: Usando funções de verificação de status
A função my backup step
(minha etapa de backup) somente é executada quando houver falha em uma etapa anterior do trabalho. Para obter mais informações, consulte "Expressões".
steps:
- name: My first step
uses: octo-org/action-name@main
- name: My backup step
if: ${{ failure() }}
uses: actions/heroku@1.0.0
jobs.<job_id>.steps[*].name
Nome da etapa no GitHub.
jobs.<job_id>.steps[*].uses
Seleciona uma ação para executar como parte de uma etapa no trabalho. A ação é uma unidade reutilizável de código. Você pode usar uma ação definida no mesmo repositório que o fluxo de trabalho, um repositório público ou em uma imagem publicada de contêiner Docker.
É altamente recomendável incluir a versão da ação que você está usando ao especificar um número de tag Docker, SHA ou ref do Git. Se você não especificar uma versão, ela poderá interromper seus fluxos de trabalho ou causar um comportamento inesperado quando o proprietário da ação publicar uma atualização.
- Usar o commit SHA de uma versão de ação lançada é a maneira mais garantida de obter estabilidade e segurança.
- Usar a versão principal da ação permite receber correções importantes e patches de segurança sem perder a compatibilidade. Fazer isso também garante o funcionamento contínuo do fluxo de trabalho.
- Usar o branch-padrão de uma ação pode ser conveniente, mas se alguém lançar uma nova versão principal com uma mudança significativa, seu fluxo de trabalho poderá ter problemas.
Algumas ações requerem entradas que devem ser definidas com a palavra-chave with
(com). Revise o arquivo README da ação para determinar as entradas obrigatórias.
Ações são arquivos JavaScript ou contêineres Docker. Se a ação em uso for um contêiner do Docker, você deverá executar o trabalho em um ambiente do Linux. Para obter mais detalhes, consulte runs-on
.
Exemplo: Usando ações de versão
steps:
# Reference a specific commit
- uses: actions/checkout@a81bbbf8298c0fa03ea29cdc473d45769f953675
# Reference the major version of a release
- uses: actions/checkout@v2
# Reference a specific version
- uses: actions/checkout@v2.2.0
# Reference a branch
- uses: actions/checkout@main
Exemplo: Usando uma ação pública
{owner}/{repo}@{ref}
É possível especificar um branch, ref, ou SHA em um repositório público de GitHub.
jobs:
my_first_job:
steps:
- name: My first step
# Uses the default branch of a public repository
uses: actions/heroku@main
- name: My second step
# Uses a specific version tag of a public repository
uses: actions/aws@v2.0.1
Exemplo: Usando uma ação pública em um subdiretório
{owner}/{repo}/{path}@{ref}
Subdiretório em um repositório público do GitHub em um branch, ref ou SHA específico.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/aws/ec2@main
Exemplo: Usando uma ação no mesmo repositório que o fluxo de trabalho
./path/to/dir
Caminho para o diretório que contém a ação no repositório do seu fluxo de trabalho. Você deve reservar seu repositório antes de usar a ação.
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
- name: Use local my-action
uses: ./.github/actions/my-action
Exemplo: Usando uma ação do Docker Hub
docker://{image}:{tag}
Imagem Docker publicada no Docker Hub.
empregos:
my_first_job:
passos:
- nome: Meu primeiro passo
usa: docker://alpine:3.8
Exemplo: Usando uma ação do registro público do Docker
docker://{host}/{image}:{tag}
Imagem Docker em um registro público. Este exemplo usa o Registro de Contêiner do Google em gcr.io
.
jobs:
meu_primeiro_trabalho:
steps:
- name: minha primeira etapa
uses: docker://gcr.io/cloud-builders/gradle
Exemplo: Usando uma ação dentro de um repositório privado diferente do fluxo de trabalho
Seu fluxo de trabalho deve fazer checkout no repositório privado e referenciar a ação localmente. Gere um token de acesso pessoal e adicione o token como um segredo criptografado. Para obter mais informações, consulte "Criar um token de acesso pessoal" e "Segredos criptografados".
Substitua PERSONAL_ACCESS_TOKEN
no exemplo pelo nome do seu segredo.
jobs:
my_first_job:
steps:
- name: Check out repository
uses: actions/checkout@v2
with:
repository: octocat/my-private-repo
ref: v1.0
token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
path: ./.github/actions/my-private-repo
- name: Run my action
uses: ./.github/actions/my-private-repo/my-action
jobs.<job_id>.steps[*].run
Executa programas de linha de comando usando o shell do sistema operacional. Se você não informar um name
, o nome da etapa será configurado por padrão como o texto indicado no comando run
.
Por padrão, os comandos run usam shells de não login. Você pode escolher um shell diferente e personalizar o shell usado para executar comandos. Para obter mais informações, consulte "Usar um shell específico".
Cada palavra-chave run
representa um novo processo e shell no ambiente do executor. Quando você fornece comandos de várias linhas, cada linha será executada no mesmo shell. Por exemplo:
-
Um comando de linha única:
- name: Install Dependencies run: npm install
-
Um comando de várias linhas:
- name: Clean install dependencies and build run: | npm ci npm run build
Com a palavra-chave working-directory
(diretório de trabalho), é possível especificar o diretório de trabalho de onde o comando será executado.
- name: Clean temp directory
run: rm -rf *
working-directory: ./temp
Usar um shell específico
Você pode anular as configurações padrão de shell no sistema operacional do executor usando a palavra-chave shell
. É possível usar palavras-chave integradas a shell
ou definir um conjunto personalizado de opções de shell. O comando do shell executado internamente executa um arquivo temporário que contém os comandos especificados na palavra-chave run
.
Plataforma compatível | Parâmetro shell | Descrição | Comando executado internamente |
---|---|---|---|
Todas | bash | O shell padrão em plataformas que não sejam Windows como uma alternativa para sh . Ao especificar um shell bash no Windows, é utilizado o shell bash incluído no Git para Windows. | bash --noprofile --norc -eo pipefail {0} |
Todas | pwsh | Powershell Core. O GitHub anexa a extensão .ps1 ao nome do script. | pwsh -command ". '{0}'" |
Todas | python | Executa o comando python. | python {0} |
Linux / macOS | sh | Comportamento alternativo para plataformas que não sejam Windows se nenhum shell for fornecido e o bash não for encontrado no caminho. | sh -e {0} |
Windows | cmd | O GitHub anexa a extensão .cmd ao nome do script e a substitui por {0} . | %ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}"" . |
Windows | pwsh | Essa é a shell padrão usada no Windows. Powershell Core. O GitHub anexa a extensão .ps1 ao nome do script. Se o seu executor do Windows auto-hospedado não tiver o PowerShell Core instalado, será usado o PowerShell Desktop. | pwsh -command ". '{0}'" . |
Windows | powershell | O PowerShell Desktop. O GitHub anexa a extensão .ps1 ao nome do script. | powershell -command ". '{0}'" . |
Exemplo: Executando um script usando o bash
steps:
- name: Display the path
run: echo $PATH
shell: bash
Exemplo: Executando um script usando cmd
do Windows
steps:
- name: Display the path
run: echo %PATH%
shell: cmd
Exemplo: Executando um script usando PowerShell Core
steps:
- name: Display the path
run: echo ${env:PATH}
shell: pwsh
Exemplo: Usar o PowerShell Desktop para executar um script
steps:
- name: Display the path
run: echo ${env:PATH}
shell: powershell
Exemplo: Executando um script do Python
steps:
- name: Display the path
run: |
import os
print(os.environ['PATH'])
shell: python
Shell personalizado
Você pode usar o valor shell
em um string modelo usando command […options] {0} [..more_options]
. O GitHub interpreta a primeira palavra da string delimitada por um espaço em branco como o comando e insere o nome do arquivo para o script temporário em {0}
.
Por exemplo:
steps:
- name: Display the environment variables and their values
run: |
print %ENV
shell: perl {0}
O comando usado, perl
neste exemplo, deve ser instalado no executor.
Para informações sobre o software incluído nos executores hospedados no GitHub, consulte "Especificações para os executores hospedados no GitHub."
Preferências de ação de erro e códigos de saída
Para palavras-chave de shell integradas, fornecemos os seguintes padrões usados por executores hospedados no GitHub. Você deve seguir estas diretrizes quando executar scripts shell.
-
bash
/sh
:- Comportamento de falha rápido que usa
set -eo pipefail
: Padrão parabash
eshell
embutido. Também é o padrão quando você não der opção em plataformas que não sejam Windows. - Você pode cancelar o fail-fast e assumir o controle fornecendo uma string de modelo para as opções do shell. Por exemplo,
bash {0}
. - Shells do tipo sh saem com o código de saída do último comando executado em um script, que também é o comportamento padrão das ações. O executor relatará o status da etapa como falha/êxito com base nesse código de saída.
- Comportamento de falha rápido que usa
-
powershell
/pwsh
- Comportamento fail-fast quando possível. Para shell integrado
pwsh
epowershell
, precederemos$ErrorActionPreference = 'stop'
para conteúdos de script. - Vincularemos
if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }
a scripts powershell para que os status da ação reflitam o código de saída mais recente do script. - Os usuários podem sempre optar por não usar o shell integrado e fornecer uma opção personalizada, como:
pwsh -File {0}
oupowershell -Command "& '{0}'"
, dependendo da situação.
- Comportamento fail-fast quando possível. Para shell integrado
-
cmd
- Parece não haver uma forma de optar totalmente por um comportamento fail-fast que não seja gravar seu script para verificar cada código de erro e reagir de acordo. Como não podemos fornecer esse comportamento por padrão, você precisa gravá-lo em seu script.
cmd.exe
sairá com o nível de erro do último programa que executou e retornará o código de erro para o executor. Este comportamento é internamente consistente o padrão de comportamento anteriorsh
epwsh
, e é o padrãocmd.exe
; portanto, ele fica intacto.
jobs.<job_id>.steps[*].with
Um map
(mapa) dos parâmetros de entrada definidos pela ação. Cada parâmetro de entrada é um par chave/valor. Parâmetros de entrada são definidos como variáveis de ambiente. A variável é precedida por INPUT_
e convertida em letras maiúsculas.
Exemplo
Define os três parâmetros de entrada (first_name
, middle_name
e last_name
) definidos pela ação hello_world
. Essas variáveis de entrada estarão acessíveis para a ação hello-world
como variáveis de ambiente INPUT_FIRST_NAME
, INPUT_MIDDLE_NAME
e INPUT_LAST_NAME
.
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/hello_world@main
with:
first_name: Mona
middle_name: The
last_name: Octocat
jobs.<job_id>.steps[*].with.args
Uma string
que define as entradas para um contêiner Docker. O GitHub entrega os args
ao ENTRYPOINT
do contêiner quando o contêiner inicia. Um array de strings
não é compatível com esse parâmetro.
Exemplo
steps:
- name: Explain why this job ran
uses: octo-org/action-name@main
with:
entrypoint: /bin/echo
args: The ${{ github.event_name }} event triggered this step.
args
são usados em substituição à instrução CMD
em um Dockerfile
. Se você usar CMD
no Dockerfile
, use as diretrizes ordenadas por preferência:
- Documente os argumentos necessários no README das ações e omita-os da instrução
CMD
. - Use padrões que permitam o uso da ação sem especificação de
args
. - Se a ação expõe um sinalizador
--help
ou similar, use isso como padrão para que a ação se documente automaticamente.
jobs.<job_id>.steps[*].with.entrypoint
Anula o ENTRYPOINT
Docker no Dockerfile
ou define-o caso ainda não tenha sido especificado. Diferentemente da instrução Docker ENTRYPOINT
que tem um formulário shell e exec, a palavra-chave entrypoint
aceita apena uma única string que define o executável.
Exemplo
steps:
- name: Run a custom command
uses: octo-org/action-name@main
with:
entrypoint: /a/different/executable
A palavra-chave entrypoint
é para ser usada com ações de contêiner Docker, mas você também pode usá-la com ações JavaScript que não definem nenhuma entrada.
jobs.<job_id>.steps[*].env
Define variáveis de ambiente para etapas a serem usadas no ambiente do executor. Também é possível definir variáveis de ambiente para todo o fluxo de trabalho ou para um trabalho. Para obter mais informações, consulte env
e jobs.<job_id>.env
.
Quando mais de uma variável de ambiente é definida com o mesmo nome, GitHub usa a variável de ambiente mais específica. Por exemplo, uma variável de ambiente definida em uma etapa substituirá variáveis de trabalho e de fluxo de trabalho pelo mesmo nome enquanto a etapa é executada. Uma variável definida para um trabalho substituirá uma variável de fluxo de trabalho com o mesmo nome, enquanto o trabalho é executado.
Ações públicas podem especificar variáveis de ambiente esperadas no arquivo LEIAME. Se você está configurando um segredo em uma variável de ambiente, use o contexto secrets
. Para obter mais informações, consulte "Usando variáveis de ambiente" e "Contextos".
Exemplo
steps:
- name: minha primeira ação
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
FIRST_NAME: Mona
LAST_NAME: Octocat
jobs.<job_id>.steps[*].continue-on-error
Impede a falha de um trabalho se uma etapa não funcionar. Defina true
(verdadeiro) para permitir que um trabalho aconteça quando essa etapa falhar.
jobs.<job_id>.steps[*].timeout-minutes
Número máximo de minutos para executar a etapa antes de interromper o processo.
jobs.<job_id>.timeout-minutes
Número máximo de minutos para permitir a execução de um trabalho o antes que o GitHub o cancele automaticamente. Padrão: 360
Se o tempo-limite exceder o tempo limite de execução do trabalho para o runner, o trabalho será cancelada quando o tempo limite de execução for atingido. Para obter mais informações sobre limites de tempo de execução do trabalho, consulte "Limites de uso, cobrança e administração".
jobs.<job_id>.strategy
Estratégias criam matrizes de compilação para os trabalhos. Você pode definir variações diferentes variações nas quais executar os trabalhos.
jobs.<job_id>.strategy.matrix
Você pode definir uma matriz de diferentes configurações de trabalho. Uma matriz permite que você crie vários trabalhos que realizam a substituição de variável em uma definição de trabalho único. Por exemplo, você pode usar uma matriz para criar trabalhos para mais de uma versão compatível de uma linguagem de programação, sistema operacional ou ferramenta. Uma matriz reutiliza a configuração do trabalho e cria trabalho para cada matriz que você configurar.
Uma matriz de tarefas pode gerar 256 tarefas no máximo por execução do fluxo de trabalho. Este limite também se aplica a executores auto-hospedados.
Cada opção que você define na matriz
tem uma chave e um valor. As chaves que você define tornam-se propriedades no contexto da matriz
e você pode fazer referência à propriedade em outras áreas do seu arquivo de fluxo de trabalho. Por exemplo, se você definir a chave os
que contém um array de sistemas operacionais, você poderá usar a propriedade matrix.os
como o valor da palavra-chave runs-on
para criar um trabalho para cada sistema operacional. Para obter mais informações, consulte "Contextos".
A ordem que você define uma matriz
importa. A primeira opção que você definir será a primeira que será executada no seu fluxo de trabalho.
Exemplo: Executando várias versões do Node.js
Você pode especificar uma matriz ao fornecer um array para as opções de configuração. Por exemplo, se o executor for compatível com as versões 10, 12 e 14 do Node.js versões, você poderá especificar um array dessas versões na matriz
.
Este exemplo cria uma matriz de três trabalhos, definindo a chave nó
para um array de três versões do Node.js. Para usar a matriz, o exemplo define a propriedade do contexto matrix.node
como o valor do parâmetro setup-node
de entrada da ação node-version
. Como resultado, três trabalhos serão executados, cada uma usando uma versão diferente do Node.js.
strategy:
matrix:
node: [10, 12, 14]
steps:
# Configures the node version used on GitHub-hosted runners
- uses: actions/setup-node@v2
with:
# The Node.js version to configure
node-version: ${{ matrix.node }}
A ação setup-node ` é a forma recomendada de configurar uma versão do Node.js ao usar executores hospedados em GitHub. Para obter mais informações, consulte a ação [
setup-node`](https://github.com/actions/setup-node).
Exemplo: Executando com vários sistemas operacionais
Você pode criar uma matriz para executar fluxos de trabalho em mais de um sistema operacional do executor. Você também pode especificar mais de uma configuração da matriz. Este exemplo cria uma matriz de 6 trabalhos:
- 2 sistemas operacionais especificados na array
os
- 3 versões do Node.js especificadas na array do
nó
Ao definir uma matriz de sistemas operacionais, você deve definir o valor de runs-on
para a propriedade de contexto de matrix.os
que você definiu.
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-18.04, ubuntu-20.04]
node: [10, 12, 14]
steps:
- uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node }}
Para encontrar opções de configuração compatíveis com executores hospedados em GitHub, consulte "Ambientes virtuais para executores hospedados em GitHub."
Exemplo: Incluindo valores adicionais em combinações
Você pode adicionar opções de configurações para um trabalho de matriz de compilação existente. Por exemplo, se você quer usar uma versão específica do npm
quando o trabalho que usa o windows-latest
e a versão 8 do nó
é executado, você pode usar incluir
para especificar a opção adicional.
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
include:
# includes a new variable of npm with a value of 6
# for the matrix leg matching the os and version
- os: windows-latest
node: 8
npm: 6
Exemplo: Incluindo novas combinações
Você pode usar incluir
para adicionar novos trabalhos a uma matriz de criação. Qualquer configuração sem correspondência de incluir será adicionadas à matriz. Por exemplo, se você quiser usar a versão 14 do nó
para compilar em vários sistemas operacionais, mas quiser uma tarefa experimental extra usando o node 15 no Ubuntu, você poderá usar incluir
para especificar essa tarefa adicional.
runs-on: ${{ matrix.os }}
strategy:
matrix:
node: [14]
os: [macos-latest, windows-latest, ubuntu-18.04]
include:
- node: 15
os: ubuntu-18.04
experimental: true
Exemplo: Excluindo configurações de uma matriz
Você pode remover uma configuração específica definida na matriz de compilação usando a opção exclude
(excluir). exclude
remove um trabalho definido pela matriz de compilação. O número de trabalhos é o produto cruzado do número de sistemas operacionais (os
) incluídos nos arrays fornecidos por você, menos quaisquer subtrações (exclude
).
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [macos-latest, windows-latest, ubuntu-18.04]
node: [8, 10, 12, 14]
exclude:
# excludes node 8 on macOS
- os: macos-latest
node: 8
Observação: Todas as combinações de incluir
são processadas depois de excluir
. Isso permite que você use incluir
para voltar a adicionar combinações que foram excluídas anteriormente.
Usando variáveis de ambiente em uma matriz
Você pode adicionar variáveis de ambiente personalizadas para cada combinação de testes usando a chave include
. Em seguida, você pode se referir às variáveis de ambiente personalizadas em um passo posterior.
Neste exemplo, as entradas da matriz de node-version
são configuradas para usar valores diferentes para as variáveis de ambiente do site
e dos centros de dados
. Em seguida, a etapa de Echo site details
usa env: ${{ matrix.env }}
para referir-se às variáveis personalizadas:
name: Node.js CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
include:
- node-version: 10.x
site: "prod"
datacenter: "site-a"
- node-version: 12.x
site: "dev"
datacenter: "site-b"
steps:
- name: Echo site details
env:
SITE: ${{ matrix.site }}
DATACENTER: ${{ matrix.datacenter }}
run: echo $SITE $DATACENTER
jobs.<job_id>.strategy.fail-fast
Quando definido como true
, o GitHub cancela todos os trabalhos em andamento em caso de falha de algum trabalho de matrix
. Padrão: true
jobs.<job_id>.strategy.max-parallel
Número máximo de trabalhos que podem ser executados simultaneamente ao usar uma estratégia de trabalho de matrix
. Por padrão, o GitHub maximizará o número de trabalhos executados em paralelo dependendo dos executores disponíveis nas máquinas virtuais hospedadas no GitHub.
strategy:
max-parallel: 2
jobs.<job_id>.continue-on-error
Impede que ocorra falha na execução de um fluxo de trabalho quando ocorrer uma falha em um trabalho. Defina como verdadeiro
para permitir que uma execução de um fluxo de trabalho passe quando este trabalho falhar.
Exemplo: Evitando uma falha específica na matriz de trabalho por falha na execução de um fluxo de trabalho
Você pode permitir que as tarefas específicas em uma matriz de tarefas falhem sem que ocorra falha na execução do fluxo de trabalho. Por exemplo, se você deseja permitir apenas um trabalho experimental com o nó
definido como 15
sem falhar a execução do fluxo de trabalho.
runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
strategy:
fail-fast: false
matrix:
node: [13, 14]
os: [macos-latest, ubuntu-18.04]
experimental: [false]
include:
- node: 15
os: ubuntu-18.04
experimental: true
jobs.<job_id>.container
Contêiner para executar qualquer etapa em um trabalho que ainda não tenha especificado um contêiner. Se você tiver etapas que usam ações de script e de contêiner, as ações de contêiner serão executadas como contêineres irmãos na mesma rede e com as mesmas montagens de volume.
Se você não definir um container
, todas as etapas serão executadas diretamente no host especificado por runs-on
, a menos que uma etapa se refira a uma ação configurada para execução em um contêiner.
Exemplo
jobs:
my_job:
container:
image: node:14.16
env:
NODE_ENV: development
ports:
- 80
volumes:
- my_docker_volume:/volume_mount
options: --cpus 1
Ao especificar somente uma imagem de contêiner, você pode omitir a palavra-chave image
.
jobs:
my_job:
container: node:14.16
jobs.<job_id>.container.image
Imagem Docker a ser usada como contêiner para executar a ação. O valor pode ser o nome da imagem do Docker Hub ou um nome de registro público.
jobs.<job_id>.container.env
Define um mapa
das variáveis de ambiente no contêiner.
jobs.<job_id>.container.ports
Define um array
de portas para expor no contêiner.
jobs.<job_id>.container.volumes
Define um array
de volumes para uso do contêiner. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.
Para especificar um volume, especifique o caminho de origem e destino:
<source>:<destinationPath>
.
<source>
é um nome de volume ou caminho absoluto na máquina host, e <destinationPath>
é um caminho absoluto no contêiner.
Exemplo
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.container.options
Opções adicionais de recursos do contêiner Docker. Para obter uma lista de opções, consulte "opções docker create
".
Aviso: A opção --network
não é compatível.
jobs.<job_id>.services
Nota: se seus fluxos de trabalho usam ações do contêiner Docker ou recipientes de serviço, você deve usar um executor Linux:
- Se você estiver usando executores hospedados em GitHub, você deverá usar um executor do Ubuntu.
- Se você estiver usando executores auto-hospedados, você deve usar uma máquina Linux, pois seu executor e o Docker precisam ser instalados.
Usado para hospedar contêineres de serviço para um trabalho em um fluxo de trabalho. Contêineres de serviço são úteis para a criação de bancos de dados ou serviços armazenamento em cache como o Redis. O executor cria automaticamente uma rede do Docker e gerencia o ciclo de vida dos contêineres do serviço.
Se você configurar seu trabalho para ser executado em um contêiner, ou a sua etapa usar ações ao contêiner, você não precisará mapear as portas para acessar o serviço ou a ação. O Docker expõe automaticamente todas as portas entre os contêineres da mesma rede de ponte definida pelo usuário. Você pode fazer referência ao contêiner de serviço diretamente pelo seu nome de host. O nome do host é mapeado automaticamente com o nome da etiqueta que você configurar para o serviço no fluxo de trabalho.
Se você configurar a tarefa para executar diretamente na máquina do executor e sua etapa não usar uma ação de contêiner, você deverá mapear todas as portas de contêiner de serviço do Docker necessárias para o host do Docker (a máquina do executor). Você pode acessar o contêiner de serviço usando host local e a porta mapeada.
Para obter mais informações sobre as diferenças entre os contêineres de serviço de rede, consulte "Sobre contêineres de serviço".
Exemplo: Usando host local
Este exemplo cria dois serviços: nginx e redis. Ao especificar a porta do host do Docker mas não a porta do contêiner, a porta do contêiner será atribuída aleatoriamente a uma porta livre. O GitHub define a porta de contêiner atribuída no contexto ${{job.services.<service_name>.ports}}
. Neste exemplo, você pode acessar as portas do contêiner de serviço usando os contextos ${{ job.services.nginx.ports['8080'] }}
e ${{ job.services.redis.ports['6379'] }}
.
serviços:
nginx:
imagem: nginx
# Mapeia a porta 8080 no host do Docker com a porta 80 no contêiner nginx
portas:
- 8080:80
redis:
imagem: redis
# Mapeia a porta port 6379 TCP no host do Docker com uma porta livre aleatória no contêiner Redis
portas:
- 6379/tcp
jobs.<job_id>.services.<service_id>.image
Imagem Docker a ser usada como contêiner de serviço para executar a ação. O valor pode ser o nome da imagem do Docker Hub ou um nome de registro público.
jobs.<job_id>.services.<service_id>.env
Define um maá
das variáveis de ambiente no contêiner do serviço.
jobs.<job_id>.services.<service_id>.ports
Define um array
de portas para expor no contêiner de serviço.
jobs.<job_id>.services.<service_id>.volumes
Define um array
de volumes para uso do contêiner de serviço. É possível usar volumes para compartilhar dados entre serviços ou outras etapas em um trabalho. Você pode especificar volumes de nome Docker, volumes Docker anônimos ou vincular montagens no host.
Para especificar um volume, especifique o caminho de origem e destino:
<source>:<destinationPath>
.
<source>
é um nome de volume ou caminho absoluto na máquina host, e <destinationPath>
é um caminho absoluto no contêiner.
Exemplo
volumes:
- my_docker_volume:/volume_mount
- /data/my_data
- /source/directory:/destination/directory
jobs.<job_id>.services.<service_id>.options
Opções adicionais de recursos do contêiner Docker. Para obter uma lista de opções, consulte "opções docker create
".
Aviso: A opção --network
não é compatível.
Folha de consulta de filtro padrão
Você pode usar caracteres especiais nos filtros de caminhos, branches e tags.
*
: Corresponde a zero ou mais caracteres, mas não Corresponde ao caractere/
. Por exemplo,Octo*
corresponde aOctocat
.**
: Corresponde a zero ou mais de qualquer caractere.?
: Corresponde a zero ou a um dos caracteres anteriores.+
: Corresponde a um ou mais dos caracteres anteriores.[]
Corresponde a um caractere listado entre colchetes ou incluído nos intervalos. Os intervalos só podem incluir valores dea-z
,A-Z
, e0-9
. Por exemplo, o intervalo[0-9a-z]
corresponde a qualquer letra maiúscula ou minúscula. Por exemplo,[CB]at
corresponde aCat
ouBat
e[1-2]00
corresponde a100
e200
.!
No início de um padrão faz com que ele anule padrões positivos anteriores. Não tem nenhum significado especial caso não seja o primeiro caractere.
Os caracteres *
, [
e !
são caracteres especiais em YAML. Se você iniciar um padrão com *
, [
ou !
, você deverá colocá-lo entre aspas.
# Válido
- '**/README.md'
# Inválido - Cria um erro de análise que
# impede que o seu fluxo de trabalho seja executado.
- **/README.md
Para obter mais informações sobre a sintaxe de filtros de branches, tags e caminhos, consulte "on.<push|pull_request>.<branches|tags>
" e "on.<push|pull_request>.paths
".
Padrões para corresponder branches e tags
Padrão | Descrição | Exemplos de correspondências |
---|---|---|
feature/* | O caractere curinga * corresponde a qualquer caractere, mas não à barra (/ ). | feature/my-branch feature/your-branch |
feature/** | ** correspondem a qualquer caractere, incluindo a barra (/ ) em nomes de branches e tags. | feature/beta-a/my-branch feature/your-branch feature/mona/the/octocat |
main releases/mona-the-octocat | Corresponde ao nome exato de um branch ou tag. | main releases/mona-the-octocat |
'*' | Corresponde a todos os nomes de branches e tags que não contêm uma barra (/ ). O caractere * é um caractere especial em YAML. Ao inciar um padrão com * , você deve usar aspas. | main releases |
'**' | Corresponde a todos os nomes de branches e tags. Esse é o comportamento padrão quando você não usa um filtro de branches ou tags . | all/the/branches every/tag |
'*feature' | O caractere * é um caractere especial em YAML. Ao inciar um padrão com * , você deve usar aspas. | mona-feature feature ver-10-feature |
v2* | Corresponde aos nomes de branches e tags que iniciam com v2 . | v2 v2.0 v2.9 |
v[12].[0-9]+.[0-9]+ | Corresponde a todas as tags de versão de branch semântica com a versão principal 1 ou 2 | v1.10.1 v2.0.0 |
Padrões para corresponder a caminhos de arquivos
Padrões de caminhos devem corresponder ao caminho completo e iniciar a partir da raiz do repositório.
Padrão | Descrição das correspondências | Exemplos de correspondências |
---|---|---|
'*' | O caractere curinga * corresponde a qualquer caractere, mas não à barra (/ ). O caractere * é um caractere especial em YAML. Ao inciar um padrão com * , você deve usar aspas. | README.md server.rb |
'*.jsx?' | O caractere ? corresponde a zero ou a um dos caracteres anteriores. | page.js page.jsx |
'**' | ** corresponde a qualquer caractere incluindo a barra (/ ). Esse é o comportamento padrão quando você não usa um filtro de path . | all/the/files.md |
'*.js' | O caractere curinga * corresponde a qualquer caractere, mas não à barra (/ ). Corresponde a todos os arquivos .js na raiz do repositório. | app.js index.js |
'**.js' | Corresponde a todos os arquivos .js no repositório. | index.js js/index.js src/js/app.js |
docs/* | Todos os arquivos dentro da raiz do diretório docs , na raiz do repositório. | docs/README.md docs/file.txt |
docs/** | Qualquer arquivo no diretório docs , na raiz do repositório. | docs/README.md docs/mona/octocat.txt |
docs/**/*.md | Um arquivo com um sufixo .md em qualquer local do diretório docs . | docs/README.md docs/mona/hello-world.md docs/a/markdown/file.md |
'**/docs/**' | Qualquer arquivo no diretório docs , em qualquer local do repositório. | docs/hello.md dir/docs/my-file.txt space/docs/plan/space.doc |
'**/README.md' | Um arquivo README.md em qualquer local do repositório. | README.md js/README.md |
'**/*src/**' | Qualquer arquivo em uma pasta com o sufixo src em qualquer local do repositório. | a/src/app.js my-src/code/js/app.js |
'**/*-post.md' | Um arquivo com o sufixo -post.md em qualquer local do repositório. | my-post.md path/their-post.md |
'**/migrate-*.sql' | Um arquivo com o prefixo migrate- e sufixo .sql em qualquer local do repositório. | migrate-10909.sql db/migrate-v1.0.sql db/sept/migrate-v1.sql |
*.md !README.md | Usar um sinal de exclamação (! ) na frente de um padrão o anula. Quando um arquivo corresponde a um padrão e também corresponde a um padrão negativo definido posteriormente no arquivo, o arquivo não será incluído. | hello.md Does not match README.md docs/hello.md |
*.md !README.md README* | Os padrões são verificados sequencialmente. Um padrão que anula um padrão anterior irá incluir caminhos de arquivos novamente. | hello.md README.md README.doc |