Skip to main content

Esta versão do GitHub Enterprise será descontinuada em 2022-09-28. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

About workflows

Get a high-level overview of GitHub Actions workflows, including triggers, syntax, and advanced features.

About workflows

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 trabalho são definidos no diretório .github/workflows em um repositório. Um repositório pode ter vários fluxos de trabalho, cada um dos quais 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.

Workflow basics

A workflow must contain the following basic components:

  1. One or more events that will trigger the workflow.
  2. One or more jobs, each of which will execute on a runner machine and run a series of one or more steps.
  3. Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

For more information on these basic components, see "Understanding GitHub Actions."

Workflow overview

Triggering a workflow

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 do GitHub Enterprise Server e que disparam um evento repository_dispatch no 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.

For more information, see "Triggering a workflow", and for a full list of events, see "Events that trigger workflows."

Workflow syntax

Workflow are defined using YAML. For the full reference of the YAML syntax for authoring workflows, see "Workflow syntax for GitHub Actions."

Criar um exemplo de fluxo de trabalho

GitHub Actions usa a sintaxe do YAML para definir o fluxo de trabalho. Cada fluxo de trabalho é armazenado como um arquivo YAML separado no seu repositório de código, em um diretório chamado .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. Nesse fluxo de trabalho, GitHub Actions verifica o código enviado, instala a estrutura de teste bats e executa um comando básico para gerar a versão bats:bats -v.

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

  2. No diretório .github/workflows/, crie um arquivo chamado 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. Para conferir os detalhes sobre o histórico de execução de um fluxo de trabalho, confira "Exibir a atividade de uma execução de fluxo de trabalho".

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 – O nome do fluxo de trabalho, conforme ele será exibido na guia Ações do repositório do GitHub.
on: [push]
Especifica o gatilho para este fluxo de trabalho. Este exemplo usa o evento push, para que uma execução de fluxo de trabalho seja disparada sempre que alguém efetuar push de uma alteração para o repositório ou mesclar uma solicitação de pull. Isso é disparado por um push para cada branch. Para ver exemplos de sintaxe que são executados somente em pushes para branches, marcas ou caminhos específicos, confira "Sintaxe de fluxo de trabalho do GitHub Actions".
jobs:
Agrupa todos os trabalhos executados no fluxo de trabalho learn-github-actions.
check-bats-version:
Define um trabalho chamado 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. Para ver exemplos de sintaxe que usam outros executores, confira "Sintaxe de fluxo de trabalho do GitHub Actions".
  steps:
Agrupa todas as etapas que são executadas 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 uses especifica que esta etapa 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'
Esta etapa usa a ação actions/setup-node@v2 para instalar a versão especificada do Node.js (este exemplo usa a v14). Isso insere os comandos node e npm no PATH.
    - run: npm install -g bats
A palavra-chave run instrui o trabalho a executar um comando no executor. Nesse caso, você está usando npm para instalar o pacote de teste de software bats.
    - run: bats -v
Por fim, você executará o comando bats com um parâmetro que gera 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 predefinidas para seus fluxos de trabalho, confira "Como localizar e personalizar ações".

Visão geral do fluxo de trabalho

Exibir a atividade para uma execução de fluxo de trabalho

Quando seu fluxo de trabalho é acionado, é criada uma execução de fluxo de trabalho que executa o fluxo de trabalho. Após o início de uma execução de fluxo de trabalho, você pode ver um gráfico de visualização do progresso da execução e visualizar a atividade de cada etapa em GitHub.

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

  2. Abaixo do 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 grafo de visualização, clique no trabalho que deseja ver.

    Selecionar trabalho

  6. Exiba os resultados detalhados de cada etapa.

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

For more on managing workflow runs, such as re-running, cancelling, or deleting a workflow run, see "Managing workflow runs."

Using starter workflows

O GitHub fornece um fluxo de trabalho inicial pré-configurado que você pode personalizar para criar seu fluxo de trabalho de integração contínua. O GitHub Enterprise Server analisa seu código e mostra o fluxo de trabalho inicial de CI que pode ser útil para seu repositório. Por exemplo, se o seu repositório contiver o código Node.js, você verá sugestões para projetos Node.js. Você pode usar o fluxo de trabalho inicial como ponto de partida para criar seu fluxo de trabalho personalizado ou usá-lo no estado em que se encontra.

Navegue pela lista completa do fluxo de trabalho inicial no repositório actions/starter-workflows no your GitHub Enterprise Server instance.

For more information on using and creating starter workflows, see "Using starter workflows" and "Creating starter workflows for your organization."

Advanced workflow features

This section briefly describes some of the advanced features of GitHub Actions that help you create more complex workflows.

Storing secrets

If your workflows use sensitive data, such as passwords or certificates, you can save these in GitHub as secrets and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the workflow's YAML source.

This example job demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.

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

For more information, see "Encrypted secrets."

Creating dependent jobs

By default, the jobs in your workflow all run in parallel at the same time. If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement.

In this example, the setup, build, and test jobs run in series, with build and test being dependent on the successful completion of the job that precedes them:

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

For more information, see "Defining prerequisite jobs."

Using a matrix

Uma estratégia de matriz permite que você use variáveis em uma única definição de trabalho para criar automaticamente várias execuções de trabalho 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 um idioma ou em vários sistemas operacionais. The matrix is created using the strategy keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of 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 }}

For more information, see "Using a matrix for your jobs."

Using databases and service containers

If your job requires a database or cache service, you can use the services keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use services to create a postgres container, and then use node to connect to the service.

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

For more information, see "Using containerized services."

Using labels to route workflows

If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of self-hosted. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way. GitHub-hosted runners have predefined labels assigned.

This example shows how a workflow can use labels to specify the required runner:

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

A workflow will only run on a runner that has all the labels in the runs-on array. The job will preferentially go to an idle self-hosted runner with the specified labels.

To learn more about self-hosted runner labels, see "Using labels with self-hosted runners."

Using environments

You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see "Using environments for deployment."