Цели общего пула и риски
Цели: быстрые PR, воспроизводимые релизы, справедливый доступ к удалённым Mac. Три боли: конкуренция за CPU, RAM, диск и Simulator; конфликты ключей и профилей на общей учётке; непрозрачная очередь — job ждут runner, а узкое место в метках, lock или обслуживании.
Self-hosted runner — точка планирования, не полная изоляция: метки и конкурентность решают перегруз и голодание релизов. Назначьте владельца пинов Xcode, обновлений runner и drain, если VNC и CI делят хост.
Чеклист: когда разделять очереди
- Разделять, если двум продуктовым линиям нужны разные Xcode или базовые версии macOS — отдельные runner и маршрутизация меток, чтобы workflow не попали на чужой toolchain.
- Разделять, если интерактивные VNC-сессии и тяжёлый CI регулярно пересекаются: выделите узел под CI или окна по расписанию.
- Разделять, если релизным архивам нужна гарантированная ёмкость: маршрут
releaseна метки с runner без «шума» от PR. - Оставлять одну очередь на ранней стадии при одном Xcode и низком параллелизме; вводите структуру после повторяющихся конфликтов или срывов SLO.
Матрица сравнения маршрутизации по меткам
Маршрутизация меток выбирает self-hosted runner для job. Слабые имена дают ошибки маршрутизации и простой железа. Метки — стабильные, машиночитаемые, без личных имён в prod-workflow.
| Паттерн | Когда уместен | Компромиссы |
|---|---|---|
Широкий пул (macos, arm64) |
Однородный парк, один пин Xcode, максимум утилизации. | Любой workflow может занять любой runner; сложнее резервировать ёмкость под релизы. |
Привязка к toolchain (xcode-16-2, swift-6) |
Репозитории с фиксированным компилятором или поведением SDK. | Больше runner на обслуживание; метки должны следовать календарю обновлений. |
Уровни SLA (ci-pr, ci-release) |
Раздельные пулы для проверок PR и отгрузочных сборок. | Нужно достаточно железа за каждым уровнем; пустой уровень стопорит очередь. |
Срез команды / репо (team-mobile) |
Разделение затрат или жёсткое ограничение blast radius. | Ниже утилизация при недогрузе срезов; выше операционные затраты. |
Соглашение об именах меток (рекомендация)
- Минимальный набор:
os+arch+xcode-<major.minor>, напримерmacos,arm64,xcode-16-2. - Опциональные суффиксы роли:
ci-pr,ci-release,experimental— не переиспользуйте роль под другой Xcode без окна миграции. - Сохраняйте стандартные метки GitHub (
self-hosted) и документируйте канонический список во внутренней wiki и в README репозитория.
Очередь и стратегия блокировок
Параллельная очередь на Mac — семантика GitHub, ядра, SSD, Simulator и mutex подписи. Стартуйте консервативно; расширяйте параллелизм по метрикам. FIFO и квоты — в FAQ по общему пулу Mac.
| Политика | Стартовый порог | Заметки |
|---|---|---|
| Лимит конкурентности (тяжёлая компиляция / архив) | Одна активная job на класс Mac | Второй узел раньше, чем постоянный параллельный архив на одной машине. |
| Лимит (лёгкие проверки) | До 2 job при CPU ниже ~75% устойчиво и свободной RAM > ~8 ГБ | Дополните группами concurrency: для отмены устаревших PR. |
| Глубина очереди пула | Сигнализировать примерно после ~20 ожидающих job на пул | Снижает многочасовые «тихие» завалы; лучше алерт, чем незаметная очередь. |
| Mutex подписи / нотаризации | Одна последовательность на связку keychain | Файловый lock, Redis или одобренный организацией action для нереентерабельных шагов. |
Минимум из пяти шагов внедрения
- Зафиксируйте канонические метки и таблицу соответствия «репозиторий → набор меток».
- Задайте
concurrencyна уровне workflow или среды, чтобы старые коммиты не забивали пул. - Ограничьте одновременные тяжёлые job на хосте; измеряйте p95 времени ожидания от создания до старта.
- Введите явный mutex для шагов с ключами и нотаризацией; логируйте владельца lock.
- Документируйте процедуру drain: как снять runner с линии без обрыва текущей job.
Права и изоляция
Общий хост ломается при размытых правах: открытые артефакты, пропажа профилей после уборки, общий login keychain. Нужны отдельные пользователи CI, домашние каталоги, automation keychain и документированное владение общими папками (ACL/setgid).
Пороги очистки диска: очищайте DerivedData или тяжёлые кэши сборки, когда свободно менее примерно 15–20% на томе CI или проектные кэши выходят за 30–80 ГБ (подстройте под SSD). Не трогайте ~/Library/Keychains и артефакты подписи; избегайте неограниченного rm -rf. Подробнее — FAQ по SSH/VNC и общей сборке и гайд по изоляции прав.
Мониторинг и алерты
Четыре сигнала: пульс runner, ожидание создание→старт, CPU/RAM/диск, ошибки ключей и сертификатов. Алерт при ожидании PR вне SLO (часто 10–20 минут) или диске ниже порога очистки.
«Флаки» сопоставляйте с SSH и окнами работ. Задержки и SLA — FAQ по стабильности, чеклист переподключения.
FAQ
- Заменяют ли метки полноценную систему очередей?
- Нет: метки фильтруют runner. Если нужны приоритеты между репозиториями и сроки, сочетайте
concurrencyс внешним координатором или разнесите удалённые Mac по пулам. - Сколько runner на одной машине?
- Для тяжёлых iOS/macOS сборок часто один сервис runner на Mac. Несколько процессов без жёстких лимитов умножают конкуренцию за диск и Simulator.
- Первый признак, что нужны несколько узлов или командный тариф?
- Регулярные срывы SLO очереди, систематические конфликты на шагах подписи или обслуживание одного хоста, которое блокирует все репозитории сразу — это структурная проблема, а не «подкрутка меток».
Цифры и правила, которые можно сослать в runbook
- Конкурентность: старт с одной тяжёлой job на Mac-класс; до двух лёгких при устойчивой загрузке CPU < ~75% и RAM > ~8 ГБ свободно.
- Очередь: алерт при глубине порядка 20+ ожидающих job на пул.
- Диск: чистка кэшей при свободном месте < 15–20% или проектных кэшах > 30–80 ГБ (настройте под носитель).
Масштабируйте командный CI несколькими удалёнными Mac
Когда одного хоста недостаточно для маршрутизации меток и параллельных очередей, добавьте узлы: разделите пулы PR и релиза, закрепите Xcode за машинами, снизьте конфликты. Тарифы мультиузловых и командных планов — на главной; оформление — на странице покупки; доступ по SSH и VNC — в справочном центре. Дополнительно: руководство SSH vs VNC, балансировка и отказоустойчивость, runner против арендованного Mac и остальные статьи блога.