GitHub Actions тормозит на больших монорепо — как победить время сборки?

[gleb_flux33]

Монорепо на ~120 сервисов, все на Go и Python. GitHub Actions, самохостинговые раннеры на трёх серверах (32 ядра, 64 ГБ каждый). Проблема — при любом коммите в main запускаются все пайплайны, полный цикл занимает 45-50 минут. На небольших командах это ещё терпимо, но сейчас нас 30 разработчиков и очередь в раннеры постоянная. Что делаете для оптимизации в монорепо-сценарии?

[dnscache8196]

Первое что нужно сделать — path-based triggers. В каждом workflow добавляете `on: push: paths:` с путём к нужному сервису. Да, это нужно поддерживать, но зато не запускается 120 пайплайнов на изменение README. Второй шаг — `actions/cache` для зависимостей: Go modules и pip кеши между ранами. У нас это срезало время с 40 минут до 18 на полном прогоне.

[valera6777]

Path-based triggers — это полумера. Правильное решение — affected-change detection. Мы используем `nx affected` (да, даже для Go-проектов через custom executor) или самописный скрипт на bash который делает `git diff --name-only origin/main...HEAD` и определяет какие сервисы затронуты. Потом через `workflow_call` запускаем только нужные. Время упало с 50 до 8 минут на типичный PR.

[savva2867]

@jun_dev_2026, У нас похожая история. Решили через Turborepo — он умеет кеширование артефактов между пайплайнами через remote cache (можно self-hosted на S3-совместимом хранилище, у нас MinIO). Запуск `turbo run build test --filter=[HEAD^1]` сам определяет что изменилось и не пересобирает то что уже кешировано. На 80 сервисах типичный прогон — 6-7 минут.

[rodion_pixel50]

Не забывайте про Docker layer caching. Если у вас образы пересобираются в CI — добавьте `cache-from: type=gha` и `cache-to: type=gha,mode=max` в `docker/build-push-action`. GitHub Actions кеширует слои между ранами. Ещё — переходите на `docker buildx` с multi-platform если нужны ARM-образы, это быстрее двух отдельных сборок.

[igor_pixel18]

Три раннера по 32 ядра — это хорошо, но проверьте что у вас `runs-on: self-hosted` не ставит всё в очередь последовательно. Нужен лейбл для параллелизма: `runs-on: [self-hosted, linux, x64]` и `max-parallel: 10` в matrix strategy. Ещё поставьте на раннеры `actions-runner-controller` в k8s — он умеет автоскейлинг раннеров под нагрузку, не держите три монолитных сервера.

[sergey_cache81]

Самое радикальное — Dagger. Переписываете пайплайны на Go/Python SDK, они запускаются локально и в CI идентично, кеш шарится через Dagger Cloud. Мы потратили две недели на миграцию 40 сервисов, зато теперь разработчик гоняет те же шаги локально что и в CI. Время полного прогона в CI — 4 минуты, потому что 90% слоёв уже в кеше.