Skip to main content
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.

Sobre fluxos de trabalho

Obtenha uma visão geral de alto nível dos fluxos de trabalho de GitHub Actions, incluindo gatilhos, sintaxe e funcionalidades avançadas.

Sobre fluxos de trabalho

Um fluxo de trabalho é um processo automatizado configurável que executa um ou mais trabalhos. Os fluxos de trabalho são definidos por um arquivo YAML verificado no seu repositório e será executado quando acionado por um evento no repositório, ou eles podem ser acionados manualmente ou de acordo com um cronograma definido.

Os fluxos de travalho são definidos no diretório .github/workflows em um repositório, e um repositório pode ter vários fluxos de trabalho, cada um deles pode executar um conjunto diferente de tarefas. Por exemplo, você pode ter um fluxo de trabalho para criar e testar pull requests, outro fluxo de trabalho para implantar seu aplicativo toda vez que uma versão for criada, e outro fluxo de trabalho que adiciona uma etiqueta toda vez que alguém abre um novo problema.

Noções básicas do fluxo de trabalho

Um fluxo de trabalho deve conter os seguintes componentes básicos:

  1. Um ou mais eventos que acionarão o fluxo de trabalho.
  2. Um ou mais trabalhos, cada uma das quais será executado em uma máquina de executor e executará uma série de uma ou mais etapas.
  3. Cada etapa pode executar um script que você define ou executa uma ação, que é uma extensão reutilizável que pode simplificar seu fluxo de trabalho.

Para obter mais informações sobre esses componentes básicos, consulte "Entendendo GitHub Actions".

Visão geral do fluxo de trabalho

Acionando um fluxo de trabalho

Os acionadores de fluxo de trabalho são eventos que fazem com que um fluxo de trabalho seja executado. Esses eventos podem ser:

  • Eventos que ocorrem no repositório do fluxo de trabalho
  • Eventos que ocorrem fora de GitHub Enterprise Server e acionam um evento repository_dispatch em GitHub Enterprise Server
  • Horários agendados
  • Manual

Por exemplo, você pode configurar o fluxo de trabalho para executar quando um push é feito no branch padrão do seu repositório, quando uma versão é criada, ou quando um problema é aberto.

Para obter mais informações, consulte "Acionando um workflow" e para obter uma lista completa de eventos, consulte "Eventos que acionam fluxos de trabalho".

Sintaxe de fluxo de trabalho

O fluxo de trabalho é definido usando YAML. Para a referência completa da sintaxe do YAML para autorizar fluxos de trabalho, consulte "Sintaxe no fluxo de trabalho para o GitHub Actions".

Criar um exemplo de fluxo de trabalho

GitHub Actions usa a sintaxe do YAML para definir o fluxo de trabalho. Each workflow is stored as a separate YAML file in your code repository, in a directory named .github/workflows.

Você pode criar um exemplo de fluxo de trabalho no repositório que aciona automaticamente uma série de comandos sempre que o código for carregado. In this workflow, GitHub Actions checks out the pushed code, installs the bats testing framework, and runs a basic command to output the bats version: bats -v.

  1. No seu repositório, crie o diretório .github/workflows/ para armazenar seus arquivos do fluxo de trabalho.

  2. No diretório .github/workflows/, crie um novo arquivo denominado learn-github-actions.yml e adicione o código a seguir.

    name: learn-github-actions
    on: [push]
    jobs:
      check-bats-version:
        runs-on: ubuntu-latest
        steps:
          - uses: actions/checkout@v2
          - uses: actions/setup-node@v2
            with:
              node-version: '14'
          - run: npm install -g bats
          - run: bats -v
    
  3. Faça commit dessas alterações e faça push para o seu repositório do GitHub.

Seu novo arquivo de fluxo de trabalho de GitHub Actions agora está instalado no seu repositório e será executado automaticamente toda vez que alguém fizer push de uma alteração no repositório. To see the details about a workflow's execution history, see "Viewing the activity for a workflow run."

Entender o arquivo de fluxo de trabalho

Para ajudar você a entender como a sintaxe de YAML é usada para criar um arquivo de fluxo de trabalho, esta seção explica cada linha do exemplo Introdução:

