В 2026 году типичный запрос от платформенной команды звучит так: одна дорогая нода на bare metal Apple Silicon должна обслуживать и репозитории в GitLab, и десятки репозиториев в GitHub, при этом без «случайного» пересечения секретов и без взаимного вытеснения по диску. Технически GitLab Runner и GitHub Actions self-hosted runner — это отдельные процессы, но они делят CPU, RAM, Keychain, I/O NVMe и часто один каталог инструментов Xcode. Без квот параллелизма, без тегов и labels и без явной модели NVMe-кэша вы получите один хрупкий хост с двойным штормом вебхуков, а не «два независимых пула». Ниже — приземлённый FAQ: согласование с ИБ, разведение кэшей и критерии, когда выгоднее вторая нода. Для нескольких runner-процессов на одном Mac полезно свериться с материалом
2026 OpenClaw: пошаговое развёртывание и интеграция с автоматизацией — офлайн‑устойчивость кроссплатформенных агентов, права выполнения и совместная работа нескольких runner в GitHub Actions, а по диску и параллельным xcodebuild — с
2026: параллельные сборки Mac из нескольких репозиториев — фиксированные пути DerivedData, ключи кэша SwiftPM и пиковая нагрузка диска при параллельном xcodebuild: как выбрать стратегию очистки? Сравнительный FAQ корпоративного пула ресурсов.
1. Cohost на одном хосте: что реально делят процессы
Оба раннера выполняют job под отдельными учётными записями или сервисами, но ядро ОС одно: конкуренция за планировщик, за пропускную способность NVMe и за пики памяти симулятора остаётся общей. Практичная договорённость — описать бюджет одновременных тяжёлых job на весь хост (например, не более одного полного xcodebuild archive плюс два лёгких линтера), а уже внутри него распределить слоты между GitLab и GitHub. Отдельно зафиксируйте, кто владеет обновлением Xcode и переключением xcode-select: два оркестратора на одной машине легко превращают «обновили ночью» в серию красных сборок, если нет единого окна обслуживания и снапшота образа.
2. Квоты параллелизма: GitLab Runner и GitHub Actions на одной шкале
На стороне GitLab квота задаётся через concurrent в конфигурации runner и лимиты executor; на стороне GitHub — через параметры службы runner и concurrency в workflow, чтобы один репозиторий не открыл десять матриц на ту же ноду. Ключевая идея — один глобальный лимит тяжёлых слотов на хост, а не «у GitLab три, у GitHub пять» по отдельности: сумма активных тяжёлых job не должна превышать память и диск. Для частых PR добавьте полосу для релизных веток, чтобы они не конкурировали с экспериментами в пик.
3. Маршрутизация: теги GitLab и labels GitHub
Чтобы cohost не превратился в случайный пул, закрепите симметричную таксономию: например, теги mac-heavy / mac-light в GitLab и те же смыслы через runs-on: [self-hosted, mac-heavy] в GitHub. Это снижает риск, когда «тяжёлый» job GitHub попадёт на ту же ноду, что уже занята долгим job GitLab без меток. Дополнительно полезно развести версии Xcode по разным меткам и держать на хосте один поддерживаемый мажор, если политика безопасности не требует иного: два мажора на одном cohost почти всегда дороже по диску и по сопровождению, чем вторая физическая машина.
4. Изоляция секретов: учётные записи, Keychain и переменные
Минимально жизнеспособная модель — разные macOS-пользователи или разные связки служба+Keychain для GitLab и GitHub, чтобы токены и сертификаты подписи не делили один keychain по умолчанию. В пайплайнах держите разные префиксы путей для checkout и кэшей, а секреты — через механизмы платформы (masked variables, protected branches/environments), а не через общий .env в домашнем каталоге. Схема «один пользователь на всё» экономит час настройки и добавляет недели расследований утечек.
5. NVMe: общий быстрый том против раздельных разделов — сравнение для cohost
Три распространённых подхода показаны ниже как компромисс между стоимостью диска и безопасностью кэша. Реальные цифры зависят от размера репозиториев и политики эвикции; таблица задаёт язык для согласования с ИБ и владельцами платформы.
| Схема NVMe | Плюсы для GitLab+GitHub на одном Mac | Минусы и типичный риск |
|---|---|---|
| Один APFS-том, разные префиксы каталогов | Проще провижининг; проще мониторить заполнение | Ошибка очистки или гонка эвикции бьёт сразу по обоим CI |
| Два логических тома (GitLab / GitHub) | Чёткая граница квот; проще объяснить аудиторам владение данными | Нужно заранее нарезать ёмкость; дисбаланс при смещении нагрузки |
| Общий read-only «золотой» слой + короткие RW-аренды per job | Меньше дублирования кэшей зависимостей между системами | Сложнее внедрение; требует дисциплины lease TTL и наблюдаемости |
На практике cohost чаще всего начинают с двух префиксов на одном томе, а к раздельным томам переходят после первого инцидента с порчей кэша или когда ИБ требует физического разделения следов сборки.
6. Короткий чеклист перед включением cohost в прод
Согласуйте пункты с владельцами GitLab и GitHub, иначе «ускорение» превратится в общий простой.
- Есть ли единый глобальный лимит тяжёлых job на хост, а не только локальные лимиты каждого раннера?
- Совпадают ли теги и labels по смыслу и кто администрирует их жизненный цикл?
- Описана ли модель Keychain и пользователей так, что секреты GitLab не видны процессам GitHub и наоборот?
- Выбрана ли схема NVMe с ясными правилами эвикции и владельцем очистки?
- Запланировано ли окно для обновления Xcode без гонок двух оркестраторов?
Почему выделенный Mac mini на macOS уместен для такого cohost
Когда два оркестратора делят одну машину, выигрывает не «ещё пара ядер в облаке общего назначения», а предсказуемый macOS на Apple Silicon без соседей-арендаторов на гипервизоре: стабильные пути к Xcode, нативные инструменты цепочки подписи и привычные механизмы Gatekeeper, SIP и FileVault для политики ИБ. Mac mini M4 сочетает высокую пропускную способность памяти с низким энергопотреблением в простое (порядка нескольких ватт), что делает разумным держать постоянно включённую build-ноду с двумя раннерами и жёсткими квотами. В связке с раздельными префиксами на NVMe и дисциплиной секретов это обычно дешевле по совокупной стоимости владения, чем бесконечно бороться с нестабильными профилями виртуальных macOS.
Если вы проектируете корпоративный пул, где GitLab и GitHub делят одну высокопроизводительную ноду, Mac mini M4 — практичная стартовая точка: сначала метрики очереди и диска, затем решение о второй физической машине вместо бесконечного наращивания параллелизма на одном хосте. Чтобы сравнить конфигурации выделенного железа и регионы размещения, откройте главную страницу Macstripe и подберите вариант под реальные пики обоих CI, которые уже видит ваш мониторинг.
