CI pipeline speed — до/после AD-570 + вклад раннера buildbox

Тикет: AD-596 · Период данных: 2026-07-15 … 2026-07-18
Источник: GitLab pipelines API проекта 81171473 (agadron/aero-forge), ветка develop и MR-пайплайны.
Выборка: 258 develop-пайплайнов + 315 MR-пайплайнов; per-job тайминги и раннеры из /pipelines/{id}/jobs.

Числа — из реальных пайплайнов (медианы, не оценки). Метрики: duration джобы = чистое время
выполнения; queued_duration = ожидание раннера; wall-clock пайплайна = finished_at − created_at.

0. Точки отсчёта (мержи в develop)

Фазы анализа: A — до AD-570 (baseline); B — только AD-570 (до registry-нагрузки на build-images);
C — после registry (AD-526); D — steady-state после JS-тестов (AD-624).

1. Итог одной строкой

• AD-570 сделал ровно то, на что был нацелен: build 84.5 → 6.3 с (×13), test 142 → 48–52 с (×2.7–3.7)
  за счёт ci-base (предустановленные зависимости, pip install больше не гоняется) + compileall + pytest-xdist.
• MR-пайплайн ускорился втрое: медиана wall-clock 243 → 72 с (−70 %).
• Но стенка develop-пайплайна упала слабее, чем джобы: узкое место сместилось с test на
  build-images + scan, которые крутятся на единственном shell-раннере nas и в DAG стоят на
  критическом пути. build-images вдобавок вырос 81 → 187 с из-за пуша в registry (AD-526).
• buildbox дал реальную кросс-пайплайновую параллельность для build/test (86 одновременных запусков
  на двух docker-раннерах; очередь build/test в ночной серии ≈1–2 с). Но build/test больше не на
  критическом пути, поэтому на end-to-end время buildbox влияет ограниченно.
• Ночной затык — не resource_group deploy (ожидание ~2 с), а один shell-раннер: он последовательно
  прогоняет build-images→scan→deploy→healthcheck, и следующий пайплайн ждёт на первой же джобе
  (ci-base-tag). В ночь 15 из 44 пайплайнов ждали раннер >60 с (макс 9.6 мин), суммарно 67 мин очереди.

2. Develop: стенка пайплайна (wall-clock, только успешные с деплоем)

Максимум лучшего результата дал момент B (сразу после AD-570, до того как build-images потяжелел от
пуша в registry). Далее часть выигрыша «съели» registry-push в build-images (AD-526) и JS-тесты в test (AD-624).

3. Разбивка по джобам (develop, медиана duration, с)

Критический путь после AD-570 (DAG-needs)

ci-base-tag(4.5) → build(6.3) → ┬ test(52) ────────────────┐
                                └ build-images(187) → scan(71) ┘ → deploy(10) → healthcheck(3.4)
                                  └────────── 258 с ──────────┘
критический путь ≈ 4.5 + 6.3 + max(52, 258) + 10 + 3.4 ≈ 282 с

test (52 с) заканчивается задолго до build-images+scan (258 с). Узкое место — build-images+scan
на единственном shell-раннере, а не то, что ускорял AD-570, и не то, что параллелит buildbox.

4. MR-пайплайны: до/после AD-570

Хвост p75=218 с — пайплайны, где менялись requirements*/Dockerfile.ci и пересобирался ci-base
(джоба ci-base на shell-раннере). Целевые ~40 с достигаются, когда зависимости не менялись
(критический путь build+test ≈ 55 с + очередь).

5. Вклад раннера buildbox (AD-569)

Два docker-раннера обслуживают build/test (tag docker-build): docker-nas (tartarus) и
buildbox (andrey-ms7e06, 16c/32G). Все остальные джобы (ci-base*, build-images, scan, deploy,
healthcheck) — на одном shell-раннере nas (buildbox их не берёт).

Доля джоб на buildbox (после выхода buildbox в 22:12 07-16):

• 86 случаев, когда build/test шли на nas-docker и buildbox одновременно — подтверждённая
  кросс-пайплайновая параллельность. Раннер удвоил docker-ёмкость.
