GitHub Actions міняє runner images у червні: як перевірити CI до поломки

Зачіпка

GitHub Actions у червні 2026 року міняє частину стандартних hosted runner labels. Якщо ваш CI роками живе на windows-latest або macos-latest, це той випадок, коли краще витратити 30 хвилин зараз, ніж ловити червоний release pipeline вранці перед дедлайном.

14 травня GitHub анонсував дві практичні міграції. windows-latest і windows-2025 поступово перейдуть на Windows Server 2025 with Visual Studio 2026 з 8 до 15 червня. macos-latest з 15 червня почне переходити з macOS 15 на macOS 26 протягом 30 днів.

Проблема / Контекст

GitHub-hosted runners зручні саме тим, що GitHub сам підтримує віртуальні машини, оновлює інструменти й дає готові середовища для Linux, Windows і macOS. У workflow це виглядає просто:

jobs:
  build:
    runs-on: windows-latest

Проблема в слові latest. Воно звучить як “просто дай нормальну актуальну платформу”, але фактично це рухома ціль. Сьогодні label веде на один runner image, після rollout - на інший. Для простого lint job це може нічого не змінити. Для build job із Visual Studio, CMake, Android Command Line Tools, Xcode, code signing або нативними залежностями це вже не дрібниця.

У Windows-частині GitHub переводить windows-latest і windows-2025 на image з Visual Studio 2026. В офіційному оголошенні окремо згадані зміни Visual Studio components, CMake і Android Command Line Tools. Для macOS macos-latest почне вказувати на macOS 26 замість macOS 15. Якщо ваші тести або збірки чутливі до Xcode, SDK, notarization, simulator behavior або native dependencies, варто перевірити це до масової міграції.

Чому це важливо

CI ламається неприємно не через сам факт оновлення. Він ламається через приховану залежність: у workflow не написано “мені потрібна Visual Studio 2022”, але build script поводиться так, ніби вона там завжди буде. Або в YAML стоїть macos-latest, але signing step реально прив’язаний до toolchain з macOS 15.

Такі проблеми часто виглядають як випадковий збій:

• компілятор раптом не знаходить компонент;
• CMake вибирає інший generator;
• browser або mobile tests починають падати на setup;
• .NET або C++ build тягне інший SDK;
• code signing проходить локально, але падає у CI;
• job зелений в одному run і червоний в іншому під час поступового rollout.

Найгірший сценарій - команда бачить поломку вже після того, як label почав мігрувати. Тоді доводиться одночасно розбиратися з release pressure, логами GitHub Actions і незнайомим runner image. Краще зробити маленьку контрольовану міграцію самостійно.

Ілюстрація: де саме ризик

Уявіть runs-on як вибір робочого столу для job. На столі вже лежать компілятори, SDK, package managers і системні бібліотеки. Коли GitHub міняє runner image, стіл ніби той самий за назвою, але частина інструментів на ньому інша.

Тому аудит треба робити не по всіх workflow однаково, а по чутливості. npm test на Ubuntu може бути низьким ризиком. Windows installer build, iOS build, Electron packaging, Playwright на системних браузерах або C++ з CMake - значно вищий ризик.

Як це зробити

1. Знайдіть усі залежні workflow

Почніть із простого пошуку по репозиторію:

rg -n "runs-on:.*(windows-latest|windows-2025|macos-latest)" .github/workflows

Якщо у вас багато репозиторіїв, проганяйте це на рівні організації або хоча б по active services. Важливо знайти не тільки production deploy workflow, а й scheduled builds, release jobs, mobile packaging і manual workflow dispatch.

Після пошуку зробіть короткий список:

• файл workflow;
• job name;
• поточний runs-on;
• що job робить;
• що буде боліти, якщо job впаде.

2. Розділіть jobs за ризиком

Не кожен job треба мігрувати вручну в перший день. Низький ризик - це прості linters, unit tests без системних залежностей і jobs, де всі runtime версії явно ставляться через actions на кшталт actions/setup-node.

Середній ризик - browser tests, packaging, jobs із кешами, Docker build на Windows або macOS, складні setup scripts.

Високий ризик - .NET desktop, C++/CMake, Visual Studio workloads, Android build на Windows, iOS/macOS signing, Xcode-sensitive steps, native modules і будь-який release job, який блокує доставку користувачам.

3. Протестуйте Windows до rollout

GitHub дає тестовий label windows-2025-vs2026. Його сенс простий: ви можете прогнати job на новому image до того, як windows-latest або windows-2025 почнуть вказувати туди за замовчуванням.

