Ubuntu 26.04 ya está disponible de forma general en los runners alojados de GitHub Actions para x64 y arm64. El principal punto de atención ahora es la etiqueta ubuntu-latest: GitHub anunció que dejará de apuntar a Ubuntu 24.04 y migrará gradualmente a Ubuntu 26.04 entre el 19 de octubre y el 19 de noviembre de 2026. Los equipos que usan ubuntu-latest deben validar sus workflows antes de esa ventana porque las herramientas preinstaladas, las versiones de runtimes y los paquetes del sistema cambian entre imágenes.
Qué cambia en la migración a Ubuntu 26.04
Para usar la nueva imagen de forma explícita, GitHub indica definir runs-on: ubuntu-26.04 en jobs x64 o runs-on: ubuntu-26.04-arm en jobs arm64. Durante la migración de ubuntu-latest, el mismo archivo de workflow podrá ejecutarse en Ubuntu 24.04 o Ubuntu 26.04 a medida que avance el despliegue. Por eso, una ejecución aislada no debe considerarse prueba de que todos los jobs ya migraron.
Si el equipo todavía no está listo para el cambio, puede fijar temporalmente runs-on: ubuntu-24.04. Este pin evita que el job siga automáticamente el cambio de ubuntu-latest, pero también traslada al equipo la responsabilidad de planificar la actualización más adelante.
Cómo comprobar qué runner ejecutó un job
La forma más fiable de verificar la imagen usada por una ejecución es abrir los logs del job en GitHub Actions y expandir Set up job. Dentro de ese paso, la sección Runner Image muestra la versión de la imagen y ofrece el enlace Included Software correspondiente al runner exacto que procesó ese job.
Esta comprobación es más precisa que consultar solamente la lista actual del repositorio actions/runner-images, porque las imágenes alojadas se actualizan regularmente y el despliegue de una nueva versión tarda varios días. El propio repositorio recomienda usar el log de Set up job cuando se necesita conocer la versión efectiva de una ejecución específica.
Cómo probar antes del cambio de ubuntu-latest
La prueba más directa es ejecutar el mismo conjunto de jobs con ubuntu-26.04 antes del 19 de octubre. En workflows importantes, puede ser útil mantener durante un periodo una comparación entre ubuntu-24.04 y ubuntu-26.04, por ejemplo con una matrix de sistema operativo, para localizar diferencias sin depender del despliegue de ubuntu-latest.
No se debe mirar solamente el estado final. Conviene revisar instalación, compilación, pruebas, empaquetado, generación de artefactos y publicación. Una migración puede seguir en verde y aun así producir un binario distinto, seleccionar otra versión de compilador o resolver dependencias de forma diferente.
Qué dependencias merecen revisión
Ubuntu 26.04 incluye un conjunto diferente de software preinstalado. La lista publicada para la imagen contiene versiones más nuevas de runtimes, compiladores y gestores de paquetes que la imagen Ubuntu 24.04. Como estas imágenes se actualizan con el tiempo, la comparación debe realizarse con el enlace Included Software de la ejecución real y, cuando sea necesario, con los archivos de software de las imágenes 24.04 y 26.04 del repositorio oficial.
- Runtimes: comprueba Node.js, Python, Ruby, Java, .NET y otros lenguajes usados directamente o por herramientas auxiliares.
- Compiladores y toolchains: valida GCC, Clang, CMake, Make, el linker y bibliotecas nativas cuando el proyecto compila código o extensiones.
- Gestores de paquetes: cambios en npm, pip, Homebrew, Helm, vcpkg y otros pueden alterar la resolución de dependencias, el formato de lockfiles o el comportamiento de instalación.
- Paquetes del sistema: no presupongas que una biblioteca APT presente en la imagen anterior continúa instalada con el mismo nombre y versión.
- Contenedores y herramientas de infraestructura: revisa Docker, Buildx, CLIs de nube y herramientas usadas en build, despliegue y pruebas de integración.
- Navegadores y drivers: los pipelines de pruebas end-to-end pueden verse afectados por versiones diferentes de Chrome, Chromium, Firefox o drivers.
Cómo reducir la dependencia del contenido preinstalado
Cuanto más dependa implícitamente un workflow del contenido del runner, mayor será el riesgo de que una actualización de imagen cambie su resultado. Para componentes críticos, conviene instalar o seleccionar versiones de forma explícita con las actions oficiales de setup, archivos de lock y comandos de instalación reproducibles.
También es útil registrar versiones dentro del propio job durante la fase de migración. Comandos simples que muestran la versión del runtime, compilador, gestor de paquetes y herramienta de build hacen mucho más objetiva la comparación entre ejecuciones. Esa evidencia ayuda a separar un problema del sistema operativo de un cambio en el código o las dependencias del proyecto.
Checklist práctico para la migración
- Localiza workflows que usan ubuntu-latest.
- Ejecuta los jobs críticos con ubuntu-26.04 antes del 19 de octubre de 2026.
- Abre Set up job y registra la versión de la imagen y el enlace Included Software.
- Compara instalación, build, pruebas, artefactos y etapas de despliegue entre Ubuntu 24.04 y 26.04.
- Fija las versiones de runtimes y herramientas que no pueden variar entre ejecuciones.
- Si existe una incompatibilidad todavía no resuelta, usa temporalmente ubuntu-24.04 mientras corriges el workflow.
- Después de la corrección, vuelve a probar en ubuntu-26.04 antes de depender otra vez de ubuntu-latest.
Qué hacer si el workflow falla
Si una ejecución falla durante o después de la migración, primero confirma qué imagen ejecutó realmente el job. Después compara el enlace Included Software y las versiones registradas en el log con una ejecución anterior correcta. Si el problema está vinculado a Ubuntu 26.04, fijar temporalmente Ubuntu 24.04 puede recuperar la previsibilidad mientras se actualiza la dependencia incompatible.
El objetivo no es mantener el pin para siempre. La migración anunciada indica que Ubuntu 26.04 pasará a ser la base de ubuntu-latest, por lo que el camino sostenible es eliminar supuestos sobre software preinstalado, hacer explícitas las versiones críticas y validar el pipeline en la nueva imagen antes del despliegue.
