optimize-github-actions — VMs efêmeras de CI

⚠️ Requisito, antes de qualquer coisa

Você precisa poder criar máquinas virtuais numa cloud — GCP, Azure, AWS, Oracle,
Hetzner, tanto faz qual. A topologia inteira consiste em o seu CI subir e derrubar
VMs suas, uma por job. Sem permissão de criar instância, rede e imagem, não há o
que implementar.

E o repositório precisa ser privado, com fork desabilitado. Não é preferência:
num repositório público qualquer pessoa abre um PR e roda código na sua máquina.

O problema

Você paga minuto de CI com a margem do provedor embutida, na máquina que ele
decidiu te emprestar. Job longo custa caro, e a máquina barata do plano é justo a
que falta RAM.

As duas saídas óbvias não resolvem: runner hospedado cobra o minuto com margem;
runner persistente cobra a VM 24×7, mesmo ociosa. Falta a terceira.

O que o guia entrega

A terceira topologia: uma VM sua por job, criada e destruída pelo próprio run.
O custo passa a ser proporcional ao uso e a máquina é sua — mais núcleos, mais
RAM, disco mais rápido, pelo mesmo dinheiro.

O fluxo, concretamente: um job leve roda no runner hospedado e decide quantas
máquinas o run precisa; pra cada uma, registra um runner de uso único (JIT) e
passa a credencial na metadata da VM; a VM sobe, pega um job, termina e se
desliga; um job de teardown com if: always() limpa o run, e um varredor agendado
pega o que sobrou.

15 seções em quatro movimentos:

• Decidir se vale — a topologia em uma página, quando paga e quando não
  paga, as perguntas a fazer ao humano antes de tocar em nada, e os acessos a pedir
  com o comando que prova cada um.
• Medir antes de propor — quanto se gasta hoje e com quê, qual máquina cada job
  realmente precisa, o caminho crítico, o que se paga na cloud além da VM, e por que
  custo bruto não é custo líquido.
• Implementar — as sete decisões de arquitetura, cada uma com o motivo medido
  contra a alternativa que parecia melhor: runner JIT em vez de token de registro,
  uma VM por job em vez de pool, provisionamento no runner hospedado, imagem custom
  em vez de script de boot, on-demand em vez de spot, VM sem identidade da cloud,
  saída por IP efêmero. Mais a implementação passo a passo e os testes que provam.
• Sobreviver ao primeiro mês — as armadilhas já pagas, o estudo de custo
  realizado, o A/B de tipo de máquina com as três armadilhas que invalidam a medição
  sem avisar, e como deixar uma skill no repositório pro próximo agente.

De onde ele vem

Foi escrito por um agente que implementou isso em produção, para outro agente que
vai implementar. Todo número marcado como "medido" vem de execução real: o pico
de 8.546 MiB num único job que eliminou a máquina de 8 GiB e fixou a de 16 GiB; o
shard de 2 para 4 que devia cortar o tempo pela metade e cortou 20%; a tabela de
A/B com o tempo do job mais lento em cada tipo de máquina.

O que ele NÃO é

Não é script pronto pra colar — é o raciocínio, as decisões e os comandos, pra você
adaptar à sua cloud. Não é promessa de economia: tem uma seção dedicada a quando
não vale fazer, e ela é pra ser levada a sério — job abaixo de ~5 min é dominado
pelo boot da VM, volume abaixo de ~50 horas-job por mês não paga a operação, e
franquia de minutos sobrando no plano mata o caso. Não cobre GitLab CI nem CircleCI.
E não substitui alguém que saiba mexer na sua cloud.

Pra quem é

Quem tem repositório privado, CI com job longo e recorrente, uma cloud já em uso, e
uma fatura de Actions que incomoda. Se você não tem os quatro, o guia vai te dizer
isso nas três primeiras seções — de propósito.