Pull to refresh

Comments 7

Я в своем проекте в какой-то момент сделал обратную вещь и выбросил bazel в пользу родного тулинга go/docker и обернул это все мэйкфайлами. По факту, мы поняли, что для нашего проекта bazel не решает ни одной задачи, которые решает родной тулинг. Зато добавляет геморой с поддержкой конфигурации сборки и скорее замедляет сборки (у базеля есть заметный оверхед на настройку тулчейна, который на сборке мелких программ в CI очень заметен). В добавок, мы хотели мультиархитектурные образы на выходе (arm64/amd64), а значит было нужно, чтобы у нас работала нормально кросс-компиляция и создание манифеста в конце. А кросс-компиляция в базеле отвратительно работает.

На сколько я понимаю, Bazel имеет следующие пенальти:

  • время анализа;

  • создание песочницы на каждый шаг;

  • запись и чтение из кэша. В итоге совсем чистая сборка с холодным кэшем действительно идёт чуть дольше. Но цифры сопоставимые.

Особый плюс Bazel-я проявляется при использовании общего кэша и фермы для сборки.

С кросс-компиляцией действительно всё плохо, но если не используется CGO, то тут спасает кросс-компиляция в самом Go.

Ну и интересно, когда именно Вы стокнулись с этими проблемами и какую ферму/общий кэш использовали?

Мы не дошли до оптимизации сборки кэшами. Команда решила перенять процессы/инструменты у соседней команды, которая начала работу заметно раньше, и вместе с этим притащили базел. Практически сразу я понял, что все кроме меня воспринимают конфигурацию базеля как магию и не понимают, что там происходит. Вся соседняя команда работала на amd64 и им кросс-компиляция нахер не сдалась. А у нас вся команда работает на arm64 и нам бы сборку под две архитектуры поддерживать. А поддерживать такую сложную штуку просто ради того, чтобы она была (потому что опять же никаких плюсов по сравнению с родным тулчейном go), нафиг не надо. Ну и у нас у каждого отдельно взятого микросервиса сборка/тесты проходят меньше чем за минуту. Нам просто нет нужды пытаться это оптимизировать. С базелем без кэшей оно становится втрое дольше, а настраивать кэши базеля для того чтобы решить проблему которую использование базеля и создало...

Кросс-компиляция с CGO это ад даже в самом Go, я недавно заставлял это работать с одним из сервисов.

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

Вопрос в этой ситуации был в том, развивать собственный инструментарий или заменить его на что-то готовое. После некоторого исследования пришли к выводу, что затащить Bazel будет более разумным.

Мы в текущем (iOS) проекте используем Bazel. Я бы сказал, что результаты смешанные. У нас есть дополнительные требования к системе сборки, которые xcodebuild из коробки обеспечить не мог. Но при этом основная проблема Bazel - да, время потраченное на сам bazel первые пол года работы было сопоставимо со временем написания кода. Сейчас вроде бы улеглось, хотя какой-то техдолг всё равно есть. Просто его никто трогать не хочет...

А это может помочь в случае, если в проекте есть один большой package?
Резать на отдельные его нельзя, к сожалению т.к. получается всё устройство кодгеном
Интересует как раз тоже ускорение тестов и сборки, особенно на локальных машинах, потому что сейчас запустить тесты этого проекта на локальных машинах не всегда возможно

Гранулярность Bazel-а при сборке Go-проектов - пакет.

То есть, если в пакете поменялся один файл, то пересобрать придётся весь пакет и, скорее всего, всё от чего он зависит.

Здесь, как мне кажется, Bazel может дать ускорение только за счет следующих моментов:

  • не нужно будет каждый раз пересобирать зависимости данного пакета;

  • если пакет не менялся, то его тесты могут быть закэшированны;

  • можно распилить тесты на https://bazel.build/reference/be/common-definitions#test.shard_count (грубо говоря, будет параллельно вызываться один и тот же исполняемый файл с разными аргументами, каждый раз выполняя часть тестов пакета);

Но для параллельного запуска тесты должны быть сами к этому готовы. Если они, к примеру, используют общую базу данных на машине разработчика, то будут проблемы.

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

В результате, к примеру, зачастую для проверки компилируемости проще и быстрее закинуть ветку на CI.

Sign up to leave a comment.