Incidente com Actions, Pull Requests e Issues

Artigo original ↗ Discussão no Hacker News ↗

Falhas frequentes afetando GitHub Actions, pull requests e issues estão levando desenvolvedores a questionar a confiabilidade do GitHub e a estratégia da Microsoft, à medida que o coding “agêntico” impulsionado por IA aumenta massivamente a carga na plataforma. Muitos argumentam que planos gratuitos generosos e minutos de CI subprecificados, na prática, permitiram que bots DDOSassem o serviço, e sugerem limites de taxa mais rígidos, preços mais altos ou separar o uso gratuito do pago para proteger fluxos de trabalho sérios. Outros estão reagindo explorando alternativas como GitLab, Buildkite, Forgejo ou CI totalmente self-hosted, avaliando o trade-off entre a conveniência do SaaS e o controle operacional.

Sentimento geral

  • Muitos comentaristas estão frustrados e já não veem o GitHub Actions como confiável para CI/CD “sério” ou corporativo.
  • Alguns ainda o consideram aceitável ou ótimo para projetos hobby/pequenos/FOSS, onde CI gratuito e de baixo esforço é muito valorizado.
  • Várias equipes estão planejando ativamente, ou executando, migrações para fora do CI do GitHub.

Causas percebidas das falhas repetidas

  • Crescimento massivo atribuído ao uso por IA/agentes: alegações de ter passado de ~50M para ~2B eventos por dia, com agentes acionando repetidamente o CI para mudanças triviais.
  • Divergência sobre a infraestrutura:
    • Alguns culpam a Azure por ser “não confiável” ou limitada em capacidade.
    • Outros argumentam que a própria arquitetura e as decisões de escala do GitHub são as culpadas, não a nuvem subjacente vs. self‑host.
  • Debate sobre se as falhas se devem a:
    • Limites reais de capacidade e cargas intensivas em escrita (actions, PRs, eventos).
    • Slop “vibecoded” / escrito por agentes e atalhos operacionais.
    • Gestão escolhendo crescimento e posicionamento em IA em vez de estabilidade.
  • Não está claro quanto do impacto é compartilhado entre os planos gratuitos e os pagos/empresariais; os relatos entram em conflito sobre se a nuvem enterprise evita ou compartilha a dor.

Preço, plano gratuito e incentivos

  • Muitos veem isso como uma falha de preço e de política:
    • Repositórios gratuitos/privados mais minutos generosos de Actions teriam convidado uso abusivo ou pesado por agentes de IA.
    • Sugestões incluem tornar Actions um recurso pago, reduzir drasticamente os minutos gratuitos, impor limites de taxa mais rígidos ou serviço “degradado” para usuários gratuitos.
  • Contra-argumentos:
    • CI gratuito é crucial para open source e aquisição de usuários.
    • Mudanças agressivas demais poderiam afastar comunidades centrais ou gerar “cobranças misteriosas”.
    • Preço baixo pode ter sido estratégico para ganhar dados e efeitos de rede.

Alternativas e estratégias de adaptação

  • Alternativas mencionadas: GitLab CI, Buildkite, Semaphore, Concourse, Forgejo + runners self-hosted, RWX, Azure DevOps, servidores domésticos.
  • Argumentos a favor de self-hosting: independência, confiabilidade, desempenho e menor risco de plataforma, agora facilitado por assistência de LLM.
  • Argumentos contra self-hosting: sobrecarga operacional, custo, dificuldade de runners Windows/macOS e melhor uso do tempo dos desenvolvedores em SaaS.
  • Algumas equipes estão limitando o CI (gatilhos manuais, apenas na main, testes locais) para reduzir carga e dependência do Actions.

Preocupações mais amplas

  • Medo de uma possível “espiral da morte”: usuários pagantes indo embora → menos investimento → mais instabilidade.
  • Críticas à aquisição pela Microsoft e ao ambiente antitruste mais amplo.
  • Alguns sugerem que o próprio Git ou a arquitetura do GitHub pode ser estruturalmente difícil de escalar nos volumes atuais de eventos.