Sintaxe de fluxo de trabalho para o GitHub Actions

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ê não souber o que é YAMLe quiser saber mais, consulte "Aprender a usar YAML em cinco minutos".

Você deve armazenar os arquivos de fluxo de trabalho no diretório .github/workflows do seu repositório.

Limites de uso

There are some limits on GitHub Actions usage, and will vary depending on whether you use GitHub-hosted or self-hosted runners. These limits are subject to change.

• Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete. This limit does not apply to self-hosted runners.

• Workflow run time - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled. This limit also applies to self-hosted runners.

• Job queue time - Each job for self-hosted runners can be queued for a maximum of 24 hours. If a self-hosted runner does not start executing the job within this limit, the job is terminated and fails to complete. This limit does not apply to GitHub-hosted runners.

• API requests - You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail. This limit also applies to self-hosted runners.

• Concurrent jobs - The number of concurrent jobs you can run in your account depends on your GitHub plan, as indicated in the following table. If exceeded, any additional jobs are queued. There are no concurrency limits for self-hosted runners.

  GitHub plan	Total concurrent jobs	Maximum concurrent macOS jobs
  Grátis	20	5
  Pro	40	5
  Equipe	60	5
  Enterprise	180	50

• Job matrix - A job matrix can generate a maximum of 256 jobs per workflow run. This limit also applies to self-hosted runners.

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 Nome do evento do 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 com um único evento

# Acionar no push
on: push

Exemplo com uma lista de eventos

# Acionar o fluxo de trabalho em pull request ou push
on: [push, pull_request]

Example using multiple events with activity types or configuration

If you need to specify activity types or configuration for an event, you must configure each event separately. You must append a colon (:) to all events, including events without configuration.

on:
  # Trigger the workflow on push or pull request,
  # but only for the master branch
  push:
    branches:
      - master
  pull_request:
    branches:
      - master
  # 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".

# Aciona o fluxo de trabalho na atividade de pull request
on:
  release:
    # Usa apenas a palavra-chave types (tipos) para limitar os tipos de atividades que acionam o fluxo de trabalho.
    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 e tags-ignore aceitam padrões glob que usam os caracteres curinga * e ** para coincidir com mais de um nome de branch ou tag. Para obter mais informações, consulte a "Folha de consulta de filtro padrão".

Exemplo com 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.

em:
  push:
    # Sequência de padrões que correspondem a refs/heads
    branches:    
      # Push de eventos no branch-mestre
      - mestre
      # Push de eventos para branches que correspondem a refs/heads/mona/octocat
      - 'mona/octocat'
      # Push de eventos para branches que correspondem a refs/heads/releases/10
      - 'releases/**'
    # Sequência de padrões que correspondem a refs/tags
    tags:        
      - v1             # Push events to v1 tag
      - v1.*           # Push events to v1.0, v1.1, and v1.9 tags

Exemplo desconsiderando 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.

em:
  push:
    # Sequência de padrões que correspondem a refs/heads
    branches-ignore:
      # Push de eventos para branches que correspondem a refs/heads/mona/octocat
      - 'mona/octocat'
      # Push de eventos para branches que correspondem a refs/heads/releases/beta/3-alpha
      - 'releases/**-alpha'
    # Sequência de padrões que correspondem a refs/tags
    tags-ignore:
      - v1.*           # 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 ou branches-ignore - não é possível usar os dois filtros branches e branches-ignore para o mesmo evento em um fluxo de trabalho. Use o filtro branches quando você precisa filtrar branches para correspondências positivas e excluir branches. Use o filtro branches-ignore quando você só precisa excluir nomes de branches.
• tags ou tags-ignore - não é possível usar os dois filtros tags e tags-ignore para o mesmo evento em um fluxo de trabalho. Use o filtro tags quando você precisa filtrar tags para correspondências positivas e excluir tags. Use o filtro tags-ignore quando você só precisa excluir nomes de tags.

Exemplo com 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 desconsiderando caminhos

Sempre que um nome de caminho corresponder a um padrão 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 filtro paths-ignore quando você precisa somente excluir nomes de caminhos.
• paths - use o filtro paths quando você precisa filtrar caminhos para correspondências positivas e excluir caminhos.

Exemplo com 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

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.

Para obter mais informações, consulte "Sobre comparação de branches em pull requests".

on.schedule

