Como usar o GitHub Actions para criar fluxos de trabalho para CI?
Aqui, você aprende sobre o GitHub Actions e os fluxos de trabalho para CI.
Você aprenderá como:
- Criar um fluxo de trabalho com base em um modelo
- Entender os logs do GitHub Actions
- Testar em relação a vários destinos
- Separar trabalhos de build e de teste
- Salvar e acessar artefatos de compilação
- Automatizar a rotulação de um PR em revisão
Criar um fluxo de trabalho com base em um modelo
Para criar um fluxo de trabalho, comece usando um modelo. Um modelo tem etapas e trabalhos comuns pré-configurados para o tipo específico de automação que você está implementando. Se você não tiver familiaridade com os fluxos de trabalho, os trabalhos e as etapas, confira o módulo Automatizar tarefas de desenvolvimento usando o GitHub Actions.
Na página principal do repositório, selecione a guia Ações e selecione Novo fluxo de trabalho.
Na página Escolher um fluxo de trabalho, você pode escolher entre vários modelos diferentes. Um exemplo é o modelo Node.js, que faz uma instalação limpa de dependências de nó, cria o código-fonte e executa testes para versões diferentes do Node. Outro exemplo é o pacote Python modelo, que instala dependências do Python e executa testes, incluindo lint, em diferentes versões do Python.
Na caixa de pesquisa, digite Node.js.
Nos resultados da pesquisa, no painel Node.js, selecione Configurar.
Você vê esse fluxo de trabalho padrão do modelo Node.js, no arquivo recém-criado node.js.yml.
name: Node.js CI
on:
push:
branches: [ "main" ]
pull_request:
branches: [ "main" ]
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [14.x, 16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Observe o atributo on:. Esse fluxo de trabalho é disparado em um push para o repositório, bem como quando uma solicitação de pull é feita na ramificação principal.
Há um job neste fluxo de trabalho. Vamos examinar o que ele faz.
O atributo runs-on: especifica que, para o sistema operacional, o fluxo de trabalho é executado em ubuntu-latest. O atributo node-version: especifica que há três builds, um para cada versão do Node, 14.x, 16.x e 18.x. Descrevemos a parte matrix detalhadamente mais tarde, quando personalizarmos o fluxo de trabalho.
O steps no trabalho usa a ação actions/checkout@v3 do GitHub Actions para obter o código do seu repositório na VM e a ação actions/setup-node@v3 para configurar a versão correta do Node.js. Especificamos que vamos testar três versões do Node.js com o atributo ${{ matrix.node-version }}. Esse atributo faz referência à matriz que definimos anteriormente. O atributo cache especifica um gerenciador de pacotes para armazenamento em cache no diretório padrão.
A última parte desta etapa executa comandos usados por projetos Node.js. O comando npm ci instala as dependências do arquivo package-lock.json, npm run build --if-present executa um script de build, se existir, e npm test executa a estrutura de teste. Observe que esse modelo inclui as etapas de build e de teste no mesmo trabalho.
Para saber mais sobre o npm, confira a documentação do npm:
Logs de Ações para o build
Quando um fluxo de trabalho é executado, ele produz um log que inclui os detalhes do que aconteceu e todos os erros ou falhas de teste.
Se houver um erro ou se um teste falhar, você verá um ✖ vermelho em vez de uma marca de seleção verde ✔ nos logs. Você pode examinar os detalhes do erro ou da falha para investigar o que deu errado.
No exercício, você identifica os testes com falha examinando os detalhes nos logs. Você pode acessar os logs na guia Ações.
Personalizar os modelos de fluxo de trabalho
Lembre-se de que, no início deste módulo, descrevemos um cenário em que você precisa configurar a CI para a sua equipe. O modelo Node.js é um ótimo começo, mas é preferível personalizá-lo para atender melhor aos requisitos da sua equipe. Você deseja direcionar para versões diferentes do Node e sistemas operacionais diferentes. Você também deseja que as etapas de build e teste sejam trabalhos separados.
Vamos dar uma olhada em como personalizar um fluxo de trabalho.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Aqui, configuramos uma matriz de build para teste em vários sistemas operacionais e versões de idioma. Essa matriz produz quatro builds, uma para cada sistema operacional emparelhada com cada versão do Node.
Quatro builds junto com todos os testes deles produzem muitas informações de log. Pode ser difícil classificar tudo isso. No exemplo a seguir, mostramos como mover a etapa de teste para um trabalho de teste dedicado. Esse trabalho testa em relação a vários destinos. Realizar as etapas de build e de teste separadamente facilita o entendimento do log.
test:
runs-on: ${{ matrix.os }}
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
steps:
- uses: actions/checkout@v3
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v3
with:
node-version: ${{ matrix.node-version }}
- name: npm install, and test
run: |
npm install
npm test
env:
CI: true
O que são artefatos?
Quando um fluxo de trabalho produz algo diferente de uma entrada de log, o produto é chamado de artefato. Por exemplo, o build do Node.js produz um contêiner do Docker que pode ser implantado. Esse artefato, o contêiner, pode ser carregado no armazenamento usando a ação actions/upload-artifact e posteriormente baixado no armazenamento usando a ação actions/download-artifact.
Armazenar um artefato preserva-o entre trabalhos. Cada trabalho usa uma instância nova de uma VM (máquina virtual), portanto, você não pode reutilizar o artefato salvando-o na VM. Se precisar do artefato em um trabalho diferente, você poderá carregá-lo no armazenamento em um trabalho e baixá-lo para o outro trabalho.
Armazenamento de artefatos
Os artefatos são armazenados no espaço de armazenamento no GitHub. O espaço é gratuito para repositórios públicos e alguma quantia é gratuita para repositórios particulares, dependendo da conta. O GitHub armazena os artefatos por 90 dias.
No trecho do fluxo de trabalho a seguir, observe que há um atributo path: na ação actions/upload-artifact@main. O valor desse atributo é o caminho para armazenar o artefato. Aqui, especificamos public/ para carregar tudo em um diretório. Se desejarmos carregar apenas um arquivo, usaremos algo como público/mytext.txt.
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: npm install and build webpack
run: |
npm install
npm run build
- uses: actions/upload-artifact@main
with:
name: webpack artifacts
path: public/
Para baixar o artefato para teste, a compilação precisa ter sido concluída com êxito e o artefato ter sido carregado. No código a seguir, especificamos que o trabalho de teste depende do trabalho de compilação.
test:
needs: build
runs-on: ubuntu-latest
No trecho do fluxo de trabalho a seguir, baixamos o artefato. Agora, o trabalho de teste pode usar o artefato para teste.
steps:
- uses: actions/checkout@v3
- uses: actions/download-artifact@main
with:
name: webpack artifacts
path: public
Para obter mais informações sobre como usar artefatos em fluxos de trabalho, confira Manter dados de fluxo de trabalho usando artefatos na documentação do GitHub.
Automatizar revisões no GitHub usando fluxos de trabalho
Até agora, descrevemos como iniciar o fluxo de trabalho com eventos do GitHub, como push ou pull-request. Também poderíamos executar um fluxo de trabalho em uma agenda ou em algum evento fora do GitHub.
Às vezes, queremos executar o fluxo de trabalho somente depois que uma pessoa executa uma ação. Por exemplo, talvez queiramos apenas executar um fluxo de trabalho depois que um revisor aprovar a solicitação de pull. Para esse cenário, podemos disparar em pull-request-review.
Outra ação que podemos executar é adicionar um rótulo à solicitação pull. Nesse caso, usamos a ação pullreminders/label-when-approved-action.
steps:
- name: Label when approved
uses: pullreminders/label-when-approved-action@main
env:
APPROVALS: "1"
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
ADD_LABEL: "approved"
Observe o bloco chamado env:. Esse bloco é onde você define as variáveis de ambiente para essa ação. Por exemplo, você pode definir o número de aprovadores necessários. Nesse caso, o número é um. A variável de autenticação secrets.GITHUB_TOKEN é necessária porque a ação precisa fazer alterações no seu repositório adicionando um rótulo. Por fim, forneça o nome do rótulo a ser adicionado.
Adicionar um rótulo pode ser um evento que inicia outro fluxo de trabalho, como uma mesclagem. Abordaremos esse evento no próximo módulo sobre entrega contínua com o GitHub Actions.