2026: iOS CI на арендованном bare metal удалённом Mac:
self‑hosted runners, очереди и планирование кэша 1ТБ/2ТБ

Первая волна удалённого Mac CI часто ошибочно приписывает нестабильность тактовой частоте. На Apple Silicon доминирующая дисперсия обычно операционная: кэши, не переживающие job, материалы подписи, различающиеся между хостами, реестры на другом континенте и допущения о параллелизме, игнорирующие давление unified memory. Bare metal убирает конкуренцию соседей на уровне платформы, но вам всё равно нужна явная модель жизненного цикла runner, водяных знаков диска и справедливости очереди.

Переведите следующий список в пункты чек‑листа ревью, чтобы бюджет крепился к правильному измерению, а не к самому крупному SKU по умолчанию.

• Лавины кэша: параллельные runner с холодным стартом DerivedData растягивают wall time случайно, пока вы не построите hit rate по хостам.
• Дрейф подписи: связка ключниц, профилей provisioning, team ID и настроек экспортного контроля должна описываться как конечный автомат, а не как одноразовая заметка.
• Локальность артефактов: если Git, фиды пакетов и внутренние реестры расходятся по региону, фазы загрузки доминируют над компиляцией.
• Риск одного хоста с несколькими job: смешение UI‑тестов и тяжёлых волн компиляции на M4 16ГБ ухудшает хвост через память, а не через насыщение CPU.
• Отсутствие политики очереди: без меток и потолков параллелизма тяжёлые job голодают лёгкие проверки PR и ломают петлю обратной связи в минутах.
• Размытая граница эксплуатации: self‑hosted runner всё равно требует владельцев для обновлений macOS, параллельных установок Xcode, ротации логов и очистки диска.

Дополнительно командам с ночными массовыми UI нужно разводить окна, чтобы дневные лёгкие проверки не сталкивались с ночными пакетами. Метки как полосы движения и числовые потолки параллелизма переносят спор из ощущений в договорённости.

Если проверка подписи или загрузка отчётов зависит от исходящего канала, полоса тоже становится переменной хвоста. На bare metal сеть не бесконечна, поэтому DNS и пропускную способность включайте в сигналы здоровья runner.

Практическое правило: определите локальность артефактов и удержание кэша до масштабирования числа runner.

Таблица ниже не универсальный рецепт. Это язык, которым могут делиться финансы и платформа, споря о параллелизме и запасе. Команды с упором на PR выигрывают от разделения очередей и повторного использования кэша. Команды с упором на релизы выигрывают от большей памяти и спокойного параллелизма.

Когда вы переносите матрицу на CALMVPS, продуктовая история — это региональное покрытие и полная лестница конфигураций, а не один героический узел. Выбирайте регион, который одновременно снижает задержку Git и реестров, затем расширяйте ширину очереди параллельной ёмкостью, когда всплики превышают заранее записанные пороги.

На практике при смене региона пересоберите базовые профили: TLS, корпоративный прокси и внутренние зеркала — иначе вы оптимизируете CPU при неизменной сетевой геометрии.

Self‑hosted runner успешен, когда вы относитесь к повторно используемым артефактам сборки как к одноразовым, но воспроизводимым, а к секретам подписи как к строго ограниченным и аудируемым. Практичный шаблон — вынести DerivedData и пользовательские корни кэша на большой выделенный том, явно прописать пути в скриптах сборки и мониторить водяные знаки диска с той же серьёзностью, что и глубину очереди. Хвост редко загадочен, если построить процент свободного диска рядом с p95 времени сборки.

GitHub публикует концептуальную модель и обязанности для self‑hosted runner. Переоткрывайте страницу после правок upstream, потому что заголовки и ограничения меняются.

https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners

Даже при другом контроллере сохраняйте разделение: процесс runner забирает код и сообщает статус, а Xcode владеет компиляцией и тестами. Переменные окружения, момент разблокировки ключницы и потолки параллелизма живут на одной странице runbook.

В крупных модульных репозиториях индексация и кэш модулей Swift быстро растут; без политики ротации расширение диска лишь откладывает переполнение.

export RUNNER_ALLOW_RUNASROOT=0
defaults read com.apple.dt.Xcode.plist
df -h
du -sh ~/Library/Developer/Xcode/DerivedData 2>/dev/null
xcodebuild -showsdks

Инженеры онбординга должны трактовать дисковые команды как первичные сигналы. Удалённый bare metal без ясной политики очистки заполнит диск логами, тестовыми артефактами и индексацией, даже когда CPU простаивает. Для интерактивной проверки вне SSH включайте страницу доступа VNC в стандартный путь приёмки, а не только как аварийный вход.

