2026: трансграничные команды — Trunk / Merge Queue и мультирегиональные физические Mac: как сгладить хвосты оркестрации и шторм блокировок? Матрицы глубины очереди, маршрутизации по меткам и порогов аффинности артефактов (готовый фрагмент GitHub Actions merge_group + FAQ)

Три матрицы решений: очередь, метки, аффинность артефактов

Матрица A: когда ужесточать Merge Queue / группы concurrency

Матрица B: маршрутизация по меткам (мультирегиональный физический Mac)

Матрица C: аффинность артефактов (с порогами)

Используйте все три вместе: глубина очереди отвечает на вопрос кто идёт первым, метки — где это выполняется, аффинность — что перемещается до запуска. Убрав один угол, получите «зелёные слияния», которые всё равно выходят медленно.

Runbook из семи шагов

1. Зафиксировать базовые линии: раздельно замерить PR-проверки, merge_group и пуши в default; следить за глубиной очереди runner и долей ретраев по регионам.
2. Задать SLA для merge_group: целевая длительность ниже бизнес-максимума «времени до слияния», с отдельной строкой про долю времени на скачивание артефактов.
3. Сжать concurrency: через concurrency или правило «один тяжёлый джоб на runner» для общих изменяемых ресурсов — сначала убрать ложные отрицательные.
4. Добавить региональные метки: привязать валидацию default branch к тому же региону, что артефакты и зеркала зависимостей; трансгранично — только ускорение чтения.
5. Откалибровать пути артефактов: крупные промежуточные данные — генерация, ссылка и проверка дайджеста в одном регионе; избегать повторных полных загрузок внутри merge_group.
6. Игровой день: осушить регион или ввести троттлинг; убедиться, что запасной сценарий очереди не нарушает юрисдикцию подписи (задокументировать RTO, если «регион-авторитет» нельзя перенести).
7. Записать пороги: глубина очереди, RTT и размер артефактов — в ADR, чтобы масштабирование не стёрло неформальные правила.

Пороги для цитирования (удобно для ADR)

• P95 ожидания в Merge Queue > ~2× длительности одной проверки merge_group → настраивать concurrency и дробить джобы до закупки железа.
• P95 RTT трансграничной загрузки артефактов > ~80–120 мс при одном скачивании > ~5 ГБ → по умолчанию выравнивать сборку и проверку по региону.
• На self-hosted физических Mac держите один тяжёлый UI-джоб на runner внутри группы concurrency, чтобы не драться за симулятор.
• Краткосрочная доля сбоев перестройки очереди > ~5% → смотреть на branch protection и дрейф, а не на больше ретраев.

Готовый фрагмент GitHub Actions merge_group

Минимальный триггер merge_group рядом с pull_request и ключ concurrency, чтобы снизить штормы блокировок на self-hosted runner. Замените метки runs-on и имена регионов на свои.

name: ci

on:
  pull_request:
  merge_group:

concurrency:
  group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
  cancel-in-progress: true

jobs:
  validate:
    if: github.event_name == 'merge_group' || github.event_name == 'pull_request'
    runs-on: [self-hosted, macOS, region-apac]
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.merge_group.head_sha || github.event.pull_request.head.sha }}
      - name: Build and test (merge queue aware)
        run: |
          echo "Running on ${{ github.event_name }} @ ${{ github.sha }}"
          # xcodebuild / swift test / your merge validation commands

Замечания: merge_group должен checkout тот же ref, что и временный merge-коммит очереди; подберите ключ concurrency так, чтобы PR и merge-queue не отменяли чужую работу (при необходимости разделите workflow). Семантика merge_group у GitHub развивается — проверьте сквозной сценарий в тестовом репозитории до продакшена.

FAQ

Можно ли merge_group и pull_request держать в одном определении job?

Да для шагов, но явно обрабатывайте if и ref — при перестройке очереди неверные SHA дают «случайный красный».

Смешивать пулы физических Mac с GitHub-hosted runner?

Можно, но метки должны быть взаимоисключающими и задокументированными; унифицируйте контракты путей артефактов и кэша, чтобы одна группа concurrency не охватывала классы runner с разной файловой раскладкой.

Шторм блокировок: сначала осушать очередь или убивать джобы?

Сначала снижайте параллелизм и зерно блокировок; осушение очереди ломает намеренный порядок слияний и обычно оставляют для инцидентов control plane.

Стабильная очередь на Mac mini

Trunk и Merge Queue переносят корректность слияний в CI, а физические Mac runner несут реальную нагрузку Xcode и симулятора — вместе важнее стабильность и предсказуемость I/O, чем пиковые ГГц. Apple Silicon Mac mini сочетает высокую пропускную способность памяти с примерно ~4 Вт в простое, поэтому региональные runner могут оставаться тёплыми ночью без термопрогонов, из-за которых на многих башнях x86 приходится постоянно перенастраивать TTL блокировок.

macOS даёт те же корни, что и на ноутбуках команды, сужая разрыв «локально проходит, в CI флакает»; Gatekeeper, SIP и FileVault упрощают объяснение состояния сессии и диска при аудите по сравнению с типичной Windows-фермой. Совместите runner с артефактами и зеркалами, затем закрепите границы блокировок метками и concurrency — если нужна проверка merge_group на тихом, эффективном и предсказуемом железе, Mac mini M4 по-прежнему один из сильнейших стартов по цене и производительности.

Если вы готовы перейти от «merge_group иногда отрабатывает» к «доверяю порогам глубины очереди и аффинности», оформите Mac mini сейчас и прогоните эту матрицу на реальном кремнии вместо борьбы только с квотами облака.