Переход на Ubuntu 26.04 в GitHub Actions: проверка различий раннеров на одном коммите
Исходный код не менялся, однако результаты CI могут измениться. Если ваши рабочие процессы используют ubuntu-latest, переход на новый образ операционной системы должен стать изменением, которым управляет команда.
17 сентября 2026 года GitHub объявил об официальной поддержке раннеров Ubuntu 26.04 и плане перехода для ubuntu-latest. Эта статья — не просто рассказ о том, что новый образ непременно быстрее, а практическое предложение: изолировать и проверить различия сред на одном и том же коммите.
Что подтверждено в официальном анонсе
Согласно анонсу, образы Ubuntu 26.04 официально поддерживаются на архитектурах x64 и arm64 с явными метками ubuntu-26.04 и ubuntu-26.04-arm. Метка ubuntu-latest будет постепенно переведена с Ubuntu 24.04 на 26.04 в период с 19 октября по 19 ноября 2026 года.
В новом образе обновлены или удалены некоторые инструменты, поэтому сборки, зависящие от предустановленных пакетов, могут столкнуться со сбоями. Если подготовка еще не завершена, GitHub рекомендует явно указать ubuntu-24.04. Этот график не означает фактическую дату переключения для каждого отдельного репозитория.
Фиксация требований репозитория к окружению
Сначала проверьте параметр runs-on в основных и переиспользуемых рабочих процессах. Не стоит полагать, что запуск в контейнере полностью исключает влияние хоста: важно проверить также шаги установки, архивации и выгрузки артефактов, выполняемые вне контейнера.
Составьте чек-лист, разделив компиляторы, среды выполнения, пакетные менеджеры и системные библиотеки. Вместо простого перечисления названий инструментов свяжите их с источником установки и шагами, которые их вызывают: это поможет быстрее локализовать причину в логах сбоя.
Один коммит, две среды, независимые артефакты
Тестирование перехода безопаснее начинать в тестовых ветках без прав на развертывание. Запустите один и тот же коммит и файл блокировок на старом и новом образах, сохранив отдельно логи, результаты тестов и имена артефактов. Именно такой подход к проверке предлагается в этой статье.
При первоначальном сравнении зафиксируйте условия кэширования, чтобы отделить влияние устаревшего кэша. Помимо факта успешной сборки, необходимо сохранить версии установленных инструментов, упавшие шаги и результаты запуска артефактов — это позволит отличить реальную стабильность от случайного успеха из-за попадания в кэш.
Проверка после зеленых галочек
В веб-проектах можно убедиться, что созданные файлы действительно отдаются сервером, а при наличии нативных зависимостей — что они успешно загружаются в целевой среде. Вместо правила о побайтовой идентичности всех артефактов разделяйте недетерминированные различия (например, временные метки) и функциональные расхождения.
Ревьюер должен видеть в одном месте ссылки на запуски в новом образе, различия версий инструментов, результаты проверки ключевой функциональности и планируемые изменения для отката. Совмещение смены раннера с рефакторингом приложения неоправданно расширяет область поиска ошибок и масштаб отката.
Преимущества и ограничения фиксации образа
Явное указание метки операционной системы помогает контролировать масштабные обновления, но не гарантирует абсолютную неизменность среды сборки. Сохраняйте привычку явно устанавливать необходимые для сборки инструменты и фиксировать их фактические версии в логах.
Для небольших репозиториев нет необходимости выстраивать громоздкую систему проверки. Можно начать со сравнения одной репрезентативной сборки и наиболее чувствительных зависимостей, а в случае временной фиксации версии образа — назначить ответственного и дату повторного пересмотра.
Разделение публичных обсуждений и решений команды
Открытые issue в runner-images — это источник информации об изменениях в образах и сообщений о проблемах. Однако конкретные комментарии или сбои в других проектах не означают, что они воспроизведутся в вашем репозитории; эта статья не делает количественных заявлений о консенсусе сообщества или частоте инцидентов.
Задача на сегодня — найти места использования метки latest и протестировать тот же коммит на новом образе. Если заранее зафиксировать критерии прохождения и причины для паузы, при изменении сборки во время фактического перехода ответственный сможет принимать решения на основе объективных данных.