--- service: "Publicasta" schema_version: "1.0" article_id: 716 title: "GitHub Actions ha eliminado Node 20: qué deben revisar ahora los mantenedores de código abierto" language: "es" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=es" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=es" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_actions_node24_migration_open_source_maintainers?lang=es" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-28T07:04:34+00:00" updated_at: "2026-09-28T07:04:34+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=de" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=de" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=en" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=en" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=es" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=es" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=zh" --- # GitHub Actions ha eliminado Node 20: qué deben revisar ahora los mantenedores de código abierto > GitHub Actions ejecuta ahora las acciones JavaScript con Node 24 tras retirar Node 20. La migración parece un cambio de metadatos, pero los runners autohospedados, las versiones de macOS, los dispositivos ARM32, las cachés y los emuladores locales aún pueden romper una compilación. GitHub Actions ya pasó de las advertencias a las interrupciones: Node 20 dejó de estar disponible como entorno de ejecución para las acciones JavaScript en los runners alojados por GitHub. Desde el 23 de septiembre de 2026, esas acciones se ejecutan con Node 24 y se eliminó la exclusión temporal que permitía a los repositorios seguir usando Node 20. ![Ilustración tecnológica editorial de un mantenedor de código abierto revisando la migración de GitHub Actions de Node 20 a Node 24, con artefactos de CI y un runner propio.](https://publicasta.com/storage/projects/10/pages/716/2026/09/eb75953e-6fdf-433e-8e16-e6eabd4850fd.webp) Para la mayoría de los repositorios, la corrección visible parece sencilla: actualizar las referencias de las acciones y continuar. Para los mantenedores de proyectos de código abierto, sin embargo, el trabajo importante es más amplio. Una acción puede parecer actualizada en su árbol de fuentes mientras la etiqueta publicada sigue apuntando a un paquete `dist` antiguo. Un workflow puede usar una acción JavaScript reciente y aun así fallar en un runner autohospedado, en un Mac antiguo o en una placa ARM32. Las herramientas locales que emulan Actions también pueden seguir ejecutando el runtime equivocado y transmitir una falsa sensación de compatibilidad. La recomendación práctica es tratar este cambio como una auditoría de lanzamiento y de matriz de soporte, no como una sustitución mecánica de `node20` por `node24`. El cambio de runtime es el acontecimiento inmediato. El asunto más duradero es cómo los proyectos de código abierto comunican qué runners admiten, publican artefactos de acciones inmutables y prueban los entornos que realmente utilizan sus usuarios. ## Qué cambió el 23 de septiembre El aviso de retirada de GitHub indica que los runners usan ahora Node 24 para las acciones JavaScript. También señala que `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION` ya no está disponible. Esa variable era una salida temporal durante la migración; ya no es un mecanismo de compatibilidad respaldado. GitHub aplica el cambio tanto en github.com como en GitHub con residencia de datos. Es importante distinguir entre el runtime de una acción y la versión de Node instalada para un workflow. Una acción JavaScript declara su entorno de ejecución en `action.yml`, normalmente en un bloque parecido a este: ```yaml runs: using: node24 main: dist/index.js ``` Esa configuración controla el runtime de Node que GitHub utiliza para lanzar la acción. Es independiente de un paso posterior como `actions/setup-node`, que instala una versión de Node para los comandos del propio proceso de compilación, pruebas o empaquetado del repositorio. Instalar Node 20 con `setup-node` no vuelve compatible una acción que declara `node20` cuando el runtime de acciones Node 20 ha sido retirado del runner. Del mismo modo, cambiar el runtime declarado por una acción no cambia automáticamente la versión de Node que usa la suite de pruebas del proyecto. Por eso un repositorio puede contener varias superficies de migración independientes: - Acciones JavaScript declaradas en los propios archivos `action.yml` del repositorio. - Acciones de terceros referenciadas en los archivos de workflow. - El JavaScript incluido bajo `dist/`, si la acción confirma el código compilado en Git. - Las versiones y los sistemas operativos de los runners autohospedados. - La versión de Node que el proyecto utiliza para pruebas, compilaciones, CLI o scripts de publicación. El aviso de obsolescencia anterior de GitHub concedió a los mantenedores un periodo de transición y documentó la fecha de retirada definitiva. Node.js, por su parte, indica que Node 20 llegó al final de su vida útil el 24 de marzo de 2026. El cambio de Actions elimina, por tanto, una vía de ejecución que ya dependía de un runtime ascendente sin soporte; no inaugura una política nueva de lanzamientos de Node.js. ## Primera auditoría: localizar lo que realmente se ejecutará Comienza por los archivos de workflow, pero no te detengas ahí. Busca tanto el uso directo de acciones como sus definiciones. Una primera revisión útil en un repositorio incluye: ```text .github/workflows/ action.yml action.yaml */action.yml */action.yaml ``` En los workflows, busca referencias como `uses: owner/project@vN`. Una etiqueta de versión mayor no revela qué runtime de Node utiliza la versión referenciada. Hay que inspeccionar la acción en la etiqueta o el commit resueltos. Esto resulta especialmente importante en acciones pequeñas de la comunidad que pueden haber recibido una actualización en sus fuentes sin publicar un lanzamiento nuevo. Para una acción mantenida en el mismo repositorio, revisa `action.yml` e identifica `runs.using`. Si indica `node20`, cámbialo a `node24` y vuelve a construir el paquete incluido cuando el proyecto espera que `dist/` esté confirmado en Git. Muchas acciones JavaScript ejecutan archivos compilados, no el código TypeScript o JavaScript fuente del repositorio. Cambiar correctamente la fuente dejando un paquete desactualizado no constituye un lanzamiento completo. La siguiente pregunta es si las dependencias de la acción son compatibles con Node 24. Node 24 no es solo una etiqueta que el analizador de metadatos acepta. Incluye un V8 más reciente y un conjunto más nuevo de APIs de Node, y puede revelar supuestos sobre la carga de módulos, las exportaciones de paquetes, el comportamiento de OpenSSL o las APIs de archivos y streams. El riesgo no consiste en que toda acción de Node 20 vaya a fallar. El riesgo es que el proyecto nunca haya ejecutado su artefacto real de lanzamiento bajo el nuevo runtime. Para acciones de terceros, prioriza un lanzamiento publicado por el mantenedor que documente explícitamente la compatibilidad con Node 24. No des por hecho que sustituir `@v3` por `@v4` es correcto solo porque el número es mayor. Lee las notas de lanzamiento, inspecciona los metadatos de la acción y comprueba si la nueva versión introduce cambios de comportamiento no relacionados. Una migración de runtime es una mala razón para aceptar un cambio de versión mayor sin revisar entradas, salidas, permisos y comportamiento de seguridad. ## Por qué las actualizaciones de las acciones oficiales sirven como ejemplo Las acciones oficiales de GitHub ofrecen una imagen concreta de cómo se está gestionando la migración. El changelog actual de `actions/checkout` registra actualizaciones a Node 24 en su historial de versiones, y la documentación actual de `actions/setup-node` identifica versiones más recientes de la acción que usan Node 24. Estos proyectos hacen más que editar un campo de metadatos: publican un lanzamiento nuevo, actualizan la documentación, ejecutan su propia matriz de pruebas y señalan los requisitos de runners y los cambios de comportamiento. Ese patrón merece ser adoptado por repositorios más pequeños. Un lanzamiento de migración responsable debe responder con claridad a cuatro preguntas: qué versión de la acción contiene el cambio, qué versión del runner se necesita, qué sistemas operativos o arquitecturas dejan de estar soportados y si cambiaron las entradas o salidas de la acción. Las respuestas deben aparecer en las notas de lanzamiento aunque el diff de código sea diminuto. El proyecto `actions/setup-node` también recuerda que una migración de runtime puede coincidir con otros cambios. Su documentación actual describe una acción basada en Node 24 e incluye indicaciones sobre la caché de gestores de paquetes. Advierte que la caché automática no siempre es apropiada para workflows con privilegios elevados o credenciales sensibles. Esa advertencia no la provoca Node 24, pero importa durante la misma auditoría porque los mantenedores suelen actualizar a la vez las versiones de las acciones y la configuración de seguridad del workflow. Un usuario que actualiza una acción para obtener soporte de Node 24 puede recibir también cambios en los valores predeterminados de caché, el comportamiento de autenticación, las versiones de runner admitidas o la detección del gestor de paquetes. La revisión adecuada no consiste en preguntar únicamente si el YAML se analiza correctamente, sino qué código se ejecuta ahora, con qué permisos y con qué estado almacenado en caché. ## Los runners autohospedados son el punto más delicado El aviso de retirada de GitHub destaca dos límites de compatibilidad para Node 24: macOS 13.4 y anteriores son incompatibles, y ARM32 no cuenta con soporte oficial. Estos límites son especialmente relevantes para los proyectos de código abierto porque sus comunidades de contribuyentes y usuarios son más variadas que la matriz predeterminada de runners alojados por GitHub. Un proyecto puede tener una compilación verde en Ubuntu mientras sus usuarios ejecutan la acción en un Mac Intel antiguo, una placa ARM32 de clase Raspberry Pi o un runner privado detrás de un firewall. El problema del sistema operativo puede pasar inadvertido cuando el workflow usa una etiqueta amplia como `macos-latest`. Las etiquetas de los runners alojados por GitHub cambian con el tiempo, mientras que una etiqueta autohospedada suele describir una máquina que el administrador debe actualizar manualmente. Un repositorio que admita runners autohospedados debería documentar una versión mínima del runner y el intervalo de sistemas operativos compatible, en vez de tratar las imágenes alojadas por GitHub como si fueran toda la política de soporte. El problema de arquitectura es aún menos visible. Las máquinas ARM32 son poco comunes en la CI alojada, por lo que una matriz predeterminada puede no ejecutarlas nunca. Si el proyecto tiene usuarios que ejecutan Actions localmente o en dispositivos pequeños de borde, los mantenedores deben decidir si ARM32 continúa siendo compatible. La decisión debe ser explícita. Decir que la acción funciona en Linux no es suficientemente preciso cuando el soporte de arquitectura del runtime cambia según la plataforma. Los administradores de runners autohospedados deberían actualizar primero el software del runner antes de diagnosticar fallos de acciones. Algunas versiones compatibles con Node 24 requieren un runner suficientemente reciente, y la documentación de lanzamiento de la acción debe considerarse la autoridad para determinar la versión mínima. Actualizar el runner no vuelve compatible un sistema operativo incompatible, pero un runner antiguo puede producir errores engañosos antes de que se llegue siquiera al código de la acción. La secuencia prudente es preparar la actualización del runner, ejecutar un workflow representativo con los secretos eliminados o sustituidos por credenciales de prueba y después probar los workflows que utilizan permisos de despliegue, publicación o lanzamiento. Un job básico de pruebas unitarias no basta si la acción también sube artefactos, firma paquetes, abre pull requests o intercambia un token OIDC. ## El artefacto publicado forma parte del software Las acciones JavaScript suelen confirmar su directorio compilado `dist` en Git para que los usuarios no tengan que instalar dependencias ni construir la acción durante la ejecución del workflow. Esto crea una trampa de lanzamiento: el repositorio puede mostrar una fuente moderna mientras la etiqueta que consumen los usuarios contiene todavía un paquete desactualizado. Los mantenedores deben revisar el artefacto exacto que ejecutará la acción en la referencia publicada. Eso significa confirmar todo lo siguiente: 1. `action.yml` o `action.yaml` declara `node24`. 2. La ruta `main` o `pre` apunta al archivo generado esperado. 3. El archivo generado existe en la etiqueta publicada. 4. El lanzamiento se construyó a partir del commit previsto. 5. Las notas de lanzamiento identifican la etiqueta o el commit que deben seleccionar los usuarios. 6. El workflow de pruebas ejercita el artefacto incluido, no solo la fuente mediante un atajo de desarrollo. Los proyectos que utilizan un bot de lanzamientos o un workflow de compilación deben revisar si ese propio workflow depende de una acción antigua. Una migración puede fallar de forma circular: el mantenedor actualiza la acción, pero el workflow de lanzamiento sigue invocando una acción obsoleta de checkout, configuración, empaquetado o publicación. Actualiza la CI utilizada para producir el artefacto antes de confiar en ella para demostrar que el artefacto está actualizado. Aquí también importa fijar referencias. Una etiqueta mayor mutable resulta cómoda para los usuarios, pero un workflow sensible a la seguridad puede fijar una acción a un SHA de commit completo y actualizarlo mediante un proceso revisado. Si un proyecto publica una etiqueta fácil de recordar y una referencia firmada o fijada por digest, las notas de lanzamiento deberían explicar la relación entre ambas. La migración de runtime es una buena oportunidad para eliminar referencias ambiguas y documentar por qué se considera confiable una referencia concreta. ## El soporte de Node 24 no significa que todo el proyecto deba ejecutarse con Node 24 En un repositorio que contiene una acción hay dos preguntas de compatibilidad distintas. La primera es si la acción puede ser lanzada por el runtime Node 24 de GitHub. La segunda es si la aplicación, biblioteca, suite de pruebas o herramienta de línea de comandos del proyecto admite Node 24. Las políticas de soporte pueden ser diferentes. Una acción puede ejecutarse con Node 24 mientras invoca un proyecto que todavía admite Node 18, 20 y 22. El runtime de la acción es un detalle de implementación de la plataforma de automatización; el runtime utilizado para probar el software puede ser una promesa pública de compatibilidad. Los mantenedores no deberían elevar silenciosamente la versión mínima de Node del proyecto solo porque GitHub cambió el runtime de las acciones. A la inversa, un proyecto que utilice APIs específicas de Node 24 en la implementación de su acción debería indicarlo en la documentación para contribuyentes. De lo contrario, quienes ejecuten las pruebas localmente podrían usar Node 20 y fallar solo cuando el paquete de la acción se ejecute en GitHub. Una matriz de runtime pequeña puede evitar esta diferencia: ```yaml strategy: matrix: node: [22, 24] steps: - uses: actions/checkout@v7 - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - run: npm ci - run: npm test ``` Esta matriz es un ejemplo, no una recomendación universal. Las versiones deben coincidir con el intervalo de soporte declarado por el proyecto. Si la acción se prueba como artefacto empaquetado, el workflow también debería invocarla a través de la misma ruta que usan los usuarios, no únicamente importando sus módulos fuente. En los proyectos que publican paquetes npm, la migración es además una ocasión para revisar los metadatos del paquete. `engines.node` debe describir el intervalo admitido por la aplicación o biblioteca, no limitarse a reflejar el runtime de la acción. Los lockfiles deben estar confirmados, y las actualizaciones de dependencias deben revisarse por separado de la migración de runtime para poder atribuir un fallo al cambio correcto. ## Los emuladores locales pueden ocultar el problema Las herramientas que ejecutan workflows de GitHub Actions localmente son útiles, pero no reproducen automáticamente el comportamiento de los runners alojados por GitHub. Un emulador local puede seleccionar una imagen de contenedor con Node 16 o Node 20, no implementar el mismo mapeo de runtimes de acciones o utilizar una versión distinta del runner. Por tanto, una ejecución local correcta no demuestra que la acción publicada funcione en el runtime Node 24 de GitHub. Un problema del proyecto `actions/checkout` ilustra la confusión: una herramienta de ejecución local puede informar de una imagen de contenedor antigua aunque la versión publicada de la acción utilice Node 24. El problema no tiene por qué estar en la acción; puede residir en el modelo de runtime del emulador. Los mantenedores deberían registrar qué partes del workflow se validan localmente y cuáles requieren un runner real alojado por GitHub o un runner autohospedado configurado correctamente. Un plan de pruebas práctico utiliza ambos entornos de forma deliberada. Ejecuta localmente las pruebas unitarias y de integración rápidas, y luego lanza un workflow real mínimo contra la versión empaquetada de la acción. El workflow real debe cubrir las entradas importantes de la acción, incluidos repositorios privados, archivos grandes, configuración de proxy, credenciales, eventos de pull request o salidas generadas cuando corresponda. Las pruebas locales siguen siendo valiosas para iterar, pero no deben presentarse como sustituto de la validación a nivel de plataforma. ## Qué deben cambiar los usuarios en sus workflows Los usuarios normalmente no necesitan reescribir cada paso del workflow. La prioridad es actualizar las referencias a acciones que admitan Node 24 y después investigar los fallos que persistan. Empieza por las acciones centrales del workflow: checkout, setup-node, caché, subida y descarga de artefactos, configuración de lenguajes, operaciones con contenedores y acciones de publicación. Una lista de actualización prudente es la siguiente: - Lee las notas de lanzamiento de la acción y confirma el soporte de Node 24. - Comprueba la versión mínima documentada del runner. - Revisa permisos, secretos, configuración de caché y cambios de autenticación. - Prueba por separado los pull requests procedentes de forks y los pushes internos. - Prueba el workflow en cada sistema operativo y arquitectura que realmente declares como compatibles. - Mantén explícita la propiedad `node-version` del proyecto o su archivo de versión. - Vuelve a ejecutar los jobs de lanzamiento y publicación con un simulacro o un destino de staging. - Elimina las variables obsoletas de exclusión de Node 20; ya no ofrecen una alternativa. No confundas `actions/setup-node` con el runtime utilizado por las acciones `uses:`. Este workflow instala Node 24 para los comandos de shell: ```yaml - uses: actions/setup-node@v7 with: node-version: 24 - run: npm test ``` Eso no repara una acción de terceros cuyo metadato todavía dice `using: node20`. El mantenedor debe actualizar esa acción, o hay que sustituirla por una alternativa mantenida. Si la acción está abandonada y el proyecto no puede aceptar el riesgo de ejecutar código no revisado, un script local pequeño puede ser más seguro que adoptar un fork sin verificar; aun así, la decisión debe tener en cuenta los permisos de la acción y el flujo de datos. Los usuarios también deberían resistirse a cambiar todas las versiones de acciones de una vez. Actualizar checkout, setup-node, caché, gestión de artefactos y una acción de despliegue en un solo commit dificulta aislar los fallos. Una serie escalonada de pull requests pequeños produce un historial de auditoría más claro y permite revertir con facilidad. En un proyecto comunitario, esa claridad ayuda a los empaquetadores posteriores y a quienes mantienen ramas antiguas. ## Qué deben incluir los mantenedores en las notas de lanzamiento Una nota que diga migrar a Node 24 es preferible al silencio, pero los usuarios necesitan detalles operativos. La nota debe indicar si el cambio afecta al runtime de la acción, al runtime del proyecto o a ambos. También debe nombrar el primer lanzamiento que contiene el cambio y explicar si los usuarios necesitan modificar sus referencias en los workflows. Debe identificar además los límites conocidos. Por ejemplo, el aviso de GitHub deja claro que macOS 13.4 y anteriores y ARM32 ya no son compatibles con las acciones JavaScript basadas en Node 24. Si el proyecto tiene una restricción adicional —como una dependencia nativa, una versión mínima del runner o la necesidad de una versión más reciente de npm—, debe aparecer en la misma nota de lanzamiento. Los mantenedores deben documentar cómo verificar la migración. Un comando breve para inspeccionar los metadatos de la acción, un enlace a la matriz de CI y una declaración de que se probó el artefacto `dist` incluido son más útiles que un changelog extenso de actualizaciones de dependencias. Si el proyecto tiene una rama estable que no recibirá la migración, hay que decirlo con claridad y proporcionar la última versión de acción compatible. También es un momento útil para publicar una política de soporte. Los usuarios de código abierto suelen inferir el soporte a partir de lo que casualmente pasa en la CI pública. Una tabla o un párrafo que separen runners alojados por GitHub, runners autohospedados, emuladores locales, sistemas operativos y arquitecturas evita esa promesa accidental. Ayuda a decidir si una actualización es apropiada antes de que el límite lo descubra el propio pipeline de despliegue. ## Implicaciones de seguridad y de la cadena de suministro La retirada de Node 20 es un acontecimiento de compatibilidad, pero las actualizaciones de acciones son cambios en la cadena de suministro. Una acción ejecuta código dentro de un contexto de workflow que puede contener el contenido del repositorio, tokens, credenciales de nube, material de firma o acceso a sistemas de despliegue. Un lanzamiento nuevo merece la misma revisión que cualquier otra dependencia que se ejecute con esos privilegios. Revisa el diff entre las referencias antigua y nueva de la acción, no solo el titular del lanzamiento. Comprueba los cambios en permisos, comandos de shell, endpoints de red, gestión de artefactos y limpieza posterior al job. Para acciones que procesan pull requests no confiables, verifica si el nuevo lanzamiento cambia cuándo se hace checkout del código o cuándo quedan disponibles las credenciales. La migración de runtime no debe utilizarse como motivo para omitir esas comprobaciones. La caché merece una atención especial. Puede mejorar el rendimiento, pero un workflow que restaura datos de dependencias antes de procesar entradas no confiables puede crear una vía de envenenamiento o exposición de credenciales. La documentación actual de `setup-node` recomienda desactivar la caché automática cuando no sea necesaria en workflows con privilegios elevados o información sensible. La recomendación es más amplia que Node 24, pero resulta directamente pertinente cuando una actualización de acciones modifica el comportamiento de la caché. Fijar las referencias de las acciones a SHAs de commits revisados puede reducir el riesgo de que una etiqueta se mueva inesperadamente, aunque añade trabajo de mantenimiento. Los proyectos que usan Dependabot, Renovate u otro mecanismo de actualización deben asegurarse de que la herramienta entiende la migración del runtime y no reabra continuamente la misma versión mayor obsoleta. Un lanzamiento firmado, metadatos de procedencia y una compilación reproducible son complementos útiles, pero ninguno sustituye la revisión del código que se ejecutará con secretos. ## Alternativas cuando una acción no ha migrado No existe un sustituto universal para una acción sin mantenimiento. La decisión correcta depende de lo que haga, de los permisos que necesite y de si su comportamiento es esencial para el proyecto. Las opciones suelen agruparse en cuatro caminos. Primero, pide al mantenedor un lanzamiento para Node 24 y contribuye a la migración si el proyecto está activo y el cambio es sencillo. El pull request debe incluir el artefacto compilado, pruebas contra la matriz de runners compatible y documentación de lanzamiento. Actualizar únicamente `runs.using` sin probar el paquete es incompleto. Segundo, sustituye la acción por un proyecto mantenido que tenga una política clara de lanzamientos y soporte. Compara comportamiento y permisos, no solo nombres de funciones. Una acción con menos estrellas pero con mantenimiento transparente y un modelo de permisos limitado puede encajar mejor que una acción popular cuyo proceso actual de publicación sea opaco. Tercero, traslada una parte pequeña de la lógica a pasos ordinarios del workflow o a un script del repositorio. Esto puede reducir la dependencia de un runtime de acción, pero no vuelve automáticamente seguro el código. Los scripts de shell siguen ejecutándose con los permisos del workflow y deben validar entradas, citar los datos correctamente y evitar exponer secretos. Cuarto, aísla la acción antigua en un job o repositorio específico mientras se prepara la migración. Es una estrategia de contención, no una solución permanente. Limita sus permisos, evita pasar credenciales de despliegue y haz explícitas sus salidas. El proyecto debe indicar que la disposición es temporal para que los usuarios posteriores no la confundan con soporte. Un fork puede ser apropiado cuando el proyecto original está abandonado y el código es lo bastante pequeño como para auditarlo. También puede crear deuda de mantenimiento a largo plazo. El fork debe documentar su relación con la acción original, conservar los avisos de licencia, publicar sus propios lanzamientos y explicar cómo pueden verificar los usuarios el artefacto generado. Cambiar el nombre de una etiqueta sin establecer un proceso de lanzamiento solo traslada la incertidumbre. ## La lección más amplia para la automatización de código abierto Los runtimes gestionados por una plataforma recuerdan que una acción de código abierto tiene dos contratos de mantenimiento. El primero es con el ecosistema de fuentes: dependencias, compiladores, gestores de paquetes y versiones del lenguaje. El segundo es con la plataforma de automatización: versiones de runners, sistemas operativos compatibles, semántica de ejecución, permisos y convenciones de artefactos. Un proyecto puede cumplir un contrato y fallar el otro. La migración a Node 24 también expone una debilidad recurrente de la infraestructura abierta: los usuarios suelen descubrir la política de soporte mediante un job fallido. Se puede evitar. Los repositorios pueden publicar una matriz probada, mantener visible el artefacto de lanzamiento, declarar versiones mínimas de runner y añadir un job programado que pruebe los próximos cambios de runtime antes de que la plataforma los haga obligatorios. El runtime de la acción debe probarse como una superficie de producto. Merece notas de lanzamiento, pruebas de compatibilidad, una revisión de seguridad y un plan de reversión. El código fuente es solo una parte de lo que instalan los usuarios; los metadatos, el paquete generado, la etiqueta, el runner y los permisos forman el paquete de software real. Para los usuarios, el trabajo inmediato consiste en actualizar a versiones compatibles de las acciones y verificar los entornos que importan. Para los mantenedores, el trabajo más importante es conseguir que la próxima migración resulte aburrida. Eso exige una política de soporte publicada, requisitos explícitos de runner, un artefacto de lanzamiento reproducible y una CI que pruebe el camino que ejecutan los usuarios. Node 24 es la nueva base de GitHub Actions. La calidad de la migración se medirá menos por si cambió un archivo YAML y más por si los contribuyentes pueden entender el nuevo límite antes de que llegue a producción. ## Fuentes y lecturas adicionales - [GitHub: Node 20 ya no está disponible en GitHub Actions](https://github.blog/changelog/2026-09-23-node-20-is-no-longer-available-in-github-actions/) — aviso de retirada, Node 24 como valor predeterminado, eliminación de la exclusión y entornos de macOS y ARM32 afectados. - [GitHub: obsolescencia de Node 20 en los runners de GitHub Actions](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/) — calendario de migración y orientación previa para mantenedores, usuarios y administradores de runners autohospedados. - [Calendario de lanzamientos de Node.js](https://nodejs.org/en/about/previous-releases) — fecha de final de vida de Node 20 y estado de soporte de Node 22 y Node 24. - [Sintaxis de metadatos de GitHub Actions](https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax) — declaración `runs.using` para acciones JavaScript. - [Changelog de actions/checkout](https://github.com/actions/checkout/blob/main/CHANGELOG.md) — ejemplo oficial de lanzamientos y actualizaciones de documentación relacionados con Node 24. - [Repositorio de actions/setup-node](https://github.com/actions/setup-node) — uso actual, sintaxis de versiones de Node, orientación sobre caché y requisitos de runners. - [Repositorio de actions/runner](https://github.com/actions/runner) — implementación de código abierto del runner y automatización de sus actualizaciones de Node. - [Changelog de GitHub: Actions](https://github.blog/changelog/label/actions/) — cambios relacionados con la plataforma Actions y el ecosistema de runners.