Incidente com Operações Git, Pull Requests e Actions – Resolvido

Artigo original ↗ Discussão no Hacker News ↗

Indisponibilidades frequentes do GitHub afetando funções centrais como git push, pull requests, Actions e até autenticação estão levando desenvolvedores a questionar sua confiabilidade e considerar alternativas como GitLab, Forgejo, Gitea e configurações auto-hospedadas. Comentadores apontam o aumento do uso impulsionado por IA, a migração do GitHub para Azure e os incentivos ligados a camadas gratuitas como possíveis causas, ao mesmo tempo em que observam que o tempo de parada ainda costuma ser curto demais para justificar o custo e a complexidade de uma migração completa para longe dele. Muitos veem esse padrão como um sinal dos riscos de depender demais de um único forge centralizado para fluxos de trabalho e implantações críticas.

Impacto e abrangência da indisponibilidade

  • Usuários relatam incapacidade de fazer push, criar PRs ou issues, falhas de autenticação (por exemplo, via SSO baseado em GitHub) e commits ausentes em PRs.
  • Actions e Pages estavam falhando ou com atraso, com alguns jobs não sendo acionados ou filas de merge travadas por horas.
  • Alguns viram “Internal Server Error” intermitente em git push, erros de parse de JSON vindos de páginas HTML 500 e breves falhas não reportadas em dias anteriores.

Percepções sobre a confiabilidade do GitHub

  • Muitos sentem que as indisponibilidades agora acontecem “a cada poucos dias”, em vez de eventos mensais raros.
  • Vários dizem que o GitHub se tornou um dos serviços menos confiáveis em sua stack; alguns estão migrando ativamente cargas críticas para fora dele.
  • Outros argumentam que as indisponibilidades ainda são curtas (de dezenas de minutos) e toleráveis, especialmente considerando a natureza offline do git, embora isso seja fortemente contestado.

Causas especuladas

  • Temas comuns: migração de MySQL bare-metal personalizado para Azure; aumento de carga por codificação com IA/agentic; mais recursos e complexidade.
  • Alguns apontam para avisos internos sobre latência e migração complexa de dados em tempo real; outros questionam se o Azure é de fato a causa.
  • Poucos atribuem os problemas, com ou sem ironia, a sistemas “codificados por IA” e à perda de compreensão humana profunda.

Página de status e tratamento do incidente

  • Vários comentários dizem que o site de status subestimou a duração/impacto e marcou incidentes como “resolved” enquanto os erros persistiam.
  • Alguns veem isso como “enfeitar estatísticas” de forma enganosa; outros sugerem possíveis erros honestos, mas notam padrões recorrentes.

Alternativas e auto-hospedagem

  • Usuários relatam boas experiências com Forgejo/Gitea/GitLab auto-hospedados, muitas vezes combinados com registries S3/OCI e sistemas de CI separados.
  • Outros destacam o peso operacional: replicar issues, PRs, actions, pages e gerenciamento de projetos não é trivial.

Considerações de negócio e arquitetura

  • Debate sobre se vale a pena:
    • Migrar completamente para fora do GitHub,
    • Adicionar caminhos redundantes de deploy, ou
    • Aceitar indisponibilidades ocasionais como algo mais barato do que grandes mudanças.
  • Alguns argumentam que GitOps / CI fortemente acoplado ao GitHub é frágil; outros dizem que deploys com múltiplos caminhos raramente se justificam para a maioria das empresas.

Lock-in do ecossistema

  • Vários observam áreas em que o GitHub é, na prática, obrigatório: Homebrew taps, registries Terraform/OpenTofu, certos fluxos de trabalho em nuvem, runners gratuitos de macOS/Windows.
  • Compromisso sugerido: tratar o GitHub como um espelho somente leitura para descoberta, usando outro forge principal.