Incidente con Actions, pull requests e issues

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

Las interrupciones frecuentes que afectan a GitHub Actions, pull requests e issues están llevando a los desarrolladores a cuestionar la fiabilidad de GitHub y la estrategia de Microsoft, mientras la programación “agéntica” impulsada por IA incrementa enormemente la carga de la plataforma. Muchos sostienen que los planes gratuitos generosos y los minutos de CI infrapreciados han permitido de hecho que los bots DDoS el servicio, y proponen límites de tasa más estrictos, precios más altos o separar el uso gratuito del de pago para proteger los flujos de trabajo serios. Otros están respondiendo explorando alternativas como GitLab, Buildkite, Forgejo o CI totalmente autohospedada, sopesando la disyuntiva entre la comodidad del SaaS y el control operativo.

Sentimiento general

  • Muchos comentaristas están frustrados y ya no consideran que GitHub Actions sea fiable para CI/CD “serio” o empresarial.
  • Algunos siguen viéndolo aceptable o incluso excelente para proyectos hobby/pequeños/FOSS, donde la CI gratuita y de bajo esfuerzo es muy valiosa.
  • Varios equipos están planificando activamente, o ejecutando, migraciones fuera de GitHub CI.

Causas percibidas de las interrupciones repetidas

  • Crecimiento masivo atribuido al uso de IA/agente: afirmaciones de pasar de ~50M a ~2B eventos por día, con agentes disparando CI repetidamente por cambios triviales.
  • Desacuerdo sobre la infraestructura:
    • Algunos culpan a Azure por ser “poco fiable” o estar limitado por capacidad.
    • Otros sostienen que la culpa es de la propia arquitectura de GitHub y de sus decisiones de escalado, no de la nube subyacente frente a la autogestión.
  • Debate sobre si las interrupciones se deben a:
    • Límites reales de capacidad y cargas intensivas en escrituras (actions, PRs, eventos).
    • Slop “vibecoded” / escrito por agentes y atajos operativos.
    • Decisiones de la dirección de priorizar el crecimiento y la postura en IA por encima de la estabilidad.
  • No está claro cuánto del impacto se comparte entre los planes gratuitos y los de pago/enterprise; los informes discrepan sobre si la nube enterprise evita o comparte el problema.

Precios, plan gratuito e incentivos

  • Muchos ven esto como un fallo de precios y de política:
    • Los repositorios gratuitos/privados más unos minutos gratuitos de Actions generosos habrían invitado a un uso abusivo o intensivo por parte de agentes de IA.
    • Entre las sugerencias se incluyen hacer de Actions una función de pago, reducir drásticamente los minutos gratuitos, límites de tasa más estrictos o un servicio “degradado” para usuarios gratuitos.
  • Contraargumentos:
    • La CI gratuita es crucial para el software de código abierto y para la adquisición de usuarios.
    • Cambios demasiado agresivos podrían alejar a comunidades clave o generar “cargos misteriosos”.
    • Los precios bajos podrían haber sido una estrategia para obtener datos y efectos de red.

Alternativas y estrategias de mitigación

  • Alternativas mencionadas: GitLab CI, Buildkite, Semaphore, Concourse, Forgejo + runners autohospedados, RWX, Azure DevOps, servidores domésticos.
  • Argumentos a favor de autohospedarse: independencia, fiabilidad, rendimiento y menor riesgo de plataforma, ahora más fácil con la ayuda de LLM.
  • Argumentos en contra de autohospedarse: sobrecarga operativa, coste, dificultad de los runners de Windows/macOS y mejor uso del tiempo de los desarrolladores en SaaS.
  • Algunos equipos limitan la CI (disparadores manuales, solo en main, pruebas locales) para reducir la carga y la dependencia de Actions.

Preocupaciones más amplias

  • Temor a una posible “espiral de muerte”: que los usuarios de pago se marchen → menos inversión → más inestabilidad.
  • Críticas a la adquisición por parte de Microsoft y al entorno antimonopolio más amplio.
  • Algunos sugieren que Git en sí mismo, o la arquitectura de GitHub, puede ser estructuralmente difícil de escalar a los volúmenes de eventos actuales.