12 ноября 2026 года GitHub объявил, что к 8 декабря завершит поддержку выполнения заданий ARM32 на hosted runners под Linux и Windows. Mentoring.digital объясняет, как определить затронутые задания и не принять это объявление за остановку всей ARM-разработки.
Что именно меняется
Объявление относится к ARM32 job execution в размещённых у GitHub исполнителях. Оно также включает прекращение поддержки нативного выполнения пользовательского пространства AArch32 на hosted runners. В качестве причины GitHub указывает переход после завершения поддержки Node 20: Node 24 не поддерживает ARM32.
Это объявленный срок изменения, а не сообщение о том, что 12 ноября все такие задания уже отключены. В тексте также нет основания переносить вывод на все архитектуры ARM, любую кросс-компиляцию или любой самостоятельно размещённый runner. Способ сборки и среду исполнения нужно рассматривать отдельно.
Как найти зависимость в своём CI
Начать стоит с инвентаризации workflow: какие образы и архитектуры используются, где запускается готовый бинарный файл и какие действия требуют конкретного runtime. Одного имени выходного артефакта недостаточно, чтобы определить архитектуру фактического исполнения.
Для каждого затронутого задания полезно записать назначение и обязательный результат. Например, сборка артефакта под ARM32 и запуск тестов именно в нативной ARM32-среде требуют разных проверок при переносе. Успешная сборка на другой машине ещё не подтверждает сохранность тестового сценария.
Как подготовить перенос до срока
Редакционная рекомендация: выбрать допустимую для проекта среду, воспроизвести в ней сборку и тесты, проверить загрузку артефактов и права доступа. Не заменяйте одновременно runner, зависимости и команды тестирования без необходимости: будет сложнее установить источник расхождения.
Результат переноса нужно сравнить с текущим заданием по конкретным функциям, а старый вариант сохранять до подтверждения нужных сценариев. Разобрать архитектуру CI и ограничения исполнителей можно с наставником по DevOps. План миграции должен опираться на реальные workflow команды, а не на предположение, что любое упоминание ARM означает одинаковую проблему.
