Índice de contenidos
Claves de la noticia
- GitHub fija para el 29 de septiembre la aplicación completa de sus requisitos mínimos para los runners autogestionados de Enterprise Cloud.
- Una versión anterior a 2.329.0 impide registrar el runner; para ejecutar trabajos existe otro umbral, superior, que el último aviso no cifra.
- El cambio no afecta a GitHub Enterprise Server y exige revisar especialmente las imágenes de runners fijadas a una versión antigua.
GitHub ha trasladado al 29 de septiembre de 2026 la aplicación completa del control de versiones de los self-hosted runners de GitHub Actions en Enterprise Cloud. La fecha anterior era el 25 de septiembre. Para los equipos que ejecutan su integración continua en máquinas propias, el efecto potencial es inmediato: un agente demasiado antiguo puede dejar de registrarse o de recibir trabajos, según el umbral que incumpla.
Dos umbrales con consecuencias distintas
El aviso publicado por GitHub el 28 de septiembre distingue dos operaciones. Los runners anteriores a la versión 2.329.0 no podrán registrarse ni volver a registrarse. Por separado, los que queden por debajo de la versión mínima exigida para ejecutar trabajos dejarán de procesarlos aunque ya consten como registrados. GitHub aclara que este segundo mínimo es superior al primero, pero no da su número en ese aviso.
Esa distinción evita una conclusión engañosa: actualizar una imagen exactamente a 2.329.0 puede resolver el alta del agente, pero no demuestra que vaya a aceptar trabajos. El número publicado funciona como suelo de registro, no como certificación general de compatibilidad. Para una flota en producción, la comprobación útil combina la versión instalada con una ejecución real del flujo de trabajo y con los avisos de obsolescencia que ofrece el servicio.
GitHub no informa en el comunicado de la hora exacta de despliegue ni de cuántas organizaciones tienen todavía agentes por debajo de los mínimos. Por tanto, la fecha anunciada describe el comienzo de la aplicación completa; no permite afirmar que una empresa concreta haya sufrido ya una interrupción. Tampoco hay que atribuir a este cambio cualquier cola de trabajos: un runner desconectado, ocupado o mal etiquetado puede producir un síntoma parecido.
Del 25 al 29 de septiembre
La cronología que GitHub publicó en junio situaba la aplicación completa para Enterprise Cloud el 25 de septiembre, tras varias ventanas de prueba durante agosto y septiembre. El anuncio más reciente desplaza esa fecha al martes 29. La comparación de ambos textos muestra una prórroga de cuatro días naturales, sin modificación de los requisitos técnicos.
La misma cronología explica por qué existe el límite. GitHub está trasladando la comunicación y la ejecución de Actions a una arquitectura renovada; sostiene que ya atiende más de 120 millones de trabajos diarios y que las versiones antiguas no encajan con la infraestructura actual. Esas magnitudes son cifras de GitHub, no una medición independiente de rendimiento. El dato relevante para un administrador es que el servicio puede rechazar un agente aunque la máquina y sus herramientas locales funcionen correctamente.
El alcance también tiene un límite concreto. GitHub Enterprise Cloud con Data Residency empezó a aplicar sus reglas el 31 de julio. El aviso del 28 de septiembre dice expresamente que el nuevo calendario afecta a Enterprise Cloud y no a GitHub Enterprise Server, la instalación gestionada en servidores propios. Mezclar ambos productos llevaría a ordenar actualizaciones urgentes donde esta fecha no corresponde.
Qué revisar en una flota propia
La documentación de los runners indica que, por defecto, el programa se actualiza automáticamente cuando hay una versión disponible. Algunas organizaciones desactivan ese mecanismo para construir imágenes reproducibles, especialmente en contenedores o máquinas efímeras. En ese caso, el archivo de imagen y el proceso que lo publica deben recibir la nueva versión; reiniciar una instancia creada desde una imagen vieja solo reproduce el problema.
La revisión empieza por inventariar versión, plataforma y modo de despliegue de cada agente, y por comparar esos datos con los mínimos de registro y ejecución que comunica GitHub. Después conviene probar un trabajo representativo en cada grupo de runners, porque una lista de agentes «en línea» por sí sola no prueba que el servicio les asigne tareas. GitHub ofrece además una API de fechas de retirada por versión para automatizar alertas; el anuncio reciente la recomienda para detectar flotas que se acercan al límite.
Hay otra regla que seguirá importando después de hoy. Según GitHub, cuando se desactivan las actualizaciones automáticas, una versión nueva del runner debe incorporarse en un plazo de 30 días desde que está disponible. Una actualización crítica de seguridad puede adelantar la suspensión de la cola hasta que se instale. Por eso no basta con superar el umbral de septiembre y dejar la imagen fijada indefinidamente.
Si los trabajos quedan en cola
La guía de diagnóstico de GitHub remite a la vista de runners del repositorio, la organización o la empresa, donde figuran sus estados, y a los registros Runner_ y SelfUpdate del directorio _diag. Esos registros ayudan a separar un fallo de actualización de un problema de conexión o de un error del propio trabajo. La documentación advierte también de que, si no hay un agente disponible, un trabajo puede permanecer en cola hasta agotar un plazo de 24 horas.
La prioridad práctica es comprobar primero si el runner puede registrarse; si ya aparece registrado, verificar la versión que realmente ejecuta los trabajos y lanzar una prueba controlada. Si la flota usa imágenes congeladas, la corrección debe hacerse en la imagen de origen y desplegarse a todas las instancias afectadas. El cambio de calendario compra cuatro días respecto al plan de junio, pero no crea una excepción para versiones antiguas: el estado «registrado» y la capacidad de ejecutar son controles diferentes.
