Entendendo o Github Actions

This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.

O GitHub Actions é uma plataforma para automatizar workflows de desenvolvimento de software, ou seja, ele serve não só para implementar CI/CD, mas também para simplificar outros inúmeros processos que existem dentro do ciclo de vida do desenvolvimento de software.

Neste artigo vamos entender um pouco sobre cada componente e noções básicas para criar o primeiro workflow.

Como funciona o Github Actions?

O GitHub Actions é orientado por eventos, isso quer dizer que os workflows podem ser acionados a partir de eventos específicos que ocorrem no GitHub. Então é possível, por exemplo, executar um workflow quando alguém fizer um push de um commit para o repositório, ou então quando for criado um issue ou um pull request.

A configuração de eventos que acionam o workflow é feita utilizando o parâmetro on. Aqui temos um exemplo de um workflow configurado para ser acionado através do push de um commit:

# .github/workflows/build.yml name: Node CI on: [push]

Também é possível configurar os workflows para que sejam acionados manualmente, por eventos de webhook ou então por agendamento usando o formato Cron, para entender mais sobre a sintaxe você pode acessar https://pubs.opengroup.org.

Segue um exemplo de workflow configurado para ser disparado por agendamento:

# .github/workflows/weekly-radar.yml name: Weekly Radar on: schedule: - cron: 0 12 * * 1

Aqui você pode encontrar todos os eventos que podem disparar o workflow: https://docs.github.com/pt/actions/learn-github-actions/events-that-trigger-workflows

Workflows - Fluxos de trabalho

Os workflows, também conhecidos como fluxos de trabalho, são processos automatizados que adicionamos ao nosso repositório para executar um ou mais trabalhos (jobs). Um repositório pode ter vários workflows e cada um deles podem executar processos diferentes.

Os Workflows são definidos em arquivos YAML, e ficam dentro de uma pasta chamada .github/workflows no repositório.

Jobs - Trabalhos

Os Jobs nada mais são que conjuntos de etapas (steps) que são realizados no mesmo executor (runner).

Por padrão um workflow com vários jobs irá executar esses jobs em paralelo, mas também podemos configurar em nosso workflow para executar os jobs sequencialmente utilizando o parâmetro needs.

Steps - Etapas

Os steps são tarefas individuais que podem executar um ou mais comandos dentro de um job. Os steps podem ser Actions ou comandos shell.

Abaixo podemos ver um exemplo de um step executando uma Action para fazer a instalação da versão do Node.js, e outro step rodando os comandos npm install, build e test.

steps: - uses: actions/checkout@v1 # Exemplo de step usando Action - name: Use Node.js ${{ matrix.node-version }} uses: actions/setup-node@v1 with: node-version: ${{ matrix.node-version }} # Exemplo de step usando comando shell - name: npm install, build, and test run: | npm ci npm run build --if-present npm test env: CI: true

Actions - Ações

As Actions são comandos independentes, e geralmente executam alguma tarefa que é realizada repetidas vezes nos arquivos de workflow. As Actions foram feitas para serem reutilizáveis, então é possível utilizá-las em vários workflows. Dessa forma, ela ajuda a reduzir significativamente a quantidade de código repetitivo que você escreve em seus arquivos de workflow.
Você pode encontrar Actions já existentes no GitHub Marketplace, ou também pode criar suas próprias Actions e publicá-las no Marketplace.

Para saber mais sobre a criação de Actions você pode acessar: https://docs.github.com/pt/actions/creating-actions

Runner - Executores

Os runners são servidores que tem o aplicativo de runner do GitHub Actions instalado, eles são responsáveis por executar os workflows quando acionados. É possível usar um runner hospedado do GitHub, que podem ser: Linux, Windows ou MacOs. Mas também é possível hospedar o nosso próprio runner.

Se quiser saber mais sobre os runners auto-hospedados pode acessar: https://docs.github.com/en/actions/hosting-your-own-runners

Para configurarmos o runner no nosso workflow, utilizamos o parâmetro runs-on. No exemplo abaixo temos um workflow configurado para rodar o job de build em um runner com a última versão do ubuntu:

# .github/workflows/build.yml name: Node CI on: [push) jobs: build: name: Build runs-on: ubuntu-latest

Criando o primeiro workflow

Agora vamos para um exemplo prático bem simples utilizando o Github Actions:
Tenho uma aplicação ASP.NET no meu repositório, e gostaria de criar um workflow para disparar um build sempre que um Pull Request for executado na master.

Dentro do repositório da aplicação nós temos a aba Actions, onde é possível encontrarmos algumas sugestões de templates de workflow para começarmos a configurar nosso build.

Mas hoje começaremos o workflow do zero, clicando em set up a workflow yourself.

Primeiro, iremos dar um nome ao nosso Workflow. Essa parte não é obrigatória, mas é importante para conseguirmos visualizar e organizar melhor os nossos workflows:

name: Build ASP.NET

Vamos utilizar o parâmetro on para configurar o evento que irá disparar o nosso workflow, nesse caso será um Pull request na branch master:

name: Build ASP.NET on: pull_request: branches: [ master ]

Agora vamos ao trabalho!

Nosso Job irá executar o build da aplicação utilizando a versão mais recente do ubuntu. Para isso, iremos definir o runner usando o parâmetro runs-on:

name: Build ASP.NET on: pull_request: branches: [ master ] jobs: build: name: Build runs-on: ubuntu-latest

Por fim, definimos cada etapa que o nosso build deve realizar utilizando o parâmetro steps, e vamos colocar as etapas para a publicação do artefato. Assim, quando formos fazer o deploy da nossa aplicação, conseguiremos utilizar o artefato que foi gerado nesse build.

steps: - uses: actions/checkout@v2 - name: Setup .NET uses: actions/setup-dotnet@v1 with: dotnet-version: 5.0.x - name: Install dependencies run: dotnet restore - name: Build run: dotnet build --configuration Release --no-restore - name: dotnet publish run: dotnet publish -c Release -o ./output - name: Upload Artifact uses: actions/upload-artifact@v1 with: name: artifact path: output/

Agora nosso workflow está pronto!!

Ele deve ficar assim:

name: Build ASP.NET on: pull_request: branches: [ master ] jobs: build: name: Build runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - name: Setup .NET uses: actions/setup-dotnet@v1 with: dotnet-version: 5.0.x - name: Install dependencies run: dotnet restore - name: Build run: dotnet build --configuration Release --no-restore - name: dotnet publish run: dotnet publish -c Release -o ./output - name: Upload Artifact uses: actions/upload-artifact@v1 with: name: artifact path: output/

Após a criação do PR e execução do workflow, esse foi o resultado: