Monorepo CI: affected-сборки и remote-кэширование

Affected: от git diff к подмножеству графа задач

К концу урока ты поймёшь, почему 40-минутная сборка случается даже на однострочном PR — и какие три рычага дают CI масштабироваться с diff’ом, а не с репозиторием.

«Собирать и тестировать всё на каждый PR» — корректно и, в большом монорепо, разорительно. Стоимость растёт с размером репозитория, тогда как ценность любого отдельного PR зависит лишь от того, что он изменил. Affected-сборки разрывают эту связь. Инструменты — Nx, Turborepo, Bazel — моделируют репозиторий не как плоский список пакетов, а как граф проектов: узлы — проекты, рёбра — отношения import/зависимостей. Над ним лежит граф задач: build, test, lint для каждого проекта, связанные так, что build проекта зависит от build его зависимостей.

Вычисление affected-набора — два шага. Сначала инструмент спрашивает у git, какие файлы изменились между двумя коммитами — --base и --head — и сопоставляет каждый тронутый файл с проектом, которому он принадлежит. Это даёт напрямую изменённые проекты. Затем он обходит граф проектов в обратную сторону: любой проект, который транзитивно зависит от изменённого, тоже затронут, потому что изменение выше по графу может его сломать. Объединение — это affected-набор, и инструмент запускает запрошенные задачи ровно для этого подмножества.

# В CI: base = последний успешный SHA main, head = вершина PR.
# nrwl/nx-set-shas экспортирует их, чтобы не диффать против устаревшей точки.
nx affected -t build,test,lint --base=origin/main --head=HEAD

# Turborepo выражает ту же идею через граф пакетов + git:
turbo run build test lint --filter='...[origin/main]'

База важнее, чем кажется. Установи её на последний успешный коммит main, а не на фиксированную точку ветвления — иначе долгоживущий PR диффает против старой базы, пересчитывает огромный affected-набор, и выигрыш теряется. В CI это подключают хелпером вроде nrwl/nx-set-shas.

Remote-кэш: хэшируй входы, восстанавливай выходы

Affected говорит, что запускать. Кэш говорит, нужно ли вообще. Перед выполнением задачи инструмент считает хэш по всему, что может повлиять на выход: исходники проекта, разрешённые хэши его зависимостей, конфигурация задачи, версии инструментов и любые объявленные переменные окружения. Этот хэш — ключ кэша. Если задача с ровно таким ключом уже выполнялась раньше — кем угодно, на любой машине — её записанный выход (dist/, результат теста, логи) скачивается и проигрывается вместо пересчёта.

Рычаг в том, что кэш общий и адресуемый по содержимому. Turborepo делит это на глобальный хэш и хэш задачи; меняется любой — задача промахивается. Коллега, уже собравший main локально, или прошлый прогон CI наполняют remote-кэш (Nx Cloud, Turborepo Remote Cache), из которого читает твой прогон. Попадание в кэш, превращающее многоминутный build в восстановление артефакта за доли секунды, — это и есть разница между CI, который масштабируется с diff’ом, и тем, что масштабируется с репозиторием.

Sharding: распредели остаток по раннерам

Affected и кэширование сокращают, какие задачи бегут. Sharding сокращает, как долго бегут выжившие, запуская их параллельно на N раннерах. Классическая форма — матрица CI: разбей набор из 2000 тестов на шарды 1/4 … 4/4, дай каждому свой раннер — и сорокаминутный прогон финиширует за ~10 (четырёхкратно ≈ на 75% быстрее); маленький набор падает с 3 минут до 30 секунд. Nx Cloud и Turborepo идут дальше и распределяют сам граф задач по агентам, соблюдая порядок зависимостей, чтобы нижестоящий build ждал свой вышестоящий.

# GitHub Actions matrix: 4 параллельных тестовых шарда.
strategy:
  matrix:
    shard: [1, 2, 3, 4]
steps:
  - run: npx jest --shard=${{ matrix.shard }}/4   # или: nx affected -t test --parallel

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

Честный трейдофф: affected + remote-кэш — самый высокорычажный ход, но вся его ценность держится на том, что хэш полон, а вычисление affected узко. Упустишь вход — отгрузишь устаревшее; дашь корневому файлу раздуть affected-набор — заплатишь за настройку впустую.

Режимы отказа, стирающие выигрыш

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

Радиус поражения корневого файла. Измени tsconfig.base.json, nx.json или — классика — lock-файл, и инструмент метит всё как affected. Случай lock-файла — намеренная подстраховка: бамп зависимости мог бы затронуть любой проект, поэтому по умолчанию Nx перестраховывается и пересобирает всё. В итоге рутинное обновление package-lock.json детонирует полную сорокаминутную сборку, и команда, не понимающая почему, заключает «affected не работает». Он работает; ты задел провод глобального входа. Настраиваешь это через namedInputs, чтобы глобальными считались лишь действительно глобальные файлы — но неверно очертив glob {workspaceRoot}, ты сам воссоздаёшь радиус поражения.

Устаревшее попадание от незахэшированного входа. Разобрано выше: переменная окружения, версия инструмента или конфиг-файл, влияющие на выход, но отсутствующие в хэше. Кэш возвращает сборку, неверную для текущих входов, и поскольку попадание тихое и быстрое, оно может пройти ревью и доехать до прода. Это самый опасный отказ, потому что он не падает — он успешно отдаёт неверный ответ.

Отравление remote-кэша / доверие. Remote-кэш — это общая поверхность записи. Если недоверенный актор (PR из форка, скомпрометированный токен) может писать артефакты, он подкладывает вредоносный dist/ под ключ, который позже прочитает доверенная сборка, и твоё «попадание в кэш» запускает его код. Поэтому Turborepo подписывает артефакты через HMAC-SHA256 и проверяет их при скачивании, считая любой не прошедший подпись артефакт промахом — и поэтому доступ на запись в кэш ограничивают узко и не дают недоверенным PR наполнять кэш, который потребляют доверенные прогоны.