Короткий цикл CI в 2026: всплеск сборок и новый облачный Mac — регистрация Runner, сеть и минимальные токены за 30–60 минут (чеклист и FAQ)

Когда релиз «горит», а очередь GitHub-hosted macOS растёт быстрее коммитов, команда поднимает дополнительный self-hosted Runner на только что выданном облачном Mac. Задача не «установить всё красиво», а за 30–60 минут вывести узел в продакшен-контур: регистрация агента, базовая сетевая гигиена и секреты с минимальными правами. Ниже — сжатый runbook без философии: что проверить, в каком порядке и какие вопросы всплывают чаще всего. После того как runner в сети, логично закрепить политику кэша — см. короткий цикл облачного Mac CI: удалённый кэш против локального диска; для авральных слотов отправки в магазин полезен и материал о внезапных сборках и сроках App Store.

Чеклист по минутам: 0–15 · 15–30 · 30–60

0–15 мин. Зафиксировать версию Xcode и CLT, включить автоматические обновления ОС только если политика команды это допускает; иначе отложить. Создать отдельного пользователя ОС под runner (не администратора повседневной учётки). Проверить, что часы синхронизированы (NTP) — иначе OAuth и артефакты с коротким TTL дают «магические» 401.

15–30 мин. Установить runner по официальной инструкции платформы, зарегистрировать узел в целевой группе с метками os:mac / burst:2026 (пример), ограничить одновременные job на первый день. Прогнать «пустой» workflow: checkout, echo, upload минимального артефакта.

30–60 мин. Пройти сетевой блок ниже, выдать токены по матрице прав, включить ротацию и срок жизни, записать в runbook кто отзывает runner при утечке токена. Зафиксировать в репозитории переменные окружения и пути к Keychain только для подписи — без копирования секретов в общий чат.

Регистрация Runner после выдачи узла

Сохраните конфигурацию runner'а в том же формате, что использует ваша оркестрация (systemd на Linux не применим — на macOS это launchd или интерактивный сеанс; для краткого цикла часто достаточно LaunchAgent под отдельным пользователем). Проверьте, что рабочий каталог job лежит на быстром локальном томе, а не на сетевом монтировании по умолчанию: линкер и xcodebuild штрафуют за задержку metadata.

# Версия инструментов = контракт с репозиторием
xcodebuild -version
xcode-select -p

# Git должен ходить по HTTPS или SSH так же, как в CI YAML
GIT_TRACE_PACKET=1 GIT_CURL_VERBOSE=1 git ls-remote origin

# Runner слушает только нужные исходящие, входящих от интернета не требуется
# (проверьте корпоративный egress / прокси по документации хостинга)

Сетевой самоконтроль: DNS, TLS и «ложная компиляция»

Разделите время: DNS, TCP/TLS до github.com / артефакт-хранилища, затем Git fetch, затем компиляция. Если сумма первых двух сравнима с компиляцией, команда оптимизирует флаги компилятора зря. Проверьте резолвинг внутренних зон (Artifactory, корпоративный GitHub Enterprise) и корневые сертификаты прокси: на «свежем» облачном Mac чаще ломается не Xcode, а цепочка TLS до внутреннего реестра.

Токены минимальных привилегий

Используйте отдельный fine-grained PAT или deploy key только на чтение для checkout; второй секрет — на запись в Packages/Registry, если нужен push артефактов. Срок жизни — дни, не годы; ротация при смене runner'а обязательна. Для GitHub рассмотрите OIDC к облачному хранилищу вместо долгоживущих ключей S3 — меньше поверхность при компрометации раннера. Запретите токенам доступ к нерелевантным организациям и включите аудит на выдачу секретов в репозиторий.

FAQ: короткие ответы под давлением релиза

Нужен ли входной порт? Обычно нет: агент инициирует исходящее к платформе CI. Уточните у провайдера облачного Mac, не требуется ли STUN/другой канал для управляющей плоскости.

Можно ли один runner на несколько команд? Технически да, политически дорого: смешанные секреты и метки. Лучше отдельный пул и отдельные токены на продукт.

Что первым делом при «runner offline»? Проверить смену IP, истечение регистрационного токена, спящий режим macOS и политику энергосбережения дисплея (на серверном Mac он не должен уводить сеть в сюрприз-сон).