You can schedule a workflow to run at specific UTC times using POSIX cron syntax. Scheduled workflows run on the latest commit on the default or base branch. The shortest interval you can run scheduled workflows is once every 5 minutes.

This example triggers the workflow every 15 minutes:

on:
  schedule:
    # * is a special character in YAML so you have to quote this string
    - cron:  '*/15 * * * *'

Para obter mais informações sobre a sintaxe cron, consulte "Eventos que acionam fluxos de trabalho".

env

Um map (mapa) das variáveis de ambiente que estão disponíveis para todos os trabalhos e etapas do fluxo de trabalho. Também é possível configurar variáveis de ambiente que estão disponíveis apenas para um trabalho ou etapa. Para obter mais informações, consulte jobs.<job_id>.env e jobs.<job_id>.steps.env.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

Example

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.

When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.

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.

When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.

Exemplo

padrões:
  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 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".

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:
  meu_primeiro_trabalho:
    name: meu primeiro trabalho
  meu_segundo_trabalho:
    name: meu segundo trabalho

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 instrução condicional que faça o trabalho continuar.

Example

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:

1. job1
2. job2
3. job3

jobs.<job_id>.runs-on

Obrigatório O tipo de máquina para executar o trabalho. A máquina pode ser ou um executor hospedado em GitHub ou um executor auto-hospedado.

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
Windows Server 2019	windows-latest ou windows-2019
Ubuntu 20.04	ubuntu-20.04
Ubuntu 18.04	ubuntu-latest ou ubuntu-18.04
Ubuntu 16.04	ubuntu-16.04
macOS Catalina 10.15	macos-latest or macos-10.15

Example

runs-on: ubuntu-latest

For more information, see "Virtual environments for GitHub-hosted runners."

Executores auto-hospedados

To specify a self-hosted runner for your job, configure runs-on in your workflow file with self-hosted runner labels.

All self-hosted runners have the self-hosted label, and you can select any self-hosted runner by providing only the self-hosted label. Alternatively, you can use self-hosted in an array with additional labels, such as labels for a specific operating system or system architecture, to select only the runner types you specify.

Example

runs-on: [self-hosted, linux]

For more information, see "About self-hosted runners" and "Using self-hosted runners in a workflow."

jobs.<jobs_id>.outputs

A map of outputs for a job. Job outputs are available to all downstream jobs that depend on this job. For more information on defining job dependencies, see jobs.<job_id>.needs.

Job outputs are strings, and job outputs containing expressions are evaluated on the runner at the end of each job. Outputs containing secrets are redacted on the runner and not sent to GitHub Actions.

To use job outputs in a dependent job, you can use the needs context. For more information, see "Context and expression syntax for GitHub Actions."

Exemplo

trabalhos:
  job1:
    runs-on: ubuntu-latest
    # Mapeia a saída de uma etapa com a saída de um trabalho
    saídas:
      output1: ${{ steps.step1.outputs.test }}
      output2: ${{ steps.step2.outputs.test }}
    etapas:
    - 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
    etapas:
    - 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.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

Exemplo

jobs:
  job1:
    env:
      FIRST_NAME: Mona

jobs.<job_id>.defaults

A map of default settings that will apply to all steps in the job. You can also set default settings for the entire workflow. For more information, see defaults.

When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.

jobs.<job_id>.defaults.run

Provide default shell and working-directory to all run steps in the job. Context and expression are not allowed in this section.

You can provide default shell and working-directory options for all run steps in a job. You can also set default settings for run for the entire workflow. For more information, see jobs.defaults.run. Você não pode usar contextos ou expressões nesta palavra-chave.

When more than one default setting is defined with the same name, GitHub uses the most specific default setting. For example, a default setting defined in a job will override a default setting that has the same name defined in a workflow.

Example

trabalhos:
  job1:
    runs-on: ubuntu-latest
    padrões:
      executar:
        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.

When you use expressions in an if conditional, you may omit the expression syntax (${{ }}) because GitHub automatically evaluates the if conditional as an expression. Para obter mais informações, consulte "Contexto e sintaxe de expressão para GitHub Actions".

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. Each step runs in its own process in the runner environment and has access to the workspace and filesystem. 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".

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. For more information, see "Context and expression syntax for GitHub Actions."

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.

