Como Configurar e Correr GitHub Actions

O GitHub Actions é uma ferramenta integrada no GitHub que permite automatizar tarefas como testes, builds e deploys. A grande vantagem é que tudo acontece dentro do próprio repositório, sem necessidade de configurar servidores externos ou instalar ferramentas adicionais. Com alguns ficheiros YAML, consegues criar pipelines de integração e entrega contínua que garantem qualidade e consistência no teu código.

Para começar, é preciso criar a pasta .github/workflows no repositório. Dentro dessa pasta ficam os ficheiros que descrevem os workflows. Cada workflow é escrito em YAML e define três coisas principais: quando deve correr, o que deve fazer e como deve executar cada passo. Os eventos determinam quando o workflow é disparado, por exemplo, sempre que há um push ou um pull request. Os jobs agrupam tarefas que podem correr em paralelo ou em sequência. E dentro de cada job, os steps descrevem comandos ou ações individuais.

Criar o Primeiro Workflow

1. No repositório, cria a pasta .github/workflows.
2. Adiciona um ficheiro, por exemplo ci.yml.
3. Define o conteúdo do workflow.

# This workflow will build a .NET project
# For more information see: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-net

name: .NET

on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v4

    - name: Setup .NET
      uses: actions/setup-dotnet@v4
      with:
        dotnet-version: '8.0.x'

    - name: Restore dependencies
      run: dotnet restore

    - name: Build
      run: dotnet build --configuration Release --no-restore

    - name: Test
      run: dotnet test --configuration Release --verbosity normal

Passos do job

1. Checkout do código. Usa a ação actions/checkout@v4 para trazer o conteúdo do repositório para dentro da máquina virtual. Sem isto, não haveria acesso ao código.
2. Setup .NET Configura o ambiente .NET com a versão 8.0.x usando actions/setup-dotnet@v4. Isto garante que os comandos dotnet vão funcionar com a versão correta.
3. Restaurar dependências Corre dotnet restore, que baixa e prepara todas as bibliotecas necessárias definidas nos ficheiros .csproj ou .sln.
4. Build da solução Executa dotnet build --configuration Release --no-restore. Isto compila o projeto em modo Release, mas sem restaurar dependências novamente (porque já foram restauradas no passo anterior).
5. Testes Finalmente, corre dotnet test --configuration Release --verbosity normal. Isto executa todos os testes definidos na solução Zesty.sln, também em modo Release, e mostra os resultados com detalhe normal.

Depois de configurar o workflow, basta ir à aba Actions no GitHub para acompanhar a execução. Ali encontras todos os workflows que correram, com logs detalhados de cada passo. Se algo falhar, os logs ajudam a identificar rapidamente o problema. Esta visibilidade é fundamental para perceber se o pipeline está a funcionar como esperado.

À medida que o projeto cresce, podes expandir o workflow para incluir mais tarefas. É comum adicionar linting para verificar a qualidade do código, criar builds antes de correr testes ou configurar deploys automáticos para staging e produção. Também é possível agendar workflows para correr em horários fixos, como por exemplo todos os dias à meia-noite, usando a sintaxe de cron. Esta flexibilidade permite adaptar o GitHub Actions às necessidades específicas de cada equipa ou projeto.

Conclusão

Em resumo, o GitHub Actions é uma forma rápida e prática de automatizar o ciclo de desenvolvimento. Com apenas um ficheiro YAML, consegues garantir que o código é testado e preparado sempre que alguém faz alterações. E à medida que o projeto evolui, podes escalar para pipelines mais complexos que cobrem todo o ciclo de vida da aplicação, desde a validação inicial até ao deploy final. Este é um ficheiro inicial que podes copiar para usar nos teus projectos e por sua vez evoluir ao longo do tempo. Neste momento apenas temos integração contínua (CI), no futuro vamos incluir a entrega contínua (CD), mas primeiro vamos configurar um local runner para poder publicar o projecto localmente.