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:
