Migración a Ubuntu 26.04 en GitHub Actions: cómo comprobar las diferencias del ejecutor con el mismo commit
Los resultados de CI pueden cambiar sin haber modificado el código fuente. Si sus flujos de trabajo dependen de ubuntu-latest para el entorno de ejecución, la transición de la imagen del sistema operativo también debe formar parte de los cambios que gestiona el equipo.
El 17 de septiembre de 2026, GitHub anunció el soporte oficial para los ejecutores de Ubuntu 26.04 y el plan de migración de ubuntu-latest. Este artículo no pretende presentar la nueva imagen como algo incondicionalmente más rápido, sino ofrecer una propuesta práctica para aislar y verificar las diferencias de entorno utilizando el mismo commit.
Alcance confirmado en el anuncio oficial
Según el anuncio, las imágenes de Ubuntu 26.04 contarán con soporte oficial en x64 y arm64, y sus etiquetas explícitas son ubuntu-26.04 y ubuntu-26.04-arm. La etiqueta ubuntu-latest migrará gradualmente de Ubuntu 24.04 a 26.04 entre el 19 de octubre y el 19 de noviembre de 2026.
La nueva imagen incluye herramientas actualizadas o eliminadas, por lo que las compilaciones que dependen de paquetes preinstalados pueden verse afectadas. Si aún no está preparado, GitHub recomienda especificar ubuntu-24.04 de forma explícita. Este cronograma no representa necesariamente la fecha de transición real para todos los repositorios.
Documentar el entorno que espera su repositorio
Primero, revise runs-on en sus flujos de trabajo y en los flujos de trabajo reutilizables. No asuma que el impacto del host desaparece solo por usar contenedores; conviene revisar también los pasos de instalación, compresión y subida que se ejecutan fuera del contenedor.
En su lista de verificación, intente clasificar compiladores, entornos de ejecución, gestores de paquetes y bibliotecas del sistema. En lugar de limitarse a anotar los nombres de las herramientas, relacionar dónde se instalan y qué paso las invoca facilitará acotar la causa de los registros de error.
Mismo commit, dos entornos y artefactos independientes
Resulta más claro iniciar los ensayos de transición en una ruta de prueba que no tenga permisos de despliegue. Ejecute el mismo commit y archivo de bloqueo tanto en la imagen existente como en la nueva, y conserve por separado los registros, los resultados de las pruebas y los nombres de los artefactos. Este es el método de validación propuesto en este artículo.
En la comparación inicial, registre las condiciones de la caché para poder distinguir el impacto de memorias caché obsoletas. Además del éxito o fracaso de la compilación, debe documentar las versiones de las herramientas instaladas, los pasos fallidos y los resultados de ejecución de los artefactos para identificar casos que hayan pasado por pura casualidad gracias a un acierto de caché.
Verificaciones pendientes tras el check verde
Si se trata de un proyecto web, puede comprobar si los archivos generados realmente se pueden servir; si tiene dependencias nativas, verifique si se cargan en el entorno de destino. En lugar de exigir que los bytes de todos los artefactos sean idénticos, distinga entre diferencias no deterministas (como marcas de tiempo) y discrepancias funcionales.
Quien revise debe poder ver en un solo lugar el enlace a la ejecución en la nueva imagen, las diferencias en las versiones de las herramientas, los resultados de las pruebas de funciones representativas y los cambios que deberían revertirse. Mezclar la transición del ejecutor con refactorizaciones de la aplicación amplía innecesariamente las causas de fallo y el alcance del rollback.
Ventajas y limitaciones residuales de fijar la imagen
El uso de etiquetas explícitas de sistema operativo ayuda a controlar grandes transiciones, pero no garantiza un entorno de compilación completamente inmutable. Mantenga el hábito de instalar explícitamente las herramientas necesarias para la ejecución y registrar sus versiones reales en los logs.
En repositorios pequeños no es necesario crear un sistema de validación descomunal. Puede empezar comparando una compilación representativa y las dependencias más sensibles, y si fijó una versión temporalmente, registre el responsable de liberarla junto con la fecha prevista para su revisión.
Separar el debate público de las decisiones de su equipo
Los issues públicos de runner-images son el canal para revisar cambios en la imagen y reportes de problemas. Un comentario específico o el fallo en otro proyecto no significa que vaya a reproducirse en su repositorio, y este artículo no presenta afirmaciones cuantitativas sobre consensos comunitarios o frecuencia de incidencias.
La tarea para hoy consiste en identificar dónde se utiliza la etiqueta latest y probar el mismo commit en la nueva imagen. Si define con antelación las condiciones de aprobación y de retención, los responsables podrán evaluar con las mismas evidencias si la compilación cambia durante el período de transición real.