В монорепозитории с десятком сервисов полный прогон тестов и сборка всех сервисов на каждый PR занимает слишком много времени. Как настроить CI, чтобы собирать и тестировать только затронутые изменением пакеты?

Короткий ответ

Нужно определить граф зависимостей между пакетами (через инструменты вроде Nx, Turborepo, Bazel или по структуре директорий) и на каждый PR вычислять список изменённых файлов, запуская сборку/тесты только для затронутых пакетов и тех, что от них зависят, а не для всего монорепозитория целиком.

Как это работает подробнее

инструменты для монорепозиториев строят граф зависимостей на основе импортов/package.json-ссылок между внутренними пакетами и умеют вычислять «affected»-множество на основе diff между текущей и базовой веткой (`nx affected`, `turbo run test --filter=...[origin/main]`). Это позволяет запускать только релевантные джобы, а не весь набор.

Пример кода

example1.shКопировать

# Выполнить тесты только для пакетов, затронутых изменениями относительно main
npx nx affected --target=test --base=origin/main --head=HEAD

Пример кода

example2.txtКопировать

Affected projects: payments-service, payments-service-e2e
Skipped (not affected): notifications-service, auth-service, billing-service

Что использовать на практике

• На практике. такой подход особенно выгоден, когда сервисы в монорепо не имеют сильной связности — изменение одного микросервиса не должно требовать пересборки и тестирования остальных девяти. Нужно быть аккуратным с транзитивными зависимостями — если изменена общая shared-библиотека, affected-набор должен включать все пакеты, которые её используют, а не только саму библиотеку.
• Пример. Ожидаемое поведение: при PR, меняющем только `payments-service`, пайплайн выполняет тесты для двух затронутых проектов за 2 минуты вместо полного прогона всех 10 сервисов за 25 минут, при этом изменение в общей библиотеке `shared-utils` корректно триггерит пересборку всех зависимых от неё сервисов.

Подводные камни

• Частые ошибки. вычисляют affected-набор только по прямым, а не транзитивным зависимостям, из-за чего изменение в общей библиотеке не триггерит пересборку сервисов, которые её используют; полностью отключают полный прогон для веток релиза/main «для скорости», теряя подстраховку перед критичным мерджем.