GitHub Actions Switches from Node.js 20 to 24: Why Site Deployment Might Stop

23 сентября GitHub окончательно убрал Node.js 20 из сред выполнения GitHub Actions. JavaScript-действия теперь запускаются на Node.js 24, а временная возможность принудительно оставить старую версию больше не работает. Для владельца сайта это может выглядеть как новость исключительно для разработчиков, пока очередное обновление не перестанет собираться или выкладываться на сервер.

Важно различать две среды. Изменение GitHub не переводит сам сайт на Node.js 24 и не меняет PHP на сервере. Оно касается автоматических действий, из которых собран процесс проверки и публикации кода: установки зависимостей, сборки статики, запуска тестов, создания архива и доставки новой версии.

Собственные JavaScript-действия указывают среду запуска в служебном файле. GitHub рекомендует перевести значение runs.using на node24 и выпустить новую версию действия. Если проект использует чужие действия, нужно перейти на их актуальные выпуски с поддержкой Node.js 24.

Сбой может появиться и без собственного JavaScript. Старый выпуск действия для загрузки артефакта, кеширования зависимостей или подключения к серверу способен внутри зависеть от Node.js 20. Файл процесса при этом выглядит привычно, а ошибка возникает только на этапе выполнения.

Обновлять ссылки на действия вслепую тоже нельзя. Между крупными версиями могли измениться параметры, права доступа или формат результата. Правильная миграция включает чтение описания выпуска и контрольный запуск на тестовой ветке.

Ручное копирование файлов кажется простым запасным вариантом, но оно плохо воспроизводится. Один сотрудник забудет очистить кеш, другой забудет удалить устаревший файл, третий перенесёт конфигурацию из тестовой среды. Автоматический процесс ценен не скоростью, а одинаковой последовательностью действий.

Для интернет-магазина полезный конвейер проверяет хотя бы сборку интерфейса, синтаксис, тесты критичных компонентов и наличие обязательных файлов. После этого он создаёт неизменяемый пакет версии, сохраняет его и только затем выполняет выкладку. Если шаг сборки перестал работать из-за обновления среды, публиковать код вручную в обход проверок особенно рискованно.

Сбой конвейера лучше воспринимать как остановку защитного механизма. Сайт может продолжать работать, но команда временно теряет надёжный способ выпускать исправления.

GitHub уточняет ограничения для self-hosted runners: Node.js 24 несовместим с macOS 13.4 и более ранними версиями и официально не поддерживает ARM32. Такие исполнители больше не подходят для нового режима.

Собственный runner часто устанавливают один раз и забывают. Он годами остаётся на сервере сборки, имеет доступ к репозиторию, ключам развёртывания и внутренней сети. Поэтому проверка должна охватывать не только версию приложения runner, но и операционную систему, архитектуру процессора и минимальные версии системных библиотек.

Если старое устройство нельзя обновить, его следует заменить или вывести из процесса. Добавление неофициальной среды и обходных параметров возвращает сборку в рабочее состояние лишь внешне, но оставляет неподдерживаемую основу рядом с секретами проекта.

Начать стоит со списка всех файлов процессов и используемых действий. Для каждого внешнего действия фиксируют разработчика, закреплённую версию и назначение. Ссылки на случайную ветку опаснее стабильного выпуска: её содержимое может измениться без правки в вашем репозитории.

Затем проверяют собственные действия и инструменты командной строки. Нужно убедиться, что они запускаются на Node.js 24, не используют API, удалённые из среды выполнения, и работают с текущими версиями зависимостей. Локальный успешный запуск не заменяет тест в GitHub Actions, потому что окружение и права отличаются.

Следующий этап — разрешения. Обновлённому действию не следует автоматически выдавать запись во весь репозиторий или доступ ко всем секретам. Права токена задают минимально необходимыми, а секреты передают только тем шагам, которым они действительно нужны.

Наконец, выполняют тестовую сборку и выкладку в отдельное окружение. Проверяют не только зелёный статус, но и сам результат: открытие страниц, загрузку статики, версию файлов, миграции базы и очистку кеша. Для рабочего сайта должна существовать понятная процедура возврата к предыдущему пакету.

