Достали гитлабовские раннеры: сборки по 40 минут, кеш живет своей жизнью. Как у вас устроено?

[depechie]

Наболело. Self-hosted gitlab 18.0, раннеры на двух виртуалках в таймвебе. Монорепа: фронт на next, бек на go, сборка образов через docker executor + dind. И это боль. Кеш node_modules то подхватывается, то нет. Docker layer cache после каждого чиха пустой. Пайплайн на MR идет 35-40 минут, разработчики воют, я тоже.

Что пробовали: cache в s3 селектела, стало чуть лучше, но нестабильно. buildkit с cache-to registry, на go норм, на next толку мало.

Расскажите, кто как готовит раннеры в 2026. Тащить kubernetes executor? Или плюнуть и взять дедик пожирнее?

[antico]

Дедик пожирнее это не шутка, а правильный ответ. Мы взяли один ryzen 9 с 128 гигами за 11к в месяц вместо трех виртуалок. Сборки упали с 30 минут до 8. Кеш на локальном nvme живет идеально, s3 для кеша больше не трогаем вообще. Виртуалки для CI это оплата за чужой оверхед.

[kiwash]

kubernetes executor имеет смысл только если кластер у вас уже есть и его кто-то обслуживает. Ради раннеров поднимать k8s это лечить головную боль гильотиной. По сборке образов: dind выкидывайте, buildkit rootless или buildah. kaniko не советую, если кто предложит, репа в архиве, проект мертвый.

[rbacker]

next в монорепе без turborepo собирать это ну такое, у вас половина времени уходит на пересборку того что не менялось. сначала remote cache на уровне сборки фронта, потом уже раннеры тюнить. но это уже не к девопсам вопрос, а к фронтам

[vemina]

35-40 минут еще терпимо, у нас час двадцать и все привыкли, лол. человек ко всему привыкает