Нові вимоги GitHub до self‑hosted раннерів

Все ще працюєте на старій версії СI? GitHub натякає, що потрібен апдейт. 

Після завершення масштабного оновлення платформи Actions компанія повертає вимоги до мінімальних версій раннерів на GitHub.com та GitHub Enterprise Cloud. Цей крок спрямований на підвищення стабільності, доступності та продуктивності. 

Нова платформа вже обробляє понад 120 мільйонів джобів (робочих етапів) щодня та підтримує значно вищі навантаження. Водночас такі зміни потребують дотримання актуальних вимог до інфраструктури.  

Тож які версії втратять сумісність з платформою та коли оновлення набудуть чинності — розбираємо в матеріалі. 

Які версії потраплять під обмеження

Оскільки всі раннери переходять на нову платформу, старіші збірки, несумісні з оновленою інфраструктурою, будуть виведені з експлуатації. 

Дві ключові вимоги для сумісності: 

• Для перереєстрації раннера: версія 2.329.0 або новіша. Інакше нова платформа його просто не побачить.
• Для виконання джобів: оновлювати раннер протягом 30 днів після кожного нового релізу. Це правило було й раніше, проте зараз його застосовуватимуть послідовніше. 

Важливе уточнення: версія 2.329.0 — це лише доступ до реєстрації та отримання апдейтів. А ось для запуску джобів планка оновлення постійно зростатиме з кожним релізом. Якщо мине 30 днів без інсталяції —  раннер просто випаде з черги. 

Як працюють оновлення 

Оновленням вважається будь-який публічний реліз — major, minor або patch. 

Якщо у вас увімкнено автооновлення і раннер має доступ до сервісу апдейтів, нові релізи встановлюються самі — правило 30‑денного вікна дотримується без ручних дій. Перевірте лише, чи політики безпеки або мережеві правила не блокують доступ до служби оновлень. 

Якщо автооновлення вимкнене, кожен новий випуск раннера потрібно встановлювати самостійно. Для ручного режиму спробуйте зафіксувати такі внутрішні правила: 

1. Додайте перевірку версії під час розгортання або заплануйте щотижневу автоматичну перевірку скриптом, який звіряє встановлену версію з останньою доступною.
2. Оновлюйте базові шаблони віртуальних машин і контейнерів, з яких створюєте ранери, щоб нові інстанси (екземпляри) не запускалися зі старими файлами програми.
3. Спершу оновіть невелику тестову групу ранерів і кілька днів поспостерігайте за роботою, якщо все стабільно — розгорніть оновлення на решту інфраструктури.

Також варто пам’ятати, що у випадку критичного оновлення безпеки постановка джобів для застарілої версії зупиняється відразу до встановлення патча — без повних 30 днів.

Які графіки оновлень GitHub Actions?

Перед повним впровадженням змін GitHub проведе короткі тестові блок-вікна, щоб команди могли побачити, де використовуються застарілі інсталяції.

У межах попереджувальних блок-вікон (з 18:00 до 22:00 за київським часом) можуть періодично вводитися обмеження:

• тимчасово буде заборонена реєстрація застарілих версій раннерів;
• згодом — обмеження можуть поширюватися і на виконання джобів на цих версіях.

Графік переходу виглядає так:

GitHub Enterprise Cloud з Data Residency:

GitHub Enterprise Cloud:

Якщо ваша компанія використовує GitHub Enterprise Cloudабо GitHub Enterprise Cloud Data Residency, власники організацій можуть відстежувати, які версії раннерів реєструються, через журнал аудиту. У таких записах фіксується кожна реєстрація, включно з конкретною версією раннера.

Підсумовуючи

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

На практикумі ITEDU з CI/CD-пайплайнів розбираємо, як будувати процеси так, щоб подібні зміни не ставали сюрпризом для команди, а вирішувались як частина зрозумілого й контрольованого робочого циклу.