Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Configurar fluxo de trabalho

Se tiver acesso de gravação ou permissões de administrador em um repositório, você poderá criar, visualizar ou editar os fluxos de trabalho do repositório em questão. Você pode personalizar a configuração do seu fluxo de trabalho com base nos tipos de ações que inclui nele.

GitHub Actions is available with GitHub Free, GitHub Pro, GitHub Team, and GitHub Enterprise Cloud. GitHub Actions is unavailable for per-repository plans, which are legacy billing plans. For more information, see "GitHub's products."

Neste artigo

Sobre fluxos de trabalho

Fluxos de trabalho são processos automatizados personalizados que você pode configurar no repositório para criar, testar, fazer pacotes, gerar versões ou implantar qualquer projeto no GitHub. Com os fluxos de trabalho, você pode automatizar o ciclo de vida de desenvolvimento de software usando várias ferramentas e serviços. Para obter mais informações, consulte "Sobre o GitHub Actions".

É possível criar mais de um fluxo de trabalho em um repositório. Você deve armazenar os fluxos de trabalho no diretório .github/workflows na raiz do seu repositório.

Os fluxos devem ter pelo menos um trabalho, e os trabalhos têm um conjunto de etapas que executam tarefas individuais. As etapas podem executar comandos ou usar ações. É possível criar suas próprias ações ou usar ações compartilhadas pela comunidade do GitHub. Se necessário, você também pode personalizá-las.

Você pode configurar um fluxo de trabalho para começar quando ocorrer um evento do GitHub, em determinado horário ou quando ocorrer um evento externo.

É necessário configurar os fluxos de trabalho usando a sintaxe YAML e salvá-los como arquivos de fluxo de trabalho no repositório. Depois de criar um arquivo de fluxo de trabalho YAML e de acionar seu fluxo de trabalho, você verá os logs de criação, os resultados dos testes, os artefatos e os status de cada etapa do fluxo de trabalho. Para obter mais informações, consulte "Gerenciar a execução de fluxos de trabalho".

Imagem de execução de fluxo de trabalho comentada

Você também pode receber notificações de atualizações de status do fluxo de trabalho. Para obter mais informações sobre as opções de notificação, consulte "Escolher o método de entrega das notificações".

Os limites de uso se aplicam a fluxos de trabalho individuais. Para obter mais informações, consulte "Limites de uso para fluxos de trabalho".

Criar arquivo de fluxo de trabalho

Em nível alto, estas são as etapas necessárias para adicionar um arquivo de fluxo de trabalho. Nas seções a seguir, você verá exemplos específicos de configuração.

  1. Na raiz do repositório, crie um diretório denominado .github/workflows para armazenar seus arquivos de fluxo de trabalho.

  2. Em .github/workflows, adicione um arquivo .yml ou .yaml em seu fluxo de trabalho. Por exemplo, .github/workflows/continuous-integration-workflow.yml.

  3. Use a documentação de referência "Sintaxe de fluxo de trabalho para o GitHub Actions" a fim de escolher os eventos para acionar ações, adicionar ações e personalizar seu fluxo de trabalho.

  4. Faça commit das alterações no arquivo de fluxo de trabalho para o branch em que você pretende executar o fluxo de trabalho.

Exemplo de arquivo de fluxo de trabalho

name: Cumprimentar a Todos
# Este fluxo de trabalho é acionado em pushes para o repositório.
on: [push]

jobs:
  build:
    # o nome do trabalho é greeting (cumprimentar)
    name: Greeting
    # Este trabalho executa no Linux
    runs-on: ubuntu-latest
    steps:
      # Esta etapa usa hello-world-javascript-action do GitHub: https://github.com/actions/hello-world-javascript-action
      - name: Hello world
        uses: actions/hello-world-javascript-action@v1
        with:
          who-to-greet: 'Mona the Octocat'
        id: hello
      # Esta etapa imprime uma saída (tempo) da ação da etapa anterior.
      - name: Echo the greeting's time
        run: echo 'The time was ${{ steps.hello.outputs.time }}.'

Acionar fluxos de trabalho com eventos

Você pode configurar o início de um fluxo de trabalho para as seguintes situações:

  • Quando ocorrer um evento no GitHub, como quando alguém faz push de um commit para um repositório ou quando um problema ou uma pull request é criada;
  • Quando um evento programado começa;
  • Quando um evento externo ocorre.

Para acionar um fluxo de trabalho depois que um evento ocorre no GitHub, adicione on: e um valor de evento após o nome do fluxo. Por exemplo, este fluxo de trabalho é acionado quando ocorre o push das alterações para qualquer branch no repositório.

name: nome-descritivo-fluxo-de-trabalho
on: push

Para agendar um fluxo, você pode usar a sintaxe cron POSIX no arquivo de fluxo de trabalho. The shortest interval you can run scheduled workflows is once every 5 minutes. Por exemplo, este fluxo é acionado a cada hora.

on:
  schedule:
    - cron:  '0 * * * *'