Если пайплайн генерирует много скриншотов и видео, заранее определите срок хранения и сжатие, иначе даже 2ТБ быстро заканчиваются повторными прогонами.

Предполагается доступ администрирования по SSH и цель — долго живущий self‑hosted runner. Каждый шаг должен выдавать артефакты, которые можно приложить к записи изменения, чтобы миграции между регионами оставались скучными.

1. Заморозить базовые линии: зафиксировать версии macOS, Xcode, Swift toolchain и пакета runner как кортеж до и после.
2. Создать выделенные учётные записи: разделить личность runner и личность личной отладки и описать границы sudo.
3. Разметка диска: выделить каталоги или точки монтирования для DerivedData, вывода тестов и логов, затем закодировать очистку в cron или шагах workflow.
4. Установка и регистрация runner: следовать официальному потоку регистрации для репозитория или организации, затем прикрепить метки, отражающие намерение очереди.
5. Внедрение подписи: поддерживать таблицу, какие ключи допустимы на CI‑хостах и какие нельзя выносить с ноутбуков разработчиков.
6. Постепенная валидация: сначала компиляция и unit, затем UI, затем archive, фиксируя p95 и p99 на каждом шаге.
7. Оповещения: связать свободное место на диске, офлайн runner, завалы очереди и всплески отказов с одной дежурной поверхностью, выражая пороги расширения как SKU на странице цен.

Седьмой шаг — место, где бюджет становится закупкой: при длительном превышении порога завала расширяйте ширину очереди дополнительными узлами или короткой параллельной арендой вместо бесконечного наращивания параллелизма на одном хосте.

Согласуйте обновление runner и обновление macOS в одном поезде изменений, иначе появятся полуобновлённые состояния, которые дорого диагностировать.

• Операционное владение: документация GitHub заявляет, что организации с self‑hosted runner несут ответственность за патчи и защиту машин, поэтому обновления macOS должны идти тем же поездом, что и обновления runner.
• Семантика путей кэша: документация Apple для разработчиков объясняет DerivedData и связанные расположения достаточно подробно, чтобы якорить runbook при миграции хостов.
• Связка unified memory: Apple описывает Apple Silicon как unified memory, что в CI превращается в коррелированное давление между параллельной компиляцией и UI‑автоматизацией, если полосы не разделены.

Каноническим источником поведения на уровне Xcode остаётся документация Apple для разработчиков.

https://developer.apple.com/documentation/

Эти опоры переводят спор из субъективных жалоб на медленность в измеримые ограничения ресурсов.

Дополнительно зафиксируйте верхнюю границу одновременно открытых симуляторов и политику записи видео тестов, чтобы снизить дрейф хвоста между сменами дежурных.

Типичная экономическая форма — спокойный трафик pull request с периодическими релизными неделями, которые всплескивают ночные UI и archive. Ограничители стоимости должны сочетать ширину очереди с удержанием: короткая параллельная аренда поглощает ширину, месячная или квартальная стабилизирует хаб и горячие кэши, а выбор 1ТБ против 2ТБ отвечает на вопрос, сколько исторических версий Xcode и снимков DerivedData вы можете позволить для bisect регрессий.

FAQ: жизнеспособен ли M4 16ГБ для UI‑тестов? Да, если сместить UI‑наборы от тяжёлых волн компиляции по времени или разнести метки по хостам, потому что память доминирует над хвостом сильнее сырых гигагерц.

FAQ: почему bare metal предпочтителен для продакшен CI? Важна детерминированность атрибуции: когда отказы коррелируют с кодом, а не с соседским шумом, меньше времени уходит на споры о платформе.

FAQ: когда полезны суточная или недельная аренда? Для проверки новых версий Xcode, всплесков на предсказуемых событиях и сравнения wall time между регионами до долгосрочного контракта.

Сильно переподписанные виртуализированные пулы и домашние аплинки оба страдают от хвостовых задержек и дисциплины доступности. Для команд, которым нужна продакшен‑плоскость iOS сборки с мультирегионом, аренда облачных Mac mini на bare metal у CALMVPS обычно даёт более сильную операционную посадку: выделенный Apple Silicon, круглосуточный онлайн, эластичное помесячное заказание и короткое окно выдачи. Откройте страницу цен CALMVPS, чтобы согласовать регионы, ступени и параллельную ёмкость с уже задокументированной политикой очередей и кэша.

Для финансов полезно на одном слайде показать число runner, дни удержания на диске и долю повторных прогонов — там часто прячется скрытая стоимость.