GitHub Actions: як перевірити власні сервери CI до блокування реєстрації на 2.329.0

Ситуація: runner, який “ще вчора працював”, сьогодні вже схожий на майбутній інцидент

У інженера платформи або DevOps-команди є звичка дивитися на власні runner-и GitHub Actions як на фон: вони просто мають бути зеленими, а все інше нехай живе в іншому тикеті. Саме тому нове правило GitHub болить не гучно, а тихо: в один момент старий runner ще запускає задачу CI, а новий уже не реєструється.

Це не косметичне оновлення. Якщо ваш парк runner-ів живе на VM-шаблонах, ручних скриптах встановлення або контейнерних образах, дрейф версій може сидіти в різних місцях одночасно. Один runner оновився сам, другий давно заморожений, третій запускається з образу, який ще не бачив 2.329.0. На папері все виглядає нормально. На практиці це вже майбутній збій, тільки без сирен.

Що саме змінив GitHub

GitHub повідомив про примусову мінімальну версію 12 червня 2026 року. Для власних runner-ів на github.com і GitHub Enterprise Cloud реєстрація вимагатиме версію 2.329.0 або новішу, а далі діє ще й правило 30 днів: runner має вчасно підхоплювати нові релізи, інакше почне втрачати право виконувати задачі GitHub Actions.

Для оператора парку runner-ів це означає дві різні перевірки:

1. чи зможе новий runner узагалі зареєструватися на чистій машині;
2. чи не відвалиться вже наявний runner через затримане оновлення.

Тобто якщо ви бачите одну успішну реєстрацію сьогодні, це ще не доказ, що через місяць усе буде так само. Саме тут легко помилитися команді, яка дивиться тільки на статус задач, а не на версію виконуваного файлу runner-а.

Де шукати версію, перш ніж вона перетвориться на інцидент

Починайте не з паніки, а з інвентаризації. Інженер платформи має швидко відповісти на три питання: скільки у вас runner-ів, на яких хостах вони живуть і звідки береться їхній виконуваний файл.

Практично це означає:

• перевірити список активних runner-ів у GitHub і зіставити його з власним реєстром машин;
• витягнути версії через audit log або REST API, а не покладатися лише на UI;
• окремо відзначити тимчасові runner-и, довгоживучі VM і контейнери, бо в них різні точки оновлення;
• знайти образи та скрипти встановлення, які клонуються новими хостами без додаткової перевірки.

Якщо у вас є окремий канал релізів для інфраструктури, не чекайте, поки всі власники репозиторіїв побачать помилку. Зробіть інвентаризацію якомога ближчою до живого стану парку: сьогоднішній список важливіший за ідеальну схему у wiki.

Де зазвичай ховається дрейф версій

Найчастіше проблема не в одному “старому сервері”. Вона розмазана по ланцюжку доставки:

• базовий образ збирали ще до оголошення про нове правило;
• скрипт встановлення оновили частково, але не в усіх середовищах;
• автооновлення вимкнули “тимчасово”, а потім забули;
• контейнерний шаблон вказує на старий базовий образ;
• разовий runner для конкретного проєкту ніхто не додав до списку перевірок.

Окрема пастка - думати, що один зелений runner означає здоровий парк. Насправді це лише означає, що принаймні один хост ще не зламався. Якщо до вас приходить власник репозиторію з фразою “у мене задача не стартує”, це вже пізно для пошуку джерела версії. Краще знайти його до цього і зв’язати з конкретним шаблоном розгортання.

Практичний план на один робочий день

Щоб не розмазувати ризик на тиждень, спробуйте такий порядок:

1. Зібрати інвентар активних runner-ів і позначити всі хости, де виконуваний файл може бути старішим за 2.329.0.
2. Перевірити, чи автооновлення справді працює там, де ви на нього покладаєтесь.
3. Оновити базовий образ, скрипти встановлення і шаблони розгортання, які створюють нові runner-и.
4. Прогнати тестову реєстрацію на чистому хості й переконатися, що нова машина реєструється без ручного втручання.
5. Повідомити власників репозиторіїв про вікно змін і про те, як ескалювати неробочий runner.

Якщо у вас багато сегментів інфраструктури, оновлюйте їх хвилями. Спочатку оновіть те, що створює нові runner-и, потім те, що живе довше за 30 днів, і лише далі - все, що використовують рідкісні команди. Так ви не опинитеся в ситуації, коли нові хости вже правильні, а старі ще тихо випадають з роботи.

Що казати команді, яка не читає опис релізу

Найкоротше пояснення таке: “GitHub підняв мінімальну версію, і тепер старі власні runner-и можуть перестати реєструватися або виконувати задачі. Нам треба перевірити парк до дати примусового правила, а не після першої помилки.”

Цього достатньо, щоб перевести розмову з абстрактного “треба оновити” в конкретний “ось список хостів, ось дата, ось власник”. Для інциденту це вже різні рівні зрілості.