Para acionar um fluxo de trabalho depois que um evento externo ocorre, você pode utilizar um evento de webhook repository_dispatch chamando o endpoint da API REST "Criar um evento de envio de repositório". Para obter mais informações, consulte "Criar um evento de envio de repositório" em documentação do GitHub Developer.

Para obter mais informações e exemplos, consulte "Eventos que acionam fluxos de trabalho".

Filtrar por branches, tags e caminhos específicos

É possível configurar seu fluxo de trabalho para execução somente em determinados branches.

Por exemplo, esse fluxo de trabalho é executado quando um push que inclui arquivos no diretório test é feito no branch master ou faz push na tag v1.

on:
  push:
    branches:
      - master
    tags:
      - v1
    # caminhos de arquivo a serem considerados no evento. Opcional; define todos como padrão.
    paths:
      - 'test/*'

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

Choosing a runner

You can run workflows on GitHub-hosted runners or self-hosted runners. Jobs can run directly on the machine or in a Docker container.

You can specify the runner for each job in a workflow using runs-on. For more information about runs-on, see "Workflow syntax for GitHub Actions."

Using a GitHub-hosted runner

You can select from different types and versions of virtual host machines, including Linux, Windows, and macOS. Each job in a workflow executes in a fresh instance of the virtual environment, and steps within a job can share information using the filesystem. For more information, see "Virtual environments for GitHub Actions-hosted runners."

For example, you can use ubuntu-latest to specify the latest version of an Ubuntu GitHub-hosted runner.

runs-on: ubuntu-latest

Using a self-hosted runner

If you've added self-hosted runners to your repository, you can specify a self-hosted runner using labels. All self-hosted runners get the self-hosted label and each self-hosted runner has labels for its operating system and system architecture. For more information, see "Using self-hosted runners in a workflow."

For example, if you added a self-hosted runner with a Linux operating system and ARM32 architecture, you can select that runner using the self-hosted, linux, and ARM32 labels.

runs-on: [self-hosted, linux, ARM32]

Configurar matriz de compilação

Para fazer testes simultaneamente em vários sistemas operacionais, plataformas e versões de idiomas, você pode configurar uma matriz de compilação.

Com a matriz de criação, é possível fazer configurações diferentes no ambiente virtual para fins de teste. Por exemplo, um fluxo pode executar um trabalho para mais de uma versão compatível de um idioma, sistema operacional ou ferramenta. Para cada configuração, uma cópia do trabalho é executado e gera um status.

Você pode especificar uma matriz de criação no arquivo de fluxo de trabalho com um array que lista as opções de configuração em strategy:. Por exemplo, essa matriz de compilação vai executar um trabalho com versões diferentes de Node.js e Ubuntu, um sistema operacional Linux.

When you define a matrix of operating systems, you must set the required runs-on keyword to the operating system of the current job, rather than hard-coding the operating system name. To access the operating system name, you can use the matrix.os context parameter to set runs-on. Para obter mais informações, consulte "Contextos e sintaxe de expressão no GitHub Actions".

runs-on: ${{ matrix.os }}
strategy:
  matrix:
    os: [ubuntu-16.04, ubuntu-18.04]
    node: [6, 8, 10]

Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Usar a ação de checkout

Você pode usar várias ações padrão no seu fluxo de trabalho. A ação de checkout é uma ação padrão que você deve incluir no fluxo de trabalho antes de outras ações nas situações seguintes:

  • Quando o fluxo de trabalho requer uma cópia do código do seu repositório, como quando você está compilando e testando o repositório ou usando integração contínua;
  • Quando houver pelo menos uma ação no fluxo de trabalho definida no mesmo repositório. Para obter mais informações, consulte "Fazer referência a ações em fluxos de trabalho".

Para usar a ação padrão de checkout sem outras especificações, inclua esta etapa:

- uses: actions/checkout@v1

Usar v1 neste exemplo garante que você esteja usando uma versão estável da ação de checkout.

Para clonar superficialmente seu repositório, ou copiar apenas a versão mais recente do repositório, defina fetch-depth com a sintaxe with:

- uses: actions/checkout@v1
  with:
    fetch-depth: 1

Para obter mais informações, consulte ação de checkout.

Definir os tipos de ação do fluxo de trabalho

Você pode usar vários tipos de ação no fluxo de trabalho para atender às demandas do seu projeto:

  • Ações de contêiner Docker.
  • Ações JavaScript

Para obter mais informações, consulte "Sobre ações".

Ao escolher o tipo de ação a ser usada no fluxo de trabalho, recomendamos que você explore as ações disponíveis nos repositórios públicos ou no Docker Hub, já que elas podem ser personalizadas no seu projeto.

Você pode navegar e usar as ações compiladas pelo GitHub na organização github.com/actions. Para acessar o Docker Hub, consulte "Docker Hub" no site do Docker.

Fazer referência a ações em fluxos de trabalho