When you use expressions in an if conditional, you may omit the expression syntax (${{ }}) because GitHub automatically evaluates the if conditional as an expression. Para obter mais informações, consulte "Contexto e sintaxe de expressão para GitHub Actions".

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

etapas:
 - nome: Minha primeira etapa
   se: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}
   executar: echo Este evento é um pull request cujo responsável foi removido.

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. For more information, see "Context and expression syntax for GitHub Actions."

etapas:
  - nome: Minha primeira etapa
    usa: monacorp/action-name@master
  - nome: Minha etapa de backup
    se: ${{ failure() }}
    usa: actions/heroku@master

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 master de uma ação pode ser conveniente, mas pode gerar problemas no fluxo de trabalho caso uma nova versão principal seja lançada.

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. If the action you're using is a Docker container you must run the job in a Linux environment. For more details, see runs-on.

Exemplo usando ações com versão

etapas:    
  # Referência a um commit específico
  - usa: actions/setup-node@74bc508
  # Referência a uma versão principal da versão
  - usa: actions/setup-node@v1
  # Referência a uma versão menor da versão
  - usa: actions/setup-node@v1.2
  # Referência a um branch
  - usa: actions/setup-node@master

Exemplo usando uma ação pública

{owner}/{repo}@{ref}

Você pode especificar um branch, ref ou SHA em um repositório público GitHub.

trabalhos:
  my_first_job:
    etapas:
      - nome: Minha primeira etapa
        # Usa o branch-mestre de um repositório público
        usa: actions/heroku@master
      - nome: Minha segunda etapa
        # Usa a tag de uma versão específica de um repositório público
        usa: 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:
  meu_primeiro_trabalho:
    steps:
      - name: minha primeira etapa 
        uses: actions/aws/ec2@master

Exemplo usando a 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. You must check out your repository before using the action.

trabalhos:
  my_first_job:
    etapas:
      - Nome: Verificar repositório
        usa: actions/checkout@v2
      - nome: Use local my-action
        usa: ./.github/actions/my-action

Exemplo usando uma ação do Docker Hub

docker://{image}:{tag}

Imagem Docker publicada no Docker Hub.

jobs:
  meu_primeiro_trabalho:
    steps:
      - name: minha primeira etapa
        uses: docker://alpine:3.8

Exemplo usando uma ação do registro público do Docker Hub

docker://{host}/{image}:{tag}

Imagem Docker em um registro público.

jobs:
  meu_primeiro_trabalho:
    steps:
      - name: minha primeira etapa
        uses: docker://gcr.io/cloud-builders/gradle

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

Each run keyword represents a new process and shell in the runner environment. 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

You can override the default shell settings in the runner's operating system using the shell keyword. É possível usar palavras-chave integradas a shell ou definir um conjunto personalizado de opções de shell.

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	powershell	Essa é a shell padrão usada no Windows. PowerShell Desktop. O GitHub anexa a extensão .ps1 ao nome do script.	powershell -command "& '{0}'".

Exemplo de execução de um script usando bash:

steps:
  - name: Display the path
    run: echo $PATH
    shell: bash

Exemplo de execução de um script usando Windows cmd

steps:
  - name: Display the path
    run: echo %PATH%
    shell: cmd

Exemplo de execução de um script usando PowerShell Core

steps:
  - name: Display the path
    run: echo ${env:PATH}
    shell: pwsh

Exemplo de execução de um script 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}.

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 fail-fast usando set -e o pipefail: padrão para bash e shell integrado. 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.

• powershell/pwsh

  • Comportamento fail-fast quando possível. Para shell integrado pwsh e powershell, 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} ou powershell -Command "& '{0}'", dependendo da situação.

• 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 error level do último programa que executou e retornará o código de erro para o executor. Este comportamento é internamente consistente o padrão de comportamento anterior sh e pwsh, e é o padrão cmd.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.

Example

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:
  meu_primeiro_trabalho:
    steps:
      - name: Minha primeira etapa
        uses: actions/hello_world@master
        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.

Example

steps:
  - name: Explica por que o trabalho foi executado
    uses: monacorp/action-name@master
    with:
      entrypoint: /bin/echo
      args: O evento ${{ github.event_name }} acionou esta etapa.

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:

1. Documente os argumentos necessários no LEIAME das ações e omita-os da instrução CMD.
2. Use padrões que permitam o uso da ação sem especificação de args.
3. 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.

