👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Learn more on the GitHub blog.


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

Você pode criar fluxos de trabalho personalizados para automatizar os processos do ciclo de vida do desenvolvimento do software do seu projeto.

GitHub Actions está disponível com GitHub Free, GitHub Pro, GitHub Free para organizações, GitHub Team, GitHub Enterprise Cloud e GitHub One. O GitHub Actions não está disponível para repositórios privados de contas que utilizam planos antigos por-repositório. Para obter mais informações, consulte os "produtos do GitHub".

Neste artigo

Você conseguiu encontrar o que estava procurando?

As pessoas com permissões de gravar ou administrador de um repositório podem criar, editar ou visualizar fluxos de trabalho.

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 "Configurando 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 }}.'

Note: Ensure that you only commit valid workflow files to your repository. If .github/workflows contains an invalid workflow file, GitHub Actions generates a failed workflow run for every new commit.

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. O intervalo mais curto que você pode executar fluxos de trabalho agendados é a cada 5 minutos. 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". For more information, see "Create a repository dispatch event."

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

Escolher um executor

Você pode executar fluxos de trabalho nos executores hospedados em GitHub ou em executores auto-hospedados. Os trabalhos podem ser executados diretamente na máquina ou em um contêiner do Docker.

Você pode especificar o executor para cada trabalho em um fluxo de trabalho usando runs-on. Para obter mais informações sobre runs-on, consulte Sintaxe do fluxo de trabalho para GitHub Actions".

Usando um executor hospedado em GitHub

Você pode selecionar entre diferentes tipos e versões das máquinas de host virtuais, incluindo Lixnux, Windows e macOS. Cada trabalho em um fluxo de trabalho é executado em uma instância nova do ambiente virtual e as etapas dentro de cada trabalho podem compartilhar informações usando o sistema do arquivo. Para obter mais informações, consulte "Ambientes virtuais para executores hospedados em GitHub Actions".

Por exemplo, você pode usar ubuntu-latest para especificar a última versão de um executor hospedado em GitHub do Ubuntu.

runs-on: ubuntu-latest

Usando um executor auto-hospedado

Você pode usar etiquetas para rotear trabalhos para tipos específicos de executores auto-hospedados. Todos os executores auto-hospedados recebem a etiqueta auto-hospedado e cada executor auto-hospedado tem etiquetas para seu sistema operacional e arquitetura de sistema. Para obter mais informações, consulte "Usando executores auto-hospedados em um fluxo de trabalho".

Por exemplo, se você adicionasse um executor auto-hospedado com um sistema operacional Linux e arquitetura ARM32, você poderia selecionar esse executor usando as etiquetas auto-hospedado, linux, e ARM32.

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.

Uma matriz de criação permite que você teste o seu código com diferentes configurações de software e de sistemas operacionais. 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 compilaçã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 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]

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@v2

Usar v2 neste exemplo garante que você esteja usando uma versão estável da ação de checkout. 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".

You can also enable Atualizações de versão do GitHub Dependabot for the actions that you add to your workflow. For more information, see "Keeping your actions up to date with GitHub Dependabot."

For more detailed configuration options, see "Workflow syntax for 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@v2
      # 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 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.

If your workflow uses the name keyword, you must reference the workflow by name. 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

Alternatively, if your workflow doesn't have a name, you must reference the workflow file using the file path relative to the repository's root directory.

Note: Referencing the workflow file using the file path does not work if the workflow has a name.

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

Você conseguiu encontrar o que estava procurando?

Pergunte a uma pessoa

Não consegue encontrar o que procura?

Entrar em contato