Для перевірки не обов’язково одразу міняти основний workflow. Можна додати тимчасовий manual job або matrix:

name: runner-image-check

on:
  workflow_dispatch:

jobs:
  windows-build:
    strategy:
      fail-fast: false
      matrix:
        runner: [windows-2025, windows-2025-vs2026]
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - name: Build
        run: ./build.ps1

Порівняйте логи, тривалість, версії інструментів і помилки. Якщо job падає тільки на windows-2025-vs2026, це не “потім розберемося”. Це майбутній incident, який просто прийшов раніше у контрольованому режимі.

4. Протестуйте macOS 26 окремо

Для macOS логіка така сама. macos-latest почне переходити на macOS 26 з 15 червня, але macOS 26 images вже доступні окремими labels. Для Apple Silicon сценаріїв використовуйте macos-26, для Intel - macos-26-intel або відповідні larger runner labels, якщо вони потрібні вашому плану.

Типовий manual test:

jobs:
  macos-build:
    strategy:
      fail-fast: false
      matrix:
        runner: [macos-15, macos-26]
    runs-on: ${{ matrix.runner }}
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/ci-macos.sh

Особливо уважно дивіться на Xcode selection, SDK path, simulator boot, certificates, notarization, Homebrew packages і native dependencies. Якщо ваш workflow сам ставить потрібний Xcode або явно перевіряє версії, ризик нижчий. Якщо він просто сподівається на default image, ризик вищий.

5. Вирішіть: pinning чи міграція

Є два нормальні рішення.

Перше - мігрувати одразу. Якщо job проходить на новому image, змініть label свідомо або залиште latest, але зафіксуйте у release notes, що перевірка пройдена. Це хороший варіант для команд, які хочуть триматися ближче до актуального hosted runner stack.

Друге - тимчасовий pinning. Якщо job критичний і ще не готовий, GitHub прямо радить використовувати windows-2022 для тих, кому потрібна Visual Studio 2022, або macos-15, якщо треба лишитися на macOS 15. Це не соромно. Соромно тільки залишити pin без власника і дати йому застаріти.

У коментарі до YAML або в issue запишіть:

• чому зроблено pinning;
• хто власник;
• коли повертаємося до міграції;
• яка помилка блокує перехід.

6. Перевірте перші runs після зміни

Після merge не обмежуйтеся зеленим статусом одного run. Перевірте кілька типів запуску: pull request, push у main, release tag, scheduled workflow і manual dispatch. Саме тут часто вилізають різні environment variables, secrets, cache keys або artifact paths.

Також відкрийте Set up job у GitHub Actions logs і подивіться Runner Image section. Там видно, який image реально використався і яке Included Software отримав job. Це кращий факт, ніж припущення по label.

Антипатерни

• залишати windows-latest або macos-latest у critical release jobs без власника;
• робити pinning усюди автоматично, навіть там, де новий image уже працює;
• тестувати тільки один happy path і забути release або scheduled workflows;
• ігнорувати Windows jobs, бо “у нас frontend”;
• переносити проблему в коментар TODO без issue, дедлайну й власника;
• вважати зелений unit test доказом, що signing, packaging і deploy теж безпечні;
• не читати Runner Image section у логах і гадати, на чому job реально біг.

Висновок / План дій

Червнева міграція GitHub Actions не має бути драмою. Вона стає проблемою тільки тоді, коли команда не знає, які workflow залежать від рухомих -latest labels.

Практичний план на сьогодні:

1. знайдіть усі windows-latest, windows-2025 і macos-latest;
2. розділіть jobs за ризиком;
3. прогоніть Windows high-risk jobs на windows-2025-vs2026;
4. прогоніть macOS high-risk jobs на macos-26 або macos-26-intel;
5. тимчасово pin-ніть тільки ті jobs, які реально не готові;
6. після merge перевірте Runner Image section у перших CI logs.

Якщо у вас зараз немає часу на повну міграцію, мінімум безпеки такий: знайти critical release jobs і вирішити для них окремо. Усе інше можна доробити поступово, але release pipeline не має дізнаватися про Visual Studio 2026 першим.

Офіційні джерела:

• https://github.blog/changelog/2026-05-14-github-actions-upcoming-image-migrations/
• https://docs.github.com/en/actions/concepts/runners/github-hosted-runners
• https://github.com/actions/runner-images
• https://github.com/actions/runner-images/issues/14017
• https://github.com/actions/runner-images/issues/13739