Erick Gabriel dos Santos Alves

Posted on Aug 3

A Conta Chegou? Como Fugir do Limite de 2.000 Minutos do GitHub Actions (Parte 2)

#github #devops #infrastructure #tutorial

No episódio anterior desta série, nós configuramos um pipeline incrível que compila e testa nossa aplicação Full-Stack (Angular e .NET) em paralelo a cada push. A sensação de ver tudo verde e o deploy acontecendo sozinho é indescritível.

Mas então, o projeto cresce. A equipe começa a mandar dezenas de Pull Requests por dia. O tempo de build aumenta. E de repente, você recebe aquele e-mail assustador do GitHub: "You have used 100% of your included Action minutes".

A lua de mel com a automação acabou. A conta chegou.

No artigo de hoje, vamos resolver esse problema pela raiz. Vou te ensinar a configurar um Self-Hosted Runner: um jeito de fazer o GitHub rodar o seu pipeline de graça usando a sua própria máquina (ou uma VPS de 5 dólares).

O Problema dos 2.000 Minutos

Se o seu repositório for público (Open Source), o GitHub Actions é 100% gratuito e ilimitado. Porém, se o seu repositório for privado (o que é o caso de 99% dos projetos de empresas e startups), o GitHub te dá uma cota de 2.000 minutos por mês no plano gratuito.

Parece muito, mas faça as contas:

Seu build de Angular demora 2 minutos.
Seu build e testes de .NET demoram 3 minutos.
Total: 5 minutos por execução.
Com 20 pushes por dia em uma equipe média, você queima 100 minutos por dia. Em 20 dias úteis, sua cota zerou.

Depois disso, o GitHub começa a cobrar por minuto excedente, e a fatura em dólar pode assustar.

A Solução: Self-Hosted Runners

Por padrão, quando escrevemos runs-on: ubuntu-latest no nosso arquivo YAML, estamos alugando uma máquina virtual dos servidores da Microsoft/GitHub para rodar nossos comandos.

Um Self-Hosted Runner é um agente (um programinha) que você instala em um computador seu. Ele fica ouvindo o GitHub e diz: "Ei, não precisa alugar uma máquina. Pode mandar os comandos pra cá que eu executo localmente!".

Vantagens:

Fim do limite de minutos (você roda quantas vezes quiser de graça).
Você pode usar uma máquina muito mais potente que a do GitHub.
O agente pode acessar seu banco de dados local ou sua rede interna com facilidade.

Mão na Massa: Criando o seu Runner

Vamos configurar um runner na sua própria máquina para testes (o processo é idêntico se você for fazer em uma VPS Linux na nuvem).

Passo 1: Gerando o Token no GitHub

Vá até o seu repositório no GitHub.
Clique em Settings > Actions > Runners (na barra lateral esquerda).
Clique no botão verde New self-hosted runner.
Escolha o Sistema Operacional da máquina onde você vai instalar o agente (Linux, Windows ou macOS).

O GitHub vai gerar uma tela com vários comandos prontos. É só copiar e colar no seu terminal.

Passo 2: Instalando o Agente (Exemplo em Linux/WSL)

Abra o seu terminal e cole os comandos fornecidos pelo GitHub. Geralmente, eles se parecem com isso:

# 1. Cria uma pasta para o runner e entra nela
mkdir actions-runner && cd actions-runner

# 2. Baixa o pacote do runner
curl -o actions-runner-linux-x64-2.311.0.tar.gz -L [https://github.com/actions/runner/releases/download/](https://github.com/actions/runner/releases/download/)...

# 3. Extrai os arquivos
tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz

# 4. Configura o runner e vincula ao seu repositório (O GitHub já coloca seu token aqui automaticamente)
./config.sh --url [https://github.com/SEU_USUARIO/SEU_REPOSITORIO](https://github.com/SEU_USUARIO/SEU_REPOSITORIO) --token ABCD1234EFGH5678

Durante a configuração, ele vai pedir um nome para o seu runner. Pode dar Enter para aceitar o padrão ou chamar de meu-servidor-01.

Passo 3: Ligando o Motor

Para ligar o agente, basta rodar:

./run.sh

Você verá a mensagem: Connected to GitHub e Listening for Jobs. Pronto! Sua máquina agora é uma extensão oficial do GitHub.

Atualizando o seu YAML (A Mágica Acontece)

Agora precisamos dizer para o nosso pipeline da Parte 1 parar de usar as máquinas pagas do GitHub e começar a usar a nossa.

Abra o seu arquivo .github/workflows/main.yml. Vá nos seus jobs e troque a linha runs-on: ubuntu-latest por runs-on: self-hosted.

Veja como fica:

jobs:
  build-frontend:
    name: Build Angular App
    # A MÁGICA ESTÁ AQUI 👇
    runs-on: self-hosted
    defaults:
      run:
        working-directory: ./frontend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # ... resto dos passos iguais ...

  build-backend:
    name: Build & Test .NET API
    # A MÁGICA ESTÁ AQUI 👇
    runs-on: self-hosted
    defaults:
      run:
        working-directory: ./backend

    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      # ... resto dos passos iguais ...

Faça um commit dessa alteração e olhe para o seu terminal. Você vai ver os comandos do Angular e do .NET passando voando na sua própria tela!

Dica de Ouro: Rodando em Background

Se você fechar o terminal onde rodou o ./run.sh, o runner morre e seu pipeline para de funcionar. Para um ambiente de produção (como uma VPS), você precisa instalar o runner como um serviço do sistema, para que ele ligue sozinho se o servidor reiniciar.

O GitHub já manda o script pronto para isso. Dentro da pasta do runner, basta parar a execução (Ctrl+C) e rodar:

sudo ./svc.sh install
sudo ./svc.sh start

Agora ele está rodando silenciosamente no fundo (background) e você pode fechar o terminal tranquilamente.

O Que Vem a Seguir?

Se livrar dos custos com Self-Hosted Runners é um alívio gigante, especialmente em projetos corporativos. Agora você tem infraestrutura de sobra.

Mas, à medida que a equipe desenvolve e lança novas features, surge outro problema: como saber exatamente o que foi para produção? Como organizar as versões (v1.0.0, v1.1.0) do seu software sem fazer isso na mão?

No próximo episódio desta série, vamos transformar nosso pipeline em uma máquina de versionamento profissional usando automação de Tags, Releases e criação de Changelogs automáticos.

DEV Community