name: learn-github-actions
Opcional - Como o nome do fluxo de trabalho irá aparecer na aba Ações do repositório de GitHub.
on: [push]
Especifica o gatilho para este fluxo de trabalho. Este exemplo usa o evento push para que a execução de um fluxo de trabalho seja acionada toda vez que alguém fizer push de uma alteração no repositório ou merge de um pull request. This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "Workflow syntax for GitHub Actions."
jobs:
Agrupa todos os trabalhos executados no fluxo de trabalho learn-github-actions.
check-bats-version:
Define uma tarefa chamada check-bats-version. As chaves secundaárias definirão as propriedades do trabalho.
  runs-on: ubuntu-latest
Configura o trabalho a ser executado na versão mais recente de um executor do Linux do Ubuntu. Isto significa que o trabalho será executado em uma nova máquina virtual hospedada pelo GitHub. For syntax examples using other runners, see "Workflow syntax for GitHub Actions."
  steps:
Agrupa todos os passos são executados no trabalho check-bats-version. Cada item aninhado nesta seção é uma ação separada ou script do shell.
    - uses: actions/checkout@v2
A palavra-chave usa especifica que esta etapa irá executar v3 da ação actions/checkout. Esta é uma ação que faz o check-out do seu repositório para o executor, permitindo que você execute scripts ou outras ações com base no seu código (como ferramentas de compilação e teste). Você deve usar a ação de checkout sempre que o fluxo de trabalho for executado no código do repositório.
    - uses: actions/setup-node@v2
      with:
        node-version: '14'
Essa etapa usa a ação de actions/setup-node@v2 para instalar a versão especificada do Node.js (este exemplo usa v14). Isso coloca os dois comandos e npm no seu PATH.
    - run: npm install -g bats
A palavra-chave executar diz ao trabalho para executar um comando no executor. Neste caso, você está usando o npm para instalar o pacote de teste do software bats.
    - run: bats -v
Por fim, você executará o comando bats com um parâmetro que produz a versão do software.

Visualizar o arquivo de fluxo de trabalho

Neste diagrama, você pode ver o arquivo de fluxo de trabalho que acabou de criar e como os componentes de GitHub Actions estão organizados em uma hierarquia. Cada etapa executa uma única ação ou script do shell. As etapas 1 e 2 executam ações, enquanto as etapas 3 e 4 executam scripts de shell. Para encontrar mais ações pré-criadas para seus fluxos de trabalho, consulte "Encontrar e personalizar ações".

Visão geral do fluxo de trabalho

Viewing the activity for a workflow run

When your workflow is triggered, a workflow run is created that executes the workflow. After a workflow run has started, you can see a visualization graph of the run's progress and view each step's activity on GitHub.

  1. No your GitHub Enterprise Server instance, navegue até a página principal do repositório.

  2. No nome do seu repositório, clique em Ações.

    Acesse o repositório

  3. Na barra lateral esquerda, clique no fluxo de trabalho que deseja ver.

    Captura de tela dos resultados do fluxo de trabalho

  4. Em "Execuções do fluxo de trabalho", clique no nome da execução que você deseja ver.

    Captura de tela das execuções do fluxo de trabalho

  5. Em Trabalhos ou no gráfico de visualização, clique no trabalho que você deseja ver.

    Selecionar trabalho

  6. Visualizar os resultados de cada etapa.

    Captura de tela dos detalhes de execução do fluxo de trabalho

Para mais ao gerenciar execuções do fluxo de trabalho, como re-executar, cancelar ou excluir a execução de um fluxo de trabalho, consulte "Gerenciando execuções do fluxo de trabalho".

Usando fluxos de trabalho iniciais

GitHub provides preconfigured starter workflow that you can customize to create your own continuous integration workflow. GitHub Enterprise Server analyzes your code and shows you CI starter workflow that might be useful for your repository. Por exemplo, se o seu repositório contiver o código Node.js, você verá sugestões para projetos Node.js. You can use starter workflow as a starting place to build your custom workflow or use them as-is.

You can browse the full list of starter workflow in the actions/starter-workflows repository on your GitHub Enterprise Server instance.

Para obter mais informações sobre como usar e criar fluxos de trabalho iniciais, consulte "Usando um fluxo de trabalho inicial" e "Criando fluxos de trabalho iniciais para a sua organização".

