CI мёртв, а GitHub этого не заметил

Если вы сопровождаете GitHub Actions или self-hosted macOS runner, в 2026 году жалобы звучат очень конкретно: длиннее queue, плавает время Xcode-сборки, один PR гоняют retry снова и снова, CI то зелёный, то красный. Статья разложена на четыре слоя — сначала инженерные симптомы, затем как агенты «зацикливают» CI, и наконец место Cloud Mac. Заголовок «CI мёртв» разберём в FAQ в конце; основной текст начинается с поломок, которые вы узнаёте сразу.

1 · Первый слой: почему GitHub Actions в 2026 «медленнее, нестабильнее, flaky»

За последние полгода от iOS-, Flutter- и macOS-команд мы слышим один и тот же паттерн — не «CI устарел как идея», а одновременный рост четырёх классов проблем ниже.

1.1 Очередь macOS runner

На hosted macos-latest время в Queued часто больше, чем сам build. В таймлайне job: 40 минут ожидания, 12 минут работы — команда всё ещё крутит флаги xcodebuild. Формула диагностики по-прежнему wait time >> run time, подробно в runbook по очереди macOS runner. В 2026 queue растёт, потому что лимит macOS concurrency не успевает за числом job в репозитории — и потому что Archive и тяжёлые задачи занимают слоты, утягивая в очередь быстрый feedback по PR.

1.2 Разброс времени Xcode build

Тот же commit, перезапуск: в CI Xcode то 18, то 31 минута, на локальном Mac стабильно ~15. Типичные факторы: cold start runner, промах DerivedData cache, повторный resolve CocoaPods, patch Xcode в образе не совпадает с локальной машиной. По отдельности это похоже на «кэш настроен криво» — но когда каждый retry — холодная среда, разброс превращается в «CI нельзя доверять».

1.3 Retry вышли из-под контроля

Помимо явного retry-on-failure в workflow, растут неявные retry: агент или бот читает логи → патч → push → снова Actions. PR из «2 push от человека» превращается в «8 push от машины»; счёт minutes и нагрузка на queue растут вместе. Кажется flaky test — на деле один PR в CI гоняют с разным кодом в нескольких раундах.

1.4 Flaky CI: то зелёный, то красный, сложно воспроизвести

Классика: sporadic timeout тестов, сбой старта симулятора, блокировка keychain при подписи. В 2026 добавился слой: каждый раунд агента даёт другой diff — трудно ответить «flaky test или агент сломал другое». Фраза, от которой больнее всего release-инженерам: «Вчера вечером CI был зелёный, сегодня утром тот же tag снова красный.»

2 · Второй слой: не «CI стал хуже», а CI стал зацикленным

Чинить queue, кэш и тесты по отдельности часто помогает на один круг. Вместе видна общая нить: CI — уже не разовая проверка, а цикл «сбой → фикс → снова гонять». До агентов цикл жил в голове инженера; теперь он в инфраструктуре — модель читает логи, выдаёт patch, автоматически триггерит workflow.

Типичная цепочка давно обыденна:

• PR открыт → CI красный (тест / сборка)
• Агент читает логи Actions → fix commit
• Push → новый workflow → снова красный → ещё fix
• Пока не зелёный — или пока человек не остановит / не кончатся tokens

Формально это GitHub Actions / CI; по факту — agent retry loop. Вы боретесь не с «одним упавшим build», а с вероятностным итогом множества попыток — отсюда симптомы слоя 1: queue забита повторными job, время Xcode дрейфует из-за cold start, flaky потому что код и среда меняются каждый раунд.

Здесь полезна чуть абстрактная, но практичная формулировка: классический CI предполагает детерминизм — тот же commit, та же среда, воспроизводимый результат. После цикла агента путь становится вероятностным — на какой попытке зелёный, сколько commit между, случайно ли сработал Archive. Это объясняет, почему «просто добавить кэш» не решает всё.

GitHub по-прежнему улучшает workflow, runner и кэш — под одиночные детерминированные job. Когда в репозитории по умолчанию крутится agent loop, это помогает, но не останавливает мультипликатор «число job × раунды retry». Поэтому в заголовке «GitHub этого не заметил»: продуктовый нарратив всё ещё CI/CD, а использование уходит в автоматический цикл починки.

3 · Третий слой: структура изменилась — от CI pipeline к retry loop + execution substrate

Симптомы (слой 1) и причина (слой 2) вместе: CI из линейного pipeline превращается в систему исполнения с обратной связью.

Старая модель: Code → Build → Test → Result — сбой останавливает линию. Новая: Code → Agent → Modify → Execute → Retry → … → Result — сбой часть цикла, не конец. Зелёная галочка в GitHub ещё успокаивает, но смысл другой — может зелёный только с 4-й попытки, с изменёнными commit между.

Новый, но инженерный термин: execution substrate (база исполнения) — агент может менять код, но компиляция, подпись и upload должны лечь на стабильную воспроизводимую macOS-площадку. Serverless job слишком короткий, state не уносится; локальный Mac засыпает и обновляет Xcode; hosted runner стоит в queue и дрейфует по spec. Cloud Mac закрывает именно этот слой: постоянно online, toolchain можно pin, среду можно снапшотить — не «удалённый рабочий стол», а слой retry loop, который должен оставаться максимально детерминированным.

Власть исполнения смещается: раньше человек писал workflow, машина выполняла; теперь человек задаёт границы (что в PR, что в Archive, сколько retry), агент пробует пути внутри границ, человек принимает итог. macOS/iOS-команды чувствуют это острее — подпись и Archive не должны бесконечно крутиться в retry loop, иначе зелёный ≠ готов к релизу.

4 · Четвёртый слой: стабилизировать execution surface через Cloud Mac (можно сразу)

Не нужно ждать новый нарратив GitHub и не нужно сносить Actions. Против зацикленного CI у клиентов VPSSpark чаще всего срабатывают четыре меры ниже — и это отличие Cloud Mac от hosted runner.

4.1 Разделение пулов: ограничить радиус retry

На PR только L0/L1 (analyze, unit tests, simulator build), Archive в PR запрещён; release, IPA и нотаризация — только в изолированных пулах на main/tag. Как бы ни крутился agent loop — 35-минутный Archive не забьёт fast pool и не поставит всю команду в Queued. Жёсткие правила в CI Hard Rules; топология двух пулов Flutter в 2 Cloud Mac: fast/archive.

4.2 Warm environment: без cold start на каждый retry

Держать PUB_CACHE, DerivedData, кэш загрузки Pods персистентно; runner autostart, online 7×24. На 2-м retry агента не должно быть 15 минут pod install — иначе разброс Xcode читают как «проект тормозит». Cloud Mac покупает стоимость удержания среды, а не только CPU-minutes за job.

4.3 macOS execution substrate: зафиксировать версии toolchain

Pin Flutter/Xcode major через образ или fvm; машина Archive и fast pool физически разделены, без общего DerivedData. Каждый раунд retry должен идти на том же Distribution-сертификате, тех же CLT — условие аудируемого iOS CI. Границы self-hosted runner: документация GitHub.

4.4 Retry isolation: потолок для loop

На уровне workflow: concurrency отменяет старые run того же PR; отдельные timeout и лимит push для agent-триггеров; машина подписи только для release pool. Синтаксис: документация workflow. Цель не запретить агентов, а держать loop в контролируемых границах.

5 · FAQ