Example

steps:
  - name: Run a custom command
    uses: monacorp/action-name@master
    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

Sets environment variables for steps to use in the runner environment. 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.

When more than one environment variable is defined with the same name, GitHub uses the most specific environment variable. For example, an environment variable defined in a step will override job and workflow variables with the same name, while the step executes. A variable defined for a job will override a workflow variable with the same name, while the job executes.

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. For more information, see "Using environment variables" and "Context and expression syntax for GitHub Actions."

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

The maximum number of minutes to let a job run before GitHub automatically cancels it. Padrão: 360

jobs.<job_id>.strategy

Estratégias criam matrizes de compilação para os trabalhos. Você pode definir variações diferentes dos ambientes em que vai executar os trabalhos.

jobs.<job_id>.strategy.matrix

You can define a matrix of different job configurations. A matrix allows you to create multiple jobs by performing variable substitution in a single job definition. For example, you can use a matrix to create jobs for more than one supported version of a programming language, operating system, or tool. A matrix reuses the job's configuration and creates a job for each matrix you configure.

A job matrix can generate a maximum of 256 jobs per workflow run. This limit also applies to self-hosted runners.

Each option you define in the matrix has a key and value. The keys you define become properties in the matrix context and you can reference the property in other areas of your workflow file. For example, if you define the key os that contains an array of operating systems, you can use the matrix.os property as the value of the runs-on keyword to create a job for each operating system. For more information, see "Context and expression syntax for GitHub Actions."

The order that you define a matrix matters. The first option you define will be the first job that runs in your workflow.

Exemplo de execução com mais de uma versão do Node.js

Você pode especificar uma matriz ao fornecer um array para as opções de configuração. For example, if the runner supports Node.js versions 6, 8, and 10, you could specify an array of those versions in the matrix.

This example creates a matrix of three jobs by setting the node key to an array of three Node.js versions. To use the matrix, the example sets the matrix.node context property as the value of the setup-node action's input parameter node-version. As a result, three jobs will run, each using a different Node.js version.

estratégia:
  matriz:
    nó: [6, 8, 10]
etapas:
  # Configura a versão do nó usada nos executores hospedados no GitHub
  - usa: actions/setup-node@v1
    com:
      # A versão do Node.js a ser configurada
      node-version: ${{ matrix.node }}

The setup-node action is the recommended way to configure a Node.js version when using GitHub-hosted runners. For more information, see the setup-node action.

Exemplo de execução com mais de um sistema operacional

You can create a matrix to run workflows on more than one runner operating system. You can also specify more than one matrix configuration. This example creates a matrix of 6 jobs:

• 2 sistemas operacionais especificados na array os
• 3 versões do Node.js especificadas na array do nó

When you define a matrix of operating systems, you must set the value of runs-on to the matrix.os context property you defined.

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]
steps:
  - uses: actions/setup-node@v1
    with:
      node-version: ${{ matrix.node }}

To find supported configuration options for GitHub-hosted runners, see "Virtual environments for GitHub-hosted runners."

Exemplo de inclusão valores adicionais em combinações

Você pode adicionar opções de configurações para um trabalho de matriz de compilação existente. For example, if you want to use a specific version of npm when the job that uses windows-latest and version 4 of node runs, you can use include to specify that additional option.

runs-on: ${{ matrix.os }}
estratégia:
  matriz:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    nó: [4, 6, 8, 10]
    inclui:
      # incluo uma variável nova do npm com um valor de 2
      # para o leg da matriz que corresponde ao os e à versão
      - os: windows-latest
        nó: 4
        npm: 2

Exemplo de inclusão novas combinações

You can use include to add new jobs to a build matrix. Any unmatched include configurations are added to the matrix. For example, if you want to use node version 12 to build on multiple operating systems, but wanted one extra experimental job using node version 13 on Ubuntu, you can use include to specify that additional job.

runs-on: ${{ matrix.os }}
estratégia:
  matriz:
    nó: [12]
    os: [macos-latest, windows-latest, ubuntu-18.04]
    inclui:
      - nó: 13
        os: ubuntu-18.04
        experimental: verdadeiro

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 }}
estratégia:
  matriz:
    os: [macos-latest, windows-latest, ubuntu-18.04]
    nó: [4, 6, 8, 10]
    excluir:
      # exclui o nó 4 no macOS
      - os: macos-latest
        node: 4

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