Переход GitHub Actions на Node.js 24 — не функция, которую нужно включить на сайте. Это изменение основания, на котором выполняются автоматические операции. Оно полезно тем, что обнаруживает забытые действия, устаревшие исполнители и процессы, которые никто давно не запускал в чистой среде.

Если после замены версии процесс снова стал зелёным, работа ещё не закончена. Надёжный результат — когда команда знает, какие действия участвуют в выпуске, откуда они взяты, какие права имеют и как проверить опубликованную версию. Тогда очередное обновление среды не превращается в неожиданную остановку разработки.

On September 23, GitHub permanently removed Node.js 20 from GitHub Actions execution environments. JavaScript actions now run on Node.js 24, and the temporary option to force the old version no longer works. For a site owner, this may initially appear as news solely for developers until the next update fails to build or deploy to the server.

It is important to distinguish between two environments. GitHub's change does not migrate the website itself to Node.js 24, nor does it alter PHP on the server. It affects the automated actions that constitute the code verification and publication pipeline: installing dependencies, building static assets, running tests, creating archives, and delivering the new version.

Custom JavaScript actions specify the runtime environment in a metadata file. GitHub recommends updating the runs.using value to node24 and releasing a new version of the action. If a project relies on third-party actions, you must switch to their latest releases that support Node.js 24.

A failure can occur even without your own JavaScript. An old release of an action for uploading artifacts, caching dependencies, or connecting to a server may internally depend on Node.js 20. The process file looks familiar, but the error occurs only at runtime.

You also cannot blindly update action links. Between major versions, parameters, permissions, or result formats may have changed. Proper migration includes reading the release notes and running a control test on a staging branch.

Manually copying files seems like a simple fallback, but it is difficult to reproduce consistently. One employee might forget to clear the cache, another might forget to delete an outdated file, and a third might copy configuration from the test environment. An automated process is valuable not for speed, but for consistent execution.

For an online store, a useful pipeline checks at least the interface build, syntax, tests for critical components, and the presence of required files. Only after that does it create an immutable versioned package, save it, and then perform the deployment. If a build step fails due to an environment update, manually publishing code while bypassing checks is especially risky.

A pipeline failure should be viewed as a safety mechanism stopping. The site may continue to run, but the team temporarily loses a reliable way to release fixes.

GitHub clarifies restrictions for self-hosted runners: Node.js 24 is incompatible with macOS 13.4 and earlier versions and does not officially support ARM32. Such runners are no longer suitable for the new mode.

A self-hosted runner is often installed once and then forgotten. It remains on the build server for years, with access to the repository, deployment keys, and the internal network. Therefore, the check must cover not only the runner application version but also the operating system, processor architecture, and minimum versions of system libraries.

If an old device cannot be updated, it should be replaced or removed from the process. Adding an unofficial environment and workarounds may make the build appear functional, but it leaves an unsupported foundation next to project secrets.

Start with a list of all workflow files and the actions used. For each external action, record the author, the pinned version, and its purpose. Links to a random branch are more dangerous than a stable release: its contents can change without any modification in your repository.

Then, verify your own actions and command-line tools. Ensure they run on Node.js 24, do not use APIs removed from the runtime, and work with current dependency versions. A successful local run does not replace a test in GitHub Actions, as the environment and permissions differ.

The next stage is permissions. The updated action should not automatically be granted write access to the entire repository or access to all secrets. Token permissions must be set to the minimum necessary, and secrets should be passed only to the steps that actually require them.

Finally, perform a test build and deployment to a separate environment. Check not only the green status but also the actual result: page loading, static asset delivery, file versions, database migrations, and cache clearing. For a production site, there must be a clear procedure to roll back to the previous package.

The transition of GitHub Actions to Node.js 24 is not a feature to toggle on a website. It is a change to the foundation on which automated operations run. It is useful because it uncovers forgotten actions, obsolete runners, and processes that have not been executed in a clean environment for a long time.

If the process turns green again after the version change, the work is not yet finished. A reliable outcome is when the team knows which actions are involved in the release, where they come from, what permissions they have, and how to verify the published version. Then, the next environment update does not turn into an unexpected halt to development.