• В ночной серии (44 пайплайна за 6 ч) очередь build/test осталась ~1.0–1.4 с — без buildbox эти
  джобы вставали бы в очередь к единственному docker-раннеру.
• Загрузка раннеров в ночь: shell-nas 49 %, nas-docker 7 %, buildbox 6 %. То есть у docker-раннеров
  (в т.ч. buildbox) огромный запас, а упирается всё в shell-раннер.

Вывод: buildbox устранил очередь на build/test, но так как они уже не на критическом пути,
на время релиза он влияет мало. Его потенциал (docker + доступ к registry, простаивает на 94 %) стоит
направить на build-images/scan.

6. Ночная загрузка (07-17 20:00 … 07-18 02:00, 44 пайплайна)

Серия ~18 мержей в develop за ~2 часа (21:11 → 22:57) — «поезд» релизов.

Deploy-сериализация (resource_group) НЕ тормозит релиз — deploy быстрый (~10 с), ожидания почти нет.
Тормозит единственный shell-раннер: пока он гонит build-images(187 с)+scan(71 с)+deploy+healthcheck
предыдущего пайплайна, следующий стоит на ci-base-tag. Отсюда очередь до 9.6 мин — при том, что buildbox
и nas-docker простаивают на >90 %.

7. Interruptible (AD-568)

• После включения (07-16 20:32) 15 устаревших develop-циклов автоматически погашены новым коммитом.
• Гасятся рано (interruptible на ci-base-tag/ci-base/build): все 15 суммарно съели лишь 6.9 мин
  раннер-времени (≈0.5 мин на пайплайн вместо полного цикла ~5 мин).
• Экономия ≈ 15 × (build-images 187 + scan 71 + deploy 10) ≈ 67 мин shell-раннер-времени, которое иначе
  ушло бы на заведомо устаревшие сборки образов и деплои. Плюс — 15 лишних прод-деплоев не случилось.
• MR-пайплайнов interruptible за период не отменял (0) — MR-циклы короткие.

8. Рекомендации (по влиянию на скорость)

1. [Высокий] Снять build-images с критического пути — это главный затык сейчас.
   Два направления, дополняющие друг друга:
   - build-once/deploy-many по факту (AD-526): build-images
   сейчас каждый мерж пересобирает и aero-web, и cad (187 с медиана). Тянуть готовый образ по
   tree-hash сабдерева сервиса, если оно не менялось → чаще всего build-images схлопывается почти в ноль.
   - Разнести build-images/scan на buildbox (docker + доступ к registry, простой 94 %). Сейчас они
   привязаны к shell-раннеру nas вместе с deploy; на nas должны остаться только deploy/healthcheck
   (пишут в /opt/cortex). Это убирает и ночную очередь ci-base-tag.

2. [Средний] Параллелить build-images по сервисам (aero-web ‖ cad) на двух раннерах — режет самую
   тяжёлую джобу критического пути вдвое.

3. [Низкий] resource_group ordering (AD-601): по данным ночи
   ожидание deploy ~2 с — сейчас не узкое место. Смена на newest_first полезна как страховка на будущее
   (когда деплои начнут наслаиваться), но приоритет ниже пунктов 1–2.

4. [Отдельно, не про скорость] Zero-downtime (AD-571):
   --force-recreate даёт ~5 с недоступности прода на каждый мерж — вопрос надёжности, не скорости пайплайна;
   держать отдельным reliability-треком.

Приложение: методология

• Пайплайны: GET /projects/81171473/pipelines?ref=develop&updated_after=2026-07-15T00:00:00Z (+пагинация),
  MR — тот же запрос с source=merge_request_event.
• По каждому: GET /pipelines/{id} (duration, queued_duration, created_at, started_at, finished_at,
  status) и GET /pipelines/{id}/jobs (по стадиям: duration, queued_duration, runner.description).
• Раннеры: docker-nas (tartarus) и buildbox (andrey-ms7e06, 16c/32G) — docker (build/test);
  пустой description — shell-раннер nas (ci-base*/build-images/scan/deploy/healthcheck).
• Токен GitLab взят из git remote get-url origin (в отчёте/логах не печатался).