Incidente con operaciones de Git, pull requests y Actions – Resuelto

Artículo original ↗ Discusión en Hacker News ↗

Las frecuentes interrupciones de GitHub que afectan funciones centrales como `git push`, pull requests, Actions e incluso la autenticación están llevando a los desarrolladores a cuestionar su fiabilidad y a considerar alternativas como GitLab, Forgejo, Gitea y configuraciones autoalojadas. Los comentaristas señalan el aumento del uso impulsado por IA, la migración de GitHub a Azure y los incentivos asociados a los planes gratuitos como posibles causas, al tiempo que observan que el tiempo de inactividad sigue siendo por lo general demasiado breve como para justificar el coste y la complejidad de migrar por completo. Muchos ven este patrón como una muestra de los riesgos de depender en exceso de un único forge centralizado para flujos de trabajo y despliegues críticos.

Impacto y alcance de la interrupción

  • Los usuarios informan que no pueden hacer push, crear PRs ni issues, fallas de autenticación (p. ej., mediante SSO basado en GitHub) y commits faltantes en los PRs.
  • Actions y Pages fallaban o se retrasaban, con algunos trabajos que no se activaban o colas de merge atascadas durante horas.
  • Algunos vieron “Internal Server Error” intermitente en git push, errores de análisis JSON provenientes de páginas HTML 500 y breves fallos no informados en días anteriores.

Percepciones sobre la fiabilidad de GitHub

  • Muchos sienten que las interrupciones ahora ocurren “cada pocos días” en lugar de ser eventos mensuales raros.
  • Varios dicen que GitHub se ha convertido en uno de los servicios menos fiables de su pila; algunos están migrando activamente cargas de trabajo críticas fuera de él.
  • Otros sostienen que las interrupciones siguen siendo breves (decenas de minutos) y tolerables, especialmente dada la naturaleza offline de git, aunque esto se disputa fuertemente.

Causas especuladas

  • Temas comunes: migración de MySQL personalizado bare-metal a Azure; mayor carga por IA/coding agentic; más funciones y complejidad.
  • Algunos señalan advertencias internas sobre latencia y una migración en vivo de datos compleja; otros cuestionan si Azure es realmente la causa.
  • Unos pocos atribuyen los problemas, en tono jocoso o no, a sistemas “codificados por IA” y a la pérdida de una comprensión humana profunda.

Página de estado y gestión del incidente

  • Varios comentarios dicen que el sitio de estado subestimó la duración/el impacto y marcó los incidentes como “resueltos” mientras los errores persistían.
  • Algunos ven esto como un “relleno de estadísticas” engañoso; otros sugieren posibles errores honestos, pero notan patrones repetidos.

Alternativas y autoalojamiento

  • Los usuarios reportan buenas experiencias con Forgejo/Gitea/GitLab autoalojados, a menudo combinados con S3/registros OCI y sistemas CI separados.
  • Otros destacan la carga operativa: replicar issues, PRs, actions, pages y la gestión de proyectos no es trivial.

Consideraciones de negocio y arquitectura

  • Debate sobre si:
    • Migrar completamente fuera de GitHub,
    • Añadir rutas de despliegue redundantes, o
    • Aceptar interrupciones ocasionales como algo más barato que cambios mayores.
  • Algunos argumentan que GitOps / CI fuertemente acoplados a GitHub son frágiles; otros dicen que los despliegues verdaderamente multi-ruta rara vez se justifican para la mayoría de las empresas.

Bloqueo del ecosistema

  • Varios señalan áreas donde GitHub es efectivamente obligatorio: Homebrew taps, registries de Terraform/OpenTofu, ciertos flujos de trabajo en la nube, runners gratuitos de macOS/Windows.
  • Compromiso sugerido: tratar GitHub como un espejo de solo lectura para la descubribilidad mientras se usa otro forge principal.