Para fazer referência a ações no arquivo de fluxo de trabalho com a sintaxe correta, você deve verificar onde a ação está definida.

Fluxos de trabalho podem usar ações definidas nos seguintes locais:

  • Em repositórios públicos;
  • No repositório em que o arquivo de fluxo faz referência às ações;
  • Em uma imagem de contêiner Docker publicada no Docker Hub.

Para usar uma ação definida em um repositório privado, o arquivo de fluxo de trabalho e a ação devem estar no mesmo repositório. Seu fluxo de trabalho não pode usar ações definidas em outros repositórios privados, mesmo que o outro repositório privado esteja na mesma organização.

Para manter seu fluxo de trabalho estável mesmo quando houver atualizações em uma ação, é possível fazer referência à versão da ação que você está usando ao especificar uma ref Git ou número de tag Docker no arquivo de fluxo de trabalho. Para ver exemplos, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Para ver opções detalhadas de configuração, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Fazer referência a uma ação de um repositório público

Se uma ação for definida em um repositório público, você deve fazer referência a ela usando a sintaxe {owner}/{repo}@{ref} ou {owner}/{repo}/{path}@{ref}.

jobs:
  meu_primeiro_trabalho:
    name: nome do meu trabalho
      steps:
        - uses: actions/setup-node@v1
          with:
            node-version: 10.x

Para ver um exemplo de fluxo de trabalho completo, consulte o repositório de modelo nó de configuração.

Fazer referência a uma ação no mesmo repositório em que um arquivo de fluxo de trabalho usa a ação

Se uma ação for definida no mesmo repositório em que seu arquivo de fluxo de trabalho usa a ação, será possível fazer referência a ela com as sintaxes {owner}/{repo}@{ref} ou ./path/to/dir no arquivo de fluxo de trabalho.

Exemplo de estrutura de arquivo de repositório:

|-- hello-world (repository)
|   |__ .github
|       └── workflows
|           └── my-first-workflow.yml
|       └── actions
|           |__ hello-world-action
|               └── action.yml

Exemplo de arquivo de fluxo de trabalho:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Esta etapa faz checkout de uma cópia do seu repositório.
      - uses: actions/checkout@v1
      # Esta etapa faz referência ao diretório que contém a ação.
      - uses: ./.github/actions/hello-world-action

Fazer referência a um contêiner no Docker Hub

Se uma ação for definida em uma imagem de contêiner do Docker publicada no Docker Hub, você deve fazer referência à ação com a sintaxe docker://{image}:{tag} no arquivo de fluxo de trabalho. Para proteger seu código e os dados, é altamente recomendável verificar a integridade da imagem do contêiner Docker no Docker Hub antes de usá-la no fluxo de trabalho.

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

Para ver alguns exemplos de ações do Docker, consulte o Fluxo de trabalho Docker-image.yml e "Criar uma ação de contêiner do Docker."

Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Adicionar um selo de fluxo de trabalho em seu repositório

Status badges show whether a workflow is currently failing or passing. A common place to add a status badge is in the README.md file of your repository, but you can add it to any web page you'd like. By default, badges display the status of your default branch (usually master). You can also display the status of a workflow run for a specific branch or event using the branch and event query parameters in the URL.

Se o seu fluxo de trabalho usa a palavra-chave name, você pode fazer referência ao fluxo de trabalho pelo nome. Se o nome do seu fluxo de trabalho tem espaços em branco, será necessário substituir o espaço com a string codificada do URL%20. Para obter mais informações sobre a palavra-chave name, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_NAME>/badge.svg

Se o seu fluxo de trabalho não tem um name, você pode fazer referência ao arquivo do fluxo de trabalho usando o caminho do arquivo do diretório raiz do repositório.

https://github.com/<OWNER>/<REPOSITORY>/workflows/<WORKFLOW_FILE_PATH>/badge.svg

Exemplo de uso de um nome de fluxo de trabalho

Este exemplo de Markdown adiciona um selo de status em um fluxo de trabalho com o nome "Greet Everyone" (Cumprimentar a todos). O OWNER do repositório é a organização actions e o nome do REPOSITORY (repositório) é hello-world.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg)

Exemplo de uso de um caminho de arquivo de fluxo de trabalho

Esse exemplo de Markdown adiciona um selo de status para um fluxo de trabalho com o caminho de arquivo .github/workflows/main.yml. O OWNER (proprietário) do repositório é a organização actions e o nome do REPOSITORY (repositório) é hello-world.

![](https://github.com/actions/hello-world/workflows/.github/workflows/main.yml/badge.svg)

Exemplo usando o parâmetro branch

Este exemplo de Markdown adiciona um selo de status para um branch com o nome feature-1.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?branch=feature-1)

Exemplo usando o parâmetro event

Este exemplo de Markdown adiciona um selo que exibe o status das execuções do fluxo de trabalho acionadas pelo evento pull_request.

![](https://github.com/actions/hello-world/workflows/Greet%20Everyone/badge.svg?event=pull_request)

Leia mais

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato