Como faço para usar as Ações do GitHub para criar fluxos de trabalho para CI?
Aqui, você aprende sobre as ações do GitHub e fluxos de trabalho para CI.
Você aprende a:
- Criar um fluxo de trabalho a partir de um modelo
- Compreender os logs de ações do GitHub
- Testar contra múltiplos objetivos
- Separe os trabalhos de compilação e teste
- Salvar e acessar artefatos de construção
- Automatize a rotulagem de um RP na revisão
Criar um fluxo de trabalho a partir de um modelo
Para criar um fluxo de trabalho, comece usando um modelo. Um modelo tem trabalhos e etapas comuns pré-configurados para o tipo específico de automação que você está implementando. Se você não estiver familiarizado com fluxos de trabalho, trabalhos e etapas, confira o módulo Automatizar tarefas de desenvolvimento usando o módulo Ações do GitHub.
Na página principal do repositório, selecione a guia Ações e, em seguida, selecione Novo fluxo de trabalho.
Na página Escolher um fluxo de trabalho, pode-se escolher entre muitos modelos diferentes. Um exemplo é o modelo Node.js, que faz uma instalação limpa das dependências do Node, compila o código-fonte e executa testes para diferentes versões do Node. Outro exemplo é o modelo de de pacotes Python, que instala dependências 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ê este modelo de fluxo de trabalho padrão Node.js, no novo arquivo node.js.yml recém-criado.
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 é acionado em um push para o repositório e quando uma solicitação pull é feita em relação à ramificação principal.
Neste fluxo de trabalho, há um job. Vamos rever o que 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 existem três compilações, uma para cada versão do Node 14.x, 16.x, e 18.x. Descrevemos a parte matrix em profundidade mais tarde, quando personalizamos o fluxo de trabalho.
Os steps no trabalho utilizam a GitHub Actions ações/checkout@v3 para obter o código do seu repositório na VM, e a ação ações/setup-node@v3 para configurar a versão correta de Node.js. Especificamos que vamos testar três versões do Node.js com o atributo ${{ matrix.node-version }}. Este 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 dependências do arquivo package-lock.json, npm run build --if-present executa um script de construção, se existir, e npm test executa a estrutura de teste. Observe que esse modelo inclui as etapas de compilação e teste no mesmo trabalho.
Para saber mais sobre o npm, confira a documentação do npm:
- npm instalar
- npm executar
- de teste npm
Logs de ação para a compilação
Quando um fluxo de trabalho é executado, ele produz um log que inclui os detalhes do que aconteceu e quaisquer erros ou falhas de teste.
Se houver um erro ou se um teste falhar, ver-se-á um ✖ vermelho em vez de uma marca ✔ verde nos logs. Você pode examinar os detalhes do erro ou falha em investigar o que aconteceu.
No exercício, identifica os testes falhados analisando os detalhes nos registos. Você pode acessar os logs na guia Ações.
Personalizar modelos de fluxo de trabalho
No início deste módulo, descrevemos um cenário onde você precisa configurar o CI para sua equipe. O modelo Node.js é um ótimo começo, mas você quer personalizá-lo para melhor atender às necessidades da sua própria equipe. Você deseja direcionar diferentes versões do Node e diferentes sistemas operacionais. Você também deseja que as etapas de compilação e teste sejam trabalhos separados.
Vamos dar uma olhada em como você personaliza um fluxo de trabalho.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Aqui, configuramos uma matriz de construção para testes em vários sistemas operacionais e versões de idioma. Essa matriz produz quatro compilações, uma para cada sistema operacional emparelhado com cada versão do Node.
Quatro compilações, juntamente com todos os seus testes, produzem uma quantidade considerável de informação de log. Pode ser difícil resolver tudo. No exemplo a seguir, mostramos como mover a etapa de teste para um trabalho de teste dedicado. Este trabalho testa em relação a múltiplas metas. Separar as etapas de compilação e teste facilita a compreensão 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, a compilação Node.js produz um contêiner do Docker que pode ser implantado. Esse artefato, o contêiner, pode ser enviado para o armazenamento usando a ação actions/upload-artifact e posteriormente descarregado do armazenamento usando a ação actions/download-artifact.
O armazenamento de um artefato o preserva entre os trabalhos. Cada trabalho usa uma nova instância de uma máquina virtual (VM), portanto, você não pode reutilizar o artefato salvando-o na VM. Se você precisar de seu artefato em um trabalho diferente, você pode carregar o artefato para armazenamento em um trabalho e baixá-lo para o outro trabalho.
Armazenamento de artefactos
Os artefatos são armazenados no espaço de armazenamento no GitHub. O espaço é gratuito para repositórios públicos e algum valor é gratuito para repositórios privados, dependendo da conta. O GitHub armazena seus artefatos por 90 dias.
No trecho de fluxo de trabalho a seguir, observe que na ação actions/upload-artifact@main há um atributo path:. O valor desse atributo é o caminho para armazenar o artefato. Aqui, especificamos público/ para carregar tudo para um diretório. Se quiséssemos apenas carregar um único ficheiro, usávamos 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 artefacto para teste, a compilação deve ser concluída com êxito e o artefacto deve ser 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 de 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, consulte Armazenando dados do fluxo de trabalho como artefatos na documentação do GitHub.
Automatize revisões no GitHub usando fluxos de trabalho
Até agora, descrevemos iniciar o fluxo de trabalho com eventos do GitHub, como push ou pull-request. Também podemos executar um fluxo de trabalho num calendário ou a partir de um evento fora do GitHub.
Às vezes, queremos executar o fluxo de trabalho somente depois que uma pessoa executa uma ação. Por exemplo, talvez só queiramos executar um fluxo de trabalho depois que um revisor aprovar a solicitação pull. Para este cenário, podemos acionar em pull-request-review.
Outra ação que poderíamos tomar é adicionar um rótulo ao pull request. Neste 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:. Este 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. Aqui, é um só. A variável de autenticação secrets.GITHUB_TOKEN é necessária porque a ação deve fazer alterações no repositório adicionando um rótulo. Finalmente, você fornece 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. Abordamos este evento no próximo módulo sobre entrega contínua com o GitHub Actions.