---
service: "Publicasta"
schema_version: "1.0"
article_id: 716
title: "GitHub Actions убрал Node 20: что теперь проверить сопровождающим open-source-проектов"
language: "ru"
default_language: "en"
canonical_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers?lang=ru"
json_url: "https://publicasta.com/open_source_radar/github_actions_node24_migration_open_source_maintainers.json?lang=ru"
api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/github_actions_node24_migration_open_source_maintainers?lang=ru"
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:32+00:00"
updated_at: "2026-09-28T07:04:32+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 убрал Node 20: что теперь проверить сопровождающим open-source-проектов

> GitHub Actions перевёл JavaScript-действия на Node 24 после удаления Node 20. Основная миграция связана с метаданными и выпуском релиза, но self-hosted runner, старые версии macOS, ARM32, кэши и локальные эмуляторы всё ещё могут превратить обновление в неудачную сборку.

GitHub Actions перешёл от предупреждений к реальным сбоям: Node 20 больше недоступен как среда выполнения JavaScript-действий на runner’ах GitHub-hosted. С 23 сентября 2026 года такие действия запускаются на Node 24, а временный обходной путь, позволявший репозиториям продолжать использование Node 20, удалён.

 ![Редакционная технологическая иллюстрация: сопровождающий проект с открытым исходным кодом проверяет переход GitHub Actions с Node 20 на Node 24, рядом показаны артефакты CI и собственный runner.](https://publicasta.com/storage/projects/10/pages/716/2026/09/eb75953e-6fdf-433e-8e16-e6eabd4850fd.webp)

 Для большинства репозиториев видимое исправление выглядит просто: обновить ссылки на actions и продолжить работу. Для сопровождающих open-source-проектов задача шире. Action может выглядеть исправным в дереве исходников, тогда как опубликованный тег всё ещё указывает на старый bundle в `dist`. Workflow может использовать актуальное JavaScript-действие и всё равно завершаться ошибкой на self-hosted runner, старом Mac или плате ARM32. Локальные инструменты, эмулирующие Actions, тоже могут продолжать запускать неправильную версию Node и создавать ложное ощущение совместимости.

 Практически это стоит рассматривать как аудит релиза и матрицы поддержки, а не как однострочную замену `node20` на `node24`. Смена runtime — непосредственное событие. Более долгосрочный вопрос заключается в том, как open-source-проекты описывают поддерживаемые runner’ы, публикуют неизменяемые артефакты actions и тестируют среды, которыми действительно пользуются их пользователи.

 ## Что изменилось 23 сентября

 В уведомлении GitHub сказано, что runner’ы теперь используют Node 24 для JavaScript-действий. Там же указано, что переменная `ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION` больше недоступна. Во время миграции она была временным escape hatch, но теперь не является поддерживаемым механизмом совместимости. Изменение применяется к github.com и GitHub с Data Residency.

 Важно различать runtime самого action и версию Node, установленную для workflow. JavaScript-действие объявляет среду выполнения в `action.yml`, обычно в блоке такого вида:

 ```yaml
runs:
  using: node24
  main: dist/index.js
```

 Эта настройка определяет, какой runtime Node GitHub использует для запуска action. Она не связана с последующим шагом `actions/setup-node`, который устанавливает версию Node для команд собственного процесса сборки, тестирования или упаковки репозитория. Установка Node 20 через `setup-node` не делает action с объявлением `node20` совместимым с runner’ом, где runtime действий на Node 20 удалён. И наоборот: изменение заявленного runtime action автоматически не меняет версию Node, используемую тестами проекта.

 Поэтому в репозитории может быть несколько независимых участков миграции:

 - JavaScript-действия, объявленные в собственных файлах `action.yml` репозитория.
- Сторонние actions, на которые ссылаются workflow-файлы.
- Скомпилированный JavaScript в `dist/`, если action хранит собранный код в Git.
- Версии self-hosted runner и операционные системы.
- Собственная версия Node проекта для тестов, сборки, CLI или release-скриптов.

 В предыдущем уведомлении о прекращении поддержки GitHub дал сопровождающим переходный период и обозначил окончательную дату удаления. Сам Node.js указывает, что Node 20 достиг конца жизненного цикла 24 марта 2026 года. Поэтому изменение в Actions удаляет путь выполнения, уже основанный на неподдерживаемом upstream-runtime; это не новая политика выпуска Node.js.

 ## Первый аудит: найдите код, который действительно запустится

 Начните с workflow-файлов, но не ограничивайтесь ими. Нужно искать и прямое использование actions, и определения самих actions. Полезный первый проход по репозиторию выглядит так:

 ```text
.github/workflows/
action.yml
action.yaml
*/action.yml
*/action.yaml
```

 В workflow ищите ссылки вроде `uses: owner/project@vN`. Тег major-версии не говорит, какой runtime Node использует выбранный релиз. Action нужно проверять на разрешённом теге или commit. Это особенно важно для небольших community-actions, которые могли получить изменения в исходниках, но не новый опубликованный релиз.

 Если action поддерживается в том же репозитории, откройте `action.yml` и найдите значение `runs.using`. Если там указано `node20`, замените его на `node24`, а затем пересоберите bundle action, когда проект ожидает, что `dist/` будет закоммичен. Многие JavaScript-actions запускают скомпилированные файлы, а не TypeScript или JavaScript из исходного дерева. Исправление исходников при устаревшем bundle не является завершённым релизом.

 Следующий вопрос — совместимы ли зависимости action с Node 24. Node 24 — не просто метка, которую принимает parser метаданных. В нём более новый V8 и новый набор API Node, поэтому могут проявиться предположения о загрузке модулей, package exports, поведении OpenSSL, файловых операциях или stream API. Риск не в том, что каждое действие на Node 20 обязательно сломается. Риск в том, что проект мог ни разу не прогнать настоящий release-артефакт в новой среде.

 Для сторонних actions выбирайте релиз сопровождающего, в котором прямо заявлена поддержка Node 24. Не считайте замену `@v3` на `@v4` правильной только потому, что число стало больше. Прочитайте release notes, проверьте метаданные action и выясните, не появились ли побочные изменения поведения. Миграция runtime — плохая причина принимать major-version без проверки входов, выходов, permissions и безопасности.

 ## Почему обновления first-party actions полезны как пример

 First-party actions GitHub показывают, как можно проводить такую миграцию на практике. В актуальном changelog `actions/checkout` зафиксированы обновления Node 24, а текущая документация `actions/setup-node` указывает новые версии action, использующие Node 24. Эти проекты не ограничиваются изменением одного поля: они выпускают новый релиз, обновляют документацию, прогоняют собственную тестовую матрицу и отдельно отмечают требования к runner’ам и изменения поведения.

 Небольшим репозиториям стоит перенять этот подход. Ответственный миграционный релиз должен ясно сообщать четыре вещи: в какой версии action появился переход, какая версия runner нужна, какие операционные системы или архитектуры больше не поддерживаются и изменились ли входы либо выходы. Эти сведения должны попасть в release notes, даже если diff кода занимает несколько строк.

 Проект `actions/setup-node` также напоминает, что миграция runtime может совпасть с другими изменениями. Его актуальная документация описывает action на базе Node 24 и содержит рекомендации по кэшированию пакетных менеджеров. В ней предупреждается, что автоматический cache не всегда уместен в workflow с повышенными привилегиями или чувствительными credentials. Это предупреждение не вызвано Node 24, но оно важно в том же аудите: сопровождающие часто одновременно обновляют версии actions и настройки безопасности workflow.

 Пользователь, обновляющий action ради поддержки Node 24, может одновременно получить изменения в настройках кэша, аутентификации, минимальной версии runner, обнаружении пакетного менеджера или поведения по умолчанию. Поэтому проверка обновления должна звучать не как «YAML разбирается?», а как «какой код теперь выполняется, с какими правами и каким закэшированным состоянием?».

 ## Self-hosted runner — самый острый участок

 В уведомлении GitHub названы два ограничения совместимости Node 24: macOS 13.4 и более старые версии несовместимы, а ARM32 официально не поддерживается. Для open-source-проектов это особенно существенно: их участники и пользователи разнообразнее стандартной матрицы GitHub-hosted runner’ов. У проекта может быть зелёная сборка на Ubuntu, тогда как пользователи запускают action на старом Intel Mac, устройстве класса Raspberry Pi с ARM32 или частном runner’е за firewall.

 Проблему операционной системы легко не заметить, когда workflow использует общий label вроде `macos-latest`. Labels GitHub-hosted со временем меняются, а self-hosted label обычно обозначает машину, которую администратор обновляет вручную. Репозиторию, поддерживающему self-hosted runner’ы, стоит описывать минимальную версию runner и диапазон поддерживаемых систем, а не считать hosted-образы полной политикой совместимости.

 Проблема архитектуры ещё менее заметна. ARM32 редко встречается в hosted CI, поэтому стандартная матрица может никогда его не запускать. Если пользователи работают с Actions локально или на небольших edge-устройствах, сопровождающим нужно решить, сохраняется ли поддержка ARM32. Решение должно быть явным. Формулировки «action работает на Linux» недостаточно, когда поддержка архитектур runtime различается по платформам.

 Администраторам self-hosted runner следует обновить ПО runner до диагностики сбоев action. Некоторые совместимые с Node 24 релизы требуют достаточно свежего runner, и документация конкретного action должна считаться источником требований к минимальной версии. Обновление runner не делает несовместимую операционную систему совместимой, но старый runner способен выдать сбивающую с толку ошибку ещё до того, как управление дойдёт до кода action.

 Безопасная последовательность такова: поэтапно обновить runner, запустить показательный workflow без секретов или с тестовыми credentials, а затем проверить workflow, использующие deployment, publishing или release permissions. Базового job с unit-тестами недостаточно, если action также загружает артефакты, подписывает пакеты, открывает pull request или обменивается OIDC-токеном.

 ## Опубликованный артефакт — часть программы

 JavaScript-actions часто хранят скомпилированную директорию `dist` в Git, чтобы пользователям не приходилось устанавливать зависимости или собирать action во время workflow. Отсюда появляется ловушка релиза: в репозитории может быть современный исходный файл, а тег, который используют пользователи, всё ещё содержит старый bundle.

 Сопровождающим нужно проверить ровно тот артефакт, который будет выполнен на release ref. Это означает проверку следующих пунктов:

 1. `action.yml` или `action.yaml` объявляет `node24`.
2. Путь `main` или `pre` указывает на ожидаемый сгенерированный файл.
3. Сгенерированный файл присутствует в опубликованном теге.
4. Релиз собран из нужного commit.
5. Release notes называют тег или commit, который должны выбрать пользователи.
6. Тестовый workflow проверяет собранный bundle, а не только исходники через development shortcut.

 Проектам, использующим release bot или build workflow, следует проверить, не зависит ли сам workflow от старого action. Миграция может провалиться по кругу: сопровождающий обновил action, но release workflow всё ещё вызывает устаревшие checkout, setup, packaging или publishing actions. Сначала обновите CI, который производит артефакт, и только потом рассчитывайте, что этот CI докажет актуальность артефакта.

 Здесь важна и фиксация ссылок. Изменяемый major-tag удобен пользователям, но security-sensitive workflow может фиксировать action на полном commit SHA и обновлять его через проверяемый процесс. Если проект публикует и понятный человеку тег, и подписанную либо зафиксированную digest-ссылку, release notes должны объяснять их связь. Миграция runtime — подходящий момент, чтобы убрать неоднозначные ссылки и описать, почему конкретный ref считается доверенным.

 ## Поддержка Node 24 для action не означает, что весь проект должен работать на Node 24

 В репозитории, содержащем Action, есть два разных вопроса совместимости. Первый: можно ли запустить сам Action в runtime Node 24 GitHub. Второй: поддерживают ли Node 24 собственное приложение проекта, библиотека, тестовый набор или command-line tool. Политики поддержки у этих частей могут различаться.

 Action может работать на Node 24 и при этом вызывать проект, который продолжает поддерживать Node 18, 20 и 22. Runtime action — деталь реализации платформенной автоматизации, а runtime, на котором тестируется программа, может быть публичным обещанием совместимости. Сопровождающим не следует молча повышать минимальную версию Node проекта только потому, что GitHub изменил runtime action.

 И наоборот, если реализация action использует API, специфичные для Node 24, это нужно сказать в документации для contributors. Иначе разработчики будут запускать тесты локально на Node 20 и узнают о проблеме только при выполнении bundle на GitHub. Небольшая runtime-матрица помогает избежать такого расхождения:

 ```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
```

 Это пример, а не универсальная рекомендация. Версии должны соответствовать заявленному диапазону поддержки проекта. Если action тестируется как упакованный артефакт, workflow должен также вызывать его тем же способом, каким его вызывают пользователи, а не только импортировать исходные модули.

 Для проектов, публикующих npm-пакеты, миграция — повод проверить и package metadata. Поле `engines.node` должно описывать поддерживаемый диапазон приложения или библиотеки, а не просто повторять runtime action. Lockfiles следует коммитить, а обновления зависимостей — рассматривать отдельно от миграции runtime, чтобы причину сбоя можно было связать с правильным изменением.

 ## Локальные эмуляторы могут скрыть проблему

 Инструменты локального запуска GitHub Actions полезны, но не воспроизводят автоматически поведение GitHub-hosted runner. Локальный эмулятор может выбрать container image с Node 16 или Node 20, не реализовать ту же карту runtime actions или использовать другую версию runner. Поэтому зелёный локальный запуск не доказывает, что опубликованный action работает в runtime Node 24 GitHub.

 Один из вопросов в проекте `actions/checkout` хорошо показывает источник путаницы: локальный инструмент может сообщать о старом container image, хотя релиз action использует Node 24. Проблема может быть не в action, а в модели runtime самого эмулятора. Сопровождающим стоит фиксировать, какие части workflow проверяются локально, а какие требуют настоящего GitHub-hosted runner или корректно настроенного self-hosted runner.

 Практический план использует обе среды осознанно. Быстрые unit- и integration-тесты выполняются локально, после чего минимальный настоящий workflow запускается против упакованного релиза action. Реальный workflow должен покрывать существенные входы: private repositories, большие файлы, proxy settings, credentials, события pull request или генерируемые outputs, если они применимы. Локальная проверка остаётся полезной для итераций, но её нельзя выдавать за замену валидации на уровне платформы.

 ## Что пользователям изменить в workflow

 Обычно пользователям не нужно переписывать каждый шаг workflow. Приоритет — обновить ссылки на релизы actions с поддержкой Node 24, а затем разобраться с оставшимися ошибками. Начните с действий, от которых зависит основная работа: checkout, setup-node, cache, загрузка и скачивание артефактов, настройка языка, операции с контейнерами и публикация.

 Безопасный список проверки выглядит так:

 - Прочитайте release notes action и подтвердите поддержку Node 24.
- Проверьте документированную минимальную версию runner.
- Пересмотрите permissions, secrets, cache settings и изменения аутентификации.
- Отдельно протестируйте pull request из fork и внутренние push.
- Проверьте каждую операционную систему и архитектуру, которые действительно поддерживаете.
- Оставьте собственный `node-version` проекта или version file явным.
- Повторите release- и publishing jobs с dry-run или staging destination.
- Удалите устаревшие переменные обхода Node 20: fallback больше не предоставляется.

 Не смешивайте `actions/setup-node` с runtime actions, вызванных через `uses:`. Этот workflow устанавливает Node 24 для shell-команд:

 ```yaml
- uses: actions/setup-node@v7
  with:
    node-version: 24
- run: npm test
```

 Он не исправляет отдельный сторонний action, в метаданных которого всё ещё указано `using: node20`. Такой action должен обновить сопровождающий или его нужно заменить поддерживаемой альтернативой. Если action заброшен, а проект не может принять риск запуска непроверенного кода, небольшой локальный скрипт может оказаться безопаснее непроверенного fork. Но это решение нужно принимать с учётом permissions action и движения данных.

 Не стоит также менять все версии actions одним коммитом. Одновременное обновление checkout, setup-node, cache, обработки артефактов и deployment action усложняет локализацию ошибки. Серия небольших pull request даёт более ясный audit trail и позволяет откат. Для community-проекта такая прозрачность полезна downstream-пакетировщикам и участникам, которые сопровождают старые ветки.

 ## Что сопровождающим указать в release notes

 Запись «переход на Node 24» лучше молчания, но пользователям нужны эксплуатационные подробности. В заметке следует указать, затрагивает ли изменение runtime action, runtime проекта или оба уровня. Нужно назвать первый релиз с исправлением и объяснить, понадобится ли пользователям менять ссылки в workflow.

 Следует также назвать известные ограничения. Например, уведомление GitHub ясно сообщает, что macOS 13.4 и более ранние версии, а также ARM32 больше не поддерживаются JavaScript-actions на Node 24. Если у проекта есть отдельное ограничение — native dependency, минимальная версия runner или требование более свежего npm — оно должно быть в той же release note.

 Сопровождающим стоит описать способ проверки миграции. Короткая команда для просмотра метаданных action, ссылка на CI-матрицу и заявление о тестировании bundle `dist` полезнее длинного списка обновлённых зависимостей. Если стабильная ветка не получит миграцию, это следует сказать прямо и указать последний поддерживаемый релиз action.

 Сейчас также удобно опубликовать политику поддержки. Пользователи open-source-проектов часто выводят её из того, что случайно проходит в публичном CI. Таблица или абзац, разделяющие GitHub-hosted runner, self-hosted runner, локальные эмуляторы, операционные системы и архитектуры, предотвращают такое случайное обещание. Пользователь сможет понять, подходит ли ему обновление, до того как границу обнаружит production pipeline.

 ## Последствия для безопасности и supply chain

 Удаление Node 20 — событие совместимости, но обновление action является изменением цепочки поставок. Action выполняет код в контексте workflow, где могут находиться содержимое репозитория, токены, облачные credentials, ключи подписи или доступ к системам deployment. Новый релиз должен проходить такую же проверку, как любая зависимость, запускаемая с подобными правами.

 Сравнивайте diff между старым и новым action ref, а не только заголовок релиза. Проверяйте изменения permissions, shell-команд, сетевых endpoints, обработки артефактов и post-job cleanup. Для actions, обрабатывающих недоверенные pull request, выясните, изменился ли момент checkout кода или выдачи credentials. Миграция runtime не должна становиться поводом пропускать эти проверки.

 Кэшу нужно уделить отдельное внимание. Он ускоряет работу, но восстановление dependency data до обработки недоверенного ввода может создать путь для poisoning или раскрытия credentials. Текущая документация `setup-node` рекомендует отключать автоматическое кэширование пакетного менеджера, если оно не нужно workflow с повышенными привилегиями или чувствительными данными. Рекомендация шире темы Node 24, но она напрямую важна, когда обновление action меняет поведение cache.

 Фиксация action на проверенных commit SHA способна уменьшить риск неожиданного перемещения тега, хотя добавляет работы по сопровождению. Проектам, использующим Dependabot, Renovate или другой механизм обновлений, нужно убедиться, что инструмент понимает миграцию runtime и не открывает снова тот же устаревший major. Подписанный релиз, provenance metadata и воспроизводимая сборка полезны, но не заменяют review кода, который будет работать с секретами.

 ## Варианты, если action ещё не мигрировал

 Универсальной замены неподдерживаемому action нет. Решение зависит от его назначения, необходимых permissions и того, насколько критично поведение для проекта. Обычно есть несколько направлений.

 Во-первых, попросите сопровождающего выпустить версию с Node 24 и предложите миграцию, если проект активен, а изменение достаточно прямолинейно. Pull request должен включать собранный артефакт, тесты на поддерживаемой матрице runner’ов и документацию релиза. Изменить только `runs.using` без проверки bundle недостаточно.

 Во-вторых, замените action поддерживаемым проектом с понятной политикой релизов и совместимости. Сравнивайте поведение и permissions, а не только названия функций. Action с меньшим числом stars, но прозрачным сопровождением и узкой моделью прав может лучше подойти, чем популярный проект с непрозрачным процессом выпуска.

 В-третьих, перенесите небольшой участок логики в обычные workflow steps или скрипт репозитория. Это уменьшает зависимость от runtime action, но не делает код автоматически безопасным. Shell-скрипты по-прежнему выполняются с workflow permissions, должны проверять входы, корректно экранировать данные и не раскрывать секреты.

 В-четвёртых, изолируйте legacy-action в отдельном job или репозитории, пока готовится миграция. Это стратегия сдерживания, а не постоянное решение. Ограничьте permissions, не передавайте deployment credentials и делайте outputs явными. Проект должен сообщить о временном характере схемы, чтобы downstream-пользователи не приняли её за полноценную поддержку.

 Fork уместен, когда исходный проект заброшен, а код достаточно мал для аудита. Но он может создать долгосрочный долг сопровождения. В fork нужно описать связь с upstream-action, сохранить лицензионные уведомления, публиковать собственные релизы и объяснять пользователям, как проверить сгенерированный артефакт. Переименованный тег без release process лишь переносит неопределённость.

 ## Более широкий урок для open-source-автоматизации

 Управляемые платформой runtime напоминают, что у open-source action есть два контракта сопровождения. Первый связан с экосистемой исходного кода: зависимостями, компиляторами, пакетными менеджерами и релизами языка. Второй — с платформой автоматизации: версиями runner, поддерживаемыми системами, семантикой выполнения, permissions и правилами публикации артефактов. Проект может выполнить один контракт и нарушить другой.

 Миграция Node 24 также показывает постоянную слабость инфраструктурных open-source-проектов: пользователи часто узнают политику поддержки из упавшего job. Этого можно избежать. Репозиторий способен опубликовать протестированную матрицу, держать release artifact видимым, указать минимальные версии runner и добавить плановый job, проверяющий будущие изменения runtime до того, как платформа сделает их обязательными.

 Runtime action нужно тестировать как отдельную поверхность продукта. Ему нужны release notes, тесты совместимости, security review и план отката. Исходный код — только часть того, что устанавливает пользователь; фактический пакет образуют метаданные, сгенерированный bundle, тег, runner и permissions.

 Для пользователей непосредственная задача — обновить поддерживаемые релизы actions и проверить важные среды. Для сопровождающих более важная задача — сделать следующую миграцию скучной. Для этого нужны опубликованная политика поддержки, явные требования к runner, воспроизводимый release artifact и CI, который тестирует путь выполнения пользователя. Node 24 стал новым baseline в GitHub Actions. Качество миграции будет определяться не тем, изменился ли YAML, а тем, могут ли contributors понять новую границу до того, как она проявится в production.

 ## Источники и дополнительные материалы

 - [GitHub: Node 20 больше недоступен в GitHub Actions](https://github.blog/changelog/2026-09-23-node-20-is-no-longer-available-in-github-actions/) — уведомление об удалении, переходе на Node 24, исчезнувшем обходном пути и затронутых средах macOS и ARM32.
- [GitHub: прекращение поддержки Node 20 на runner’ах GitHub Actions](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/) — график миграции и прежние рекомендации для сопровождающих, пользователей и администраторов self-hosted runner.
- [График релизов Node.js](https://nodejs.org/en/about/previous-releases) — дата окончания жизненного цикла Node 20 и статус поддержки Node 22 и Node 24.
- [Синтаксис метаданных GitHub Actions](https://docs.github.com/en/actions/reference/workflows-and-actions/metadata-syntax) — объявление `runs.using` для JavaScript-actions.
- [Changelog actions/checkout](https://github.com/actions/checkout/blob/main/CHANGELOG.md) — пример first-party-проекта с релизами и обновлением документации вокруг Node 24.
- [Репозиторий actions/setup-node](https://github.com/actions/setup-node) — актуальное использование, синтаксис версий Node, рекомендации по кэшированию и требования к runner.
- [Репозиторий actions/runner](https://github.com/actions/runner) — реализация runner с открытым исходным кодом и автоматизация обновлений Node.
- [GitHub Changelog: Actions](https://github.blog/changelog/label/actions/) — связанные изменения платформы Actions и экосистемы runner’ов.