Prevents a workflow run from failing when a job fails. Set to true to allow a workflow run to pass when this job fails.

Exemplo do impedimento de uma matriz falha específica de gerar uma falha na execução do fluxo de trabalho

You can allow specific jobs in a job matrix to fail without failing the workflow run. For example, if you wanted to only allow an experimental job with node set to 13 to fail without failing the workflow run.

runs-on: ${{ matrix.os }}
continue-on-error: ${{ matrix.experimental }}
estratégia:
  fail-fast: falso
  matriz:
    nó: [11, 12]
    os: [macos-latest, ubuntu-18.04]
    experimental: [false]
    incluir:
      - nó: 13
        os: ubuntu-18.04
        experimental: verdadeiro

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.

Example

jobs:
  my_job:
    container:
      image: node:10.16-jessie
      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:10.16-jessie

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 do Docker público.

jobs.<job_id>.container.env

Sets a map of environment variables in the container.

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

jobs.<job_id>.services

Used to host service containers for a job in a workflow. Service containers are useful for creating databases or cache services like Redis. The runner automatically creates a Docker network and manages the life cycle of the service containers.

If you configure your job to run in a container, or your step uses container actions, you don't need to map ports to access the service or action. Docker automatically exposes all ports between containers on the same Docker user-defined bridge network. You can directly reference the service container by its hostname. The hostname is automatically mapped to the label name you configure for the service in the workflow.

If you configure the job to run directly on the runner machine and your step doesn't use a container action, you must map any required Docker service container ports to the Docker host (the runner machine). You can access the service container using localhost and the mapped port.

For more information about the differences between networking service containers, see "About service containers."

Exemplo de uso de host local

This example creates two services: nginx and redis. When you specify the Docker host port but not the container port, the container port is randomly assigned to a free port. GitHub sets the assigned container port in the ${{job.services.<service_name>.ports}} context. In this example, you can access the service container ports using the ${{ job.services.nginx.ports['8080'] }} and ${{ job.services.redis.ports['6379'] }} contexts.

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.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 de base do Docker Hub ou um hub ou registro do Docker público.

jobs.<job_id>.services.env

Sets a map of environment variables in the service container.

jobs.<job_id>.services.ports

Define um array de portas para expor no contêiner de serviço.

jobs.<job_id>.services.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.options

Opções adicionais de recursos do contêiner Docker. Para obter uma lista de opções, consulte "opções docker create".

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 a Octocat.
• **: Corresponde a zero ou mais de qualquer caractere.
• ?: Corresponde a zero ou a um único caractere. Por exemplo, Octoc?t corresponde a Octocat.
• +: 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 de a-z, A-Z, e 0-9. Por exemplo, o intervalo[0-9a-f] corresponde a qualquer letra maiúscula ou minúscula. Por exemplo, [CB]at corresponde a Cat ou Bat e [1-2]00 corresponde a 100 e 200.
• ! 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
funcionalidade/*	O caractere curinga * corresponde a qualquer caractere, mas não à barra (/).	-feature/my-branch -feature/your-branch
funcionalidade/**	** 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
-master -releases/mona-the-octcat	Corresponde ao nome exato de um branch ou tag.	-master -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.	-master -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
'*funcionalidade'	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 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.

Pattern	Descrição das correspondências	Exemplo de correspondência
'*'	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.	-LEIAME.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
documentação/*	Todos os arquivos dentro da raiz do diretório docs, na raiz do repositório.	-docs/LEIAME.md -docs/file.txt
documentação/**	Qualquer arquivo no diretório docs, na raiz do repositório.	-docs/LEIAME.md -docs/mona/octocat.txt
docs/**/*.md	Um arquivo com um sufixo .md em qualquer local do diretório docs.	-docs/LEIAME.md -docs/mona/hello-world.md -docs/a/markdown/file.md
'**/documentação/**'	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 LEIAME.md em qualquer local do repositório.	-LEIAME.md -js/LEIAME.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 -!LEIAME.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 -LEIAME.md -docs/hello.md
-*.md -!LEIAME.md -LEIAME*	Os padrões são verificados sequencialmente. Um padrão que anula um padrão anterior irá incluir caminhos de arquivos novamente.	-hello.md -LEIAME.md -LEIAME.doc