Recursos avançados de fluxo de trabalho

Esta seção descreve brevemente algumas das funcionalidades avançadas de GitHub Actions que ajudam você a criar fluxos de trabalho mais complexos.

Armazenar segredos

Se os seus fluxos de trabalho usarem dados confidenciais, como senhas ou certificados, você pode salvá-los em GitHub como segredos e usá-los nos seus fluxos de trabalho como variáveis de ambiente. Isso significa que você poderá criar e compartilhar fluxos de trabalho sem ter que incorporar valores sensíveis diretamente na fonte do YAML do fluxo de trabalho.

O exemplo desse trabalho demonstra como fazer referência a um segredo existente como uma variável de ambiente e enviá-lo como um parâmetro para um comando de exemplo.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

Para obter mais informações, consulte "Segredos criptografados".

Criar trabalhos dependentes

Por padrão, os trabalhos do seu fluxo de trabalho são executadas em paralelo e ao mesmo tempo. Se você tem um trabalho que só deve ser executado após a conclusão de outro trabalho, você pode usar a palavra-chave needs para criar esta dependência. Se um dos trabalhos falhar, todos os trabalhos dependentes serão suprimidos. No entanto, se você precisa que os trabalhos continuem, você pode definir isso usando a declaração condicional se.

Neste exemplo, os trabalhos de configuração, criação e teste executados em série, com criação e teste sendo dependentes da conclusão bem-sucedida do trabalho que os precede:

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

Para obter mais informações, consulteDefinindo trabalhos de pré-requisito".

Usando uma matriz

Uma estratégia de matriz permite usar variáveis em uma única definição de trabalho para criar automaticamente várias execuções de trabalho que são baseadas nas combinações das variáveis. Por exemplo, você pode usar uma estratégia de matriz para testar seu código em várias versões de uma linguagem ou em vários sistemas operacionais. A matriz é criada usando a palavra-chave estratégia, que recebe as opções de construção como uma matriz. Por exemplo, essa matriz irá executar o trabalho várias vezes, usando diferentes versões do Node.js:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [12, 14, 16]
    steps:
      - uses: actions/setup-node@v2
        with:
          node-version: ${{ matrix.node }}

Para obter mais informações, consulte "Usando uma matriz para seus trabalhos".

Usar bancos de dados e contêineres de serviço

Se sua tarefa exigir um banco de dados ou serviço de cache, você poderá usar a palavra-chave serviços para criar um contêiner efêmero para hospedar o serviço; o contêiner resultante ficará disponível em todas as etapas do trabalho e será removido quando o trabalho for concluído. Este exemplo demonstra como um trabalho pode usar serviços para criar um contêiner postgres e, em seguida, usar o para conectar-se ao serviço.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

Para obter mais informações, consulte "Usando serviços dentro de contêineres".

Usar etiquetas para encaminhar fluxos de trabalho

Se você quiser ter certeza de que um determinado tipo de executor irá processar seu trabalho, você pode usar etiquetas para controlar os locais onde os trabalhos são executados. Você pode atribuir etiquetas a um executor auto-hospedado, além de sua etiqueta padrão de auto-hospedado. Em seguida, você pode consultar essas etiquetas no seu fluxo de trabalho YAML, garantindo que o trabalho seja encaminhado de forma previsível. Os executores hospedados em GitHub têm etiquetas pré-definidas atribuídas.

Este exemplo mostra como um fluxo de trabalho pode usar etiquetas para especificar o executor obrigatório:

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

Um fluxo de trabalho só é executado em um executor que possui todas as etiquetas na matriz runs-on. O trabalho irá preferencialmente para um executor auto-hospedado inativo com as etiquetas especificadas.

Para aprender mais sobre etiquetas de executores auto-hospedados, consulte ""Usando etiquetas com executores auto-hospedados".

Usar ambientes

Você pode configurar ambientes com regras de proteção e segredos para controlar a execução de trabalhos no fluxo de trabalho. Cada trabalho em um fluxo de trabalho pode fazer referência a um único ambiente. Todas as regras de proteção configuradas para o ambiente têm de ser aprovadas antes que um trabalho de referência ao ambiente seja enviado a um executor. Para obter mais informações, consulte "Usando ambientes para implantação".