GitHub Actions É um Problema

Artigo original ↗ Discussão no Hacker News ↗

Muitos desenvolvedores elogiam o GitHub Actions por oferecer CI/CD gratuito e conveniente em múltiplas plataformas, mas o criticam cada vez mais por fluxos opacos, ciclos de feedback lentos, complexidade de YAML e aprisionamento ao fornecedor. Comentadores argumentam que a lógica central de build e deploy deve ficar em scripts normais que possam ser executados localmente ou em qualquer sistema de CI, usando Actions apenas como uma orquestração fina. Uma variedade de alternativas e gambiarras é mencionada — de ferramentas como Dagger, Earthly, Garden e `act` a runners self-hosted e motores genéricos de workflow — todas tentando recuperar portabilidade, testabilidade e controle sobre os pipelines.

Problemas Percebidos com o GitHub Actions

  • Fluxos de trabalho em YAML tornam-se complexos, difíceis de depurar e não são facilmente testáveis localmente.
  • A forte dependência de ações de terceiros torna o comportamento opaco e aumenta o aprisionamento ao fornecedor.
  • A terminologia é confusa (actions vs workflows), e a implementação do runner é vista como convoluta, com relatos de comportamentos estranhos e códigos de saída incomuns.
  • O ciclo de feedback é lento: precisar de commits e execuções remotas para iterar na lógica do pipeline é amplamente desaprovado.
  • Alguns consideram o Actions “bom o suficiente”, mas inferior em clareza conceitual a sistemas mais simples como o GitLab CI.

Gambiarras e Práticas Recomendadas

  • Mantenha o YAML “magro”: use-o principalmente para triggers e orquestração; coloque a lógica real em scripts, alvos Make/just, Magefiles, Bazel, etc.
  • Garanta que todas as etapas de CI possam ser executadas localmente com os mesmos comandos usados pelo CI.
  • Prefira scripts locais e containers em vez de actions reutilizáveis pesadas; alguns evitam tudo exceto ações básicas de configuração.
  • Use imagens Docker ou imagens de devcontainer como ambiente canônico tanto para execuções locais quanto para CI.
  • Centralize a lógica comum por meio de scripts compartilhados ou DSLs que compilam para YAML de CI; trate o CI como uma camada de cola.

Execução Local e Lacunas de Ferramentas

  • Há forte demanda por uma forma oficial de executar GHA localmente; os runners self-hosted atuais ainda exigem commits e execução remota.
  • act e emuladores relacionados ajudam alguns fluxos, mas são descritos como incompletos, frágeis e difíceis de depurar em pipelines complexos.
  • Actions de reverse shell/depuração (por exemplo, tmate) são elogiadas para troubleshooting em runners reais.

Aprisionamento ao Fornecedor e Preocupações com a Plataforma

  • O ecossistema de Actions e os runners hospedados gratuitos/baratos (especialmente para Windows/macOS) são vistos como um mecanismo poderoso de aprisionamento.
  • Alguns argumentam que a monetização do CI pelo GitHub desincentiva runners totalmente locais e gratuitos.
  • Outros enfatizam o conjunto mais amplo de recursos do GitHub e os efeitos de rede como a principal “cola”.

Abordagens Alternativas de CI/Workflow

  • Vários projetos miram soluções agnósticas de CI ou “pipelines as code” (Dagger, Earthly, Garden, Windmill, Cirrus CLI, Cicada).
  • O DSL em Groovy e as bibliotecas compartilhadas do Jenkins são citados como um modelo de abstração melhor do que YAML puro.
  • Tentativas de construir motores universais de workflow/CI enfrentam abstrações vazando, variação de ambiente e altos custos de migração.

Reflexões Mais Amplas sobre a Complexidade de CI/CD

  • Muitos veem pipelines de CI como motores de workflow supercomplicados, reinventados repetidamente.
  • Há concordância de que implantações devem ser auditáveis, scriptáveis e não totalmente presas a um único provedor de CI.