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

[lost300z]

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

[baseddeadlock]

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

[allyssa]

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

[Tanyagor75]

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

[qemukun]

Не забывайте про 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-образы, это быстрее двух отдельных сборок.

[van100]

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

[juniorredteam]

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

[gillan]

path-based triggers — хорошая точка входа, но для 120 сервисов поддерживать 120 файлов workflow с ручными paths это отдельный ад. Нормальное решение — один «оркестратор»-workflow, который через git diff вычисляет affected-список и динамически матрицей раскидывает джобы. Тогда и кеш работает адресно, и поддержка в одном месте. У нас на 60 сервисах такой подход держит прогон в 6-7 минут на типичный PR.

[tim28]

@van100, про actions-runner-controller полностью согласен, но там есть нюанс с self-hosted раннерами на bare-metal: ARC по умолчанию запускает pod-раннеры в k8s, а значит надо либо k8s-кластер рядом держать, либо использовать RunnerSet с container hooks. Если у ребят три физических сервера без кубернетеса — проще поднять ephemeral раннеры через официальный runner с --ephemeral флагом и systemd-сокетной активацией, это даёт большую часть профита без оверхеда на k8s.

[docker13]

@juniorredteam, Dagger интересная история, но «две недели на миграцию 40 сервисов» — это при наличии кого-то кто хорошо знает Go SDK? У нас попытка переехать на Dagger заглохла именно на этапе onboarding команды: половина народа пишет на Python, Go SDK им был чужой, Python SDK тогда ещё был сырым. Как у вас решили вопрос с тем что разные сервисы на разных языках?