Como posso utilizar o GitHub Actions para criar fluxos de trabalho para CI?
Aqui, vai ficar a saber mais sobre o GitHub Actions e os fluxos de trabalho para CI.
Sabe como:
- Criar um fluxo de trabalho a partir de um modelo
- Compreender os registos do GitHub Actions
- Testar em vários destinos
- Separar tarefas de compilação e de teste
- Guardar e aceder aos artefactos
- Automatizar a etiquetagem de um pedido Pull em análise
Criar um fluxo de trabalho a partir de um modelo
Para criar um fluxo de trabalho, comece por utilizar 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 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 Escolha um fluxo de trabalho, você pode escolher entre muitos modelos diferentes. Um exemplo é o modelo Node.js , que faz uma instalação limpa das dependências do nó, cria o código-fonte e executa testes para diferentes versões do Node. Outro exemplo é o modelo de pacote 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ê esse fluxo de trabalho de modelo de Node.js padrão no node.js.yml de arquivo 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
Repare no 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.
Há um job neste fluxo de trabalho. Vamos rever o que ele faz.
O atributo runs-on: especifica que, para o sistema operativo, o fluxo de trabalho é executado no ubuntu-latest. O node-version: atributo especifica que há três compilações, uma para cada versão do nó 14.x, 16.x e 18.x. Descrevemos a matrix parte em profundidade mais tarde, quando personalizamos o fluxo de trabalho.
O steps no trabalho use a ação Ações /checkout@v3 ações do GitHub para obter o código do repositório para a VM e a ação ações/configuração node@v3 para configurar a versão correta do Node.js. Especificamos que vamos testar três versões do Node.js com o ${{ matrix.node-version }} atributo. Este atributo faz referência à matriz que definimos anteriormente. O cache atributo especifica um gerenciador de pacotes para armazenamento em cache no diretório padrão.
A última parte deste passo executa os comandos utilizados pelos projetos Node.js. O comando npm ci instala as dependências a partir do ficheiro package-lock.json, npm run build --if-present executa um script de compilação, se existir, e npm test executa a arquitetura de teste. Observe que este modelo inclui os passos de compilação e de teste na mesma tarefa.
Para saber mais sobre o npm, veja a documentação do npm:
Registo de Ações da compilação
Quando um fluxo de trabalho é executado, cria um registo que inclui os detalhes do que aconteceu e quaisquer erros ou testes com falhas.
Se houver um erro ou se um teste falhar, você verá uma marca ✔ de seleção vermelha ✖ em vez de verde nos logs. Você pode examinar os detalhes do erro ou falha em investigar o que aconteceu.
No exercício, vai identificar os testes com falhas ao examinar os detalhes nos registos. Pode aceder aos registos a partir do separador 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. Quer incluir diferentes versões do Node e diferentes sistemas operativos. Você também deseja que as etapas de compilação e teste sejam trabalhos separados.
Vamos ver como personalizar um fluxo de trabalho.
strategy:
matrix:
os: [ubuntu-latest, windows-latest]
node-version: [16.x, 18.x]
Aqui, configurámos uma matriz de compilação para testar em vários sistemas operativos e versões de linguagens. 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 um pouco de informações de log. e ordenar todas estas informações pode tornar-se difícil. No exemplo a seguir, mostramos como mover a etapa de teste para um trabalho de teste dedicado. Esta tarefa testa em vários destinos. 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 artefactos?
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 carregado para o armazenamento usando as ações de ação /upload-artifact e posteriormente baixado do armazenamento usando as ações de ação /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 artefactos são armazenados num espaço de armazenamento no GitHub. O espaço é gratuito para os repositórios públicos e tem algum espaço gratuito para os 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 actions/upload-artifact@main ação há um path: atributo. O valor desse atributo é o caminho para armazenar o artefato. Aqui, especificamos public/ 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 artefato para teste, a compilação deve ser concluída com êxito e carregou o artefato. 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, a tarefa de teste pode utilizar o artefacto para fins de 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.
Análises automáticas no GitHub com 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 em uma programação 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 só queiramos executar um fluxo de trabalho depois que um revisor aprovar a solicitação pull. Para este cenário, podemos acionar pull-request-review.
Outra ação que poderíamos realizar é adicionar uma etiqueta ao pedido Pull. Neste caso, utilizamos 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 denominado env:. Este bloco é onde você define as variáveis de ambiente para essa ação. Por exemplo, pode definir o número de aprovadores necessários. Aqui, foi apenas definido um. A secrets.GITHUB_TOKEN variável de autenticação é necessária porque a ação deve fazer alterações no repositório adicionando um rótulo. Finalmente, deverá indicar o nome da etiqueta a adicionar.
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.