# CI и build система для больших проектов на Rust

## Intro

Всем привет, я Денис Писарев, DevOps. Ex-CI Team Lead. Живу в Берлине и работаю в Parity Tech уже почти 5 лет. Нравится.

В команде сейчас 6 человек и мы занимаемся только CI/CD. Хостами, кластерами, provisioning, деплоем, безопасностью, мониторингом. Конфигами CI конечно. Ещё у нас экспертиза по всем, что касается контейнеров.

В прошлом году я выступал на конфе с докладом про выбор CI системы для Rust и как *безопасно* позволить внешним разработчикам компилить на своём железе. Также, там было про особенности кеширования Rust. За 8 месяцев с моего доклада в Rust с этой точки зрения не изменилось ничего, а мы устали ждать и скорректировали планы.

Не буду сильно повторяться, ведь это уже есть на ютубе, ссылка в конце доклада, там deep dive в CI и технический детали кеширования Rust. Дам короткую вводную про CI системы.

В этот раз я расскажу продолжение: с чем мы столкнулись и как выбрались. TLDR; доклад об эффективном кешировании Rust для больших проектов.

Когда я пришёл в Parity, у нас был только один продукт. Это был `parity-ethereum` клиент. Он написан на Rust и был тогда де-факто стандартом майнеров и full-node Ethereum. Он был значительно быстрее и надёжнее нативного клиента `Geth`, разработчики Ethereum Foundation даже стали оптимизировать их десятки тысяч тестов под `parity-ethereum`.

Тот самый супер-быстрый бинарник `parity-ethereum` тогда компилился 45 минут. Первое, что я сделал на новой работе - посмотрел почему так и снёс `cache:` из GitLab CI джобов. Бинарник стал собираться за 15 мин, все были *очень* рады. Потом я стал лидом и набрал себе команду.

Кеш был настроен неправильно.

## Выбор CI системы

Jobs - автоматизированные изолированные (в контейнерах) и воспроизводимые задачи, скрипты исполняющие необходимые действия с кодом - линты, тесты, сборки, упаковка, интеграционные тесты и прочий релиз (это уже CD часть CI/CD).

CI система это Continuous Integration: ваши jobs выстроены в логические связи - пайплайны, сначала линты, потом unit tests, потом сборка. Если пора релизить, то подпись и отправка собранных пакетов. Удобно об этом думать как о роботизированном конвейере.

Тогда я изучил все современные CI системы. Но ни одна нам не подошла по разным причинам. То нельзя использовать свои docker-images, то нельзя селф-хостить сервер и раннеры, то раннеры слишком негибкие, то несовместимы с некоторыми ОС. Остановился на GitLab, но только в качестве CI для проектов на GitHub. Он очень гибкий и им пользуются многие уважаемые open-source проекты.

Проблема с GitLab в том, что они ведут святую войну против GitHub, портят интеграции, и, судя по общему количеству open-source проектов, а главное разработчиков, проигрывают. Дело в том, что если ты хочешь self-hosted репозиторий, GitLab в отличие от GitHub (кроме enterprise, но это совсем отдельная и грустная история) позволяет это. Но self-hosted будет жить на отдельном адресе, аккаунты на gitlab.com не будут иметь туда доступа. Нагуглить эти репозитории тоже непросто.

И картина получается такая: если ты как девелопер ищешь новую работу, нужно добавлять ссылки на свои контрибуции в open-source проекты. Ну и к сожалению, дальше GitHub никто особо не смотрит. Так, до проектов, захосченных на GitLab не добирается очень много разработчиков. А жаль, к (моему) сожалению, Microsoft - GitHub не лучшим образом заботится об open-source.

### Open Pipelines

Весь (зрелый) код, который разрабатывает компания - open source. Даже инфра, и мы открываем всё больше инфры.

Для открытых проектов мы проповедуем Open Pipelines. Это значит что любой, кто контрибутит в код, создаёт внешний PR, получает себе точно такой же пайплайн, как и core-developer. И всё это - на нашем железе. Зачем? А иначе внешние контрибьюторы получат меньше тестов. Или иначе им вообще пришлось бы собирать и тестировать код у себя. Works on my machine? *Ннет, спасибо!* Open Pipelines уже стал стандартом для open-source.

GitHub Actions и GitLab CI - известные примеры Open Pipelines.

### Проблемы встроенного кеширования

Дальше я расскажу про проблемы встроенного кеширования в GitLab и GitHub.

Встроенный функционал кеширования в GitLab и GitHub не подходит для больших проектов не только на Rust, но и на всех компилируемых языках.
- У GitLab встроенная система кеширования толком неуправляемая. Кеш архивируется и загружается на сервер в конце джоба и в начале нового загружается и разархивируется. Кеш одних только тестов Substrate больше 14Гб, это большой оверхед.
- Нормально деплоить GitLab через IaC у нас толком не получилось, к сожалению.
- Если кеш репозитория перерастает 10 Гб (не ветки, а всего проекта!), кеш GitHub Actions начинает удаляться. Это искусственное ограничение GitHub Actions runner, его нельзя обойти даже на self-hosted runner.
- Ещё, там нет возможности управлять кешем, никак. Он всегда загружается через интернет *куда-то* в Azure, даже с self-hosted runner.
- Он не хранит кеш docker images, что само по себе сильно удлиняет джобы, каждый раз приходится их скачивать.
- Чтобы иметь собственные VM в GHA, нужно прям глубоко забираться в vendor-lock-in с Microsoft, а это *как-то* не входит в планы компании, которая хочет делать unstoppable web :)
- Нам много контрибутят внешние разработчики и у нас есть джобы, которые используют GitHub секреты. Такой джоб не запустится для внешнего PR и это не обойти.

Все остальные современные CI системы ничего радикального не предлагают.

**В общем**, если у вас небольшой проект - можно не париться и сидеть на GitHub: есть много хороших Actions, которые помогут сильно оптимизировать пайплайны.
А когда суммарный кеш вашего проекта перерастает 10 Гб, пора задумываться.

### Нынешний сетап

Таким образом, нам пришлось наладить тулинг, за неимением официального инструмента: оригинальный код хостится на github.com, разработчики коммитят на GitHub, и могут видеть все логи на GitLab своими глазами, ссылки на CI джобы отображаются прямо в PR. И ещё git-ops: написав команду сообщением в PR можно запускать отдельные бенчи, тесты и тестовый деплоймент, мержить и прочее.

Мы много наконтрибьютили в sccache нашим форком и написали внутренний тул для остального кеша. Это уже сокращает время компиляции до 70% в среднем, но, как мы выяснили, это был путь не туда и можно *сильно* лучше!

( Раньше мы хотели его open-source-ить, но после редизайна мы пришли к выводу, что лучше подойти к проблеме с другой стороны.)

Опишу где мы сейчас находимся. Мы перевели CI хосты с bare-metal в облако. Получили мгновенное scalabilty, но прямо сейчас это обходится нам в 5 раз дороже. Прямо сейчас переезжаем на spot инстансы и потом убираем лишнюю абстракцию в виде VM и переезжаем в k8s.

### Следующий шаг

Редизайн заключается в следующем:
- переписываем CI конфиги на GitHub Actions, уходим от GitLab CI ради упрощения всей системы. Плюс, разработчикам так больше понравится.
- У GitHub Actions не было встроенной поддержки Kubernetes и довольно плохие self-hosted runners. Мы нашли хороший, в прошлом поддерживаемый сообществом, (теперь GitHub сделал его официальным) проект open-source раннера, который исполняет джобы в твоём кластере. Он достаточно гибкий и покрывает все наши требования. Ссылка в конце доклада.
- Будем использовать Bazel, об этом **вторая часть доклада**.

## Проблемы с Rust
Сейчас я расскажу про проблемы с Rust с точки зрения больших проектов и масштабирования CI.

### Ограничения Cargo

Rust tooling замечателен для начинающих, но с ростом проекта приходит разочарование.

В Cargo Book написано: Cargo - Rust package manager. Cargo загружает зависимости вашего пакета Rust, компилирует ваши пакеты, создает распространяемые пакеты и загружает их на crates.io.

#### Cargo - не build система

Cargo выбрал простоту и удобство использования вместо общности и масштабируемости; он не очень хорошо отслеживает зависимости и не поддерживает произвольные графы сборки. В большом монорепо это превращается в dependency hell.

#### Плохое кэширование и отслеживание зависимостей

Cargo полагается на timestamps модификации файлов для инкрементальных сборок. Обновление даже комментариев кода или переключение веток git может привести к инвалидации кэша cargo, вызывая длительные пересборки. Sccache может улучшить попадание в кэш (cache hits), он не работает со всеми видами кеша Rust.

Средства отслеживания зависимостей в Cargo относительно просты. Например, мы можем сказать cargo повторно запустить build.rs, если некоторые входные файлы или переменные окружения изменятся. Тем не менее, cargo не знает, к каким файлам или другим ресурсам могут обращаться тесты, поэтому он должен быть консервативным в кэшировании. Как следствие, мы билдим гораздо больше, чем нужно.

## Выбор тулинга для сборки Rust

- Gradle - вариант, можно заставить работать лучше cargo, но особо ничего специального для Rust там нет, просто он гибче.
- https://nixos.org/ - не подходит для больших проектов. Единица кэширования в Nix - деривация. Если бы мы хотели в полной мере использовать возможности кэширования nix, нам пришлось бы "никсифицировать" все наши внешние зависимости и внутренние пакеты Rust (по одной деривации на каждый пакет Rust).
- https://github.com/matklad/cargo-xtask - это как Makefile по сути, ничего инновационного.
- Fleet от JetBrains - неплохо, но использует cargo, а значит не лишён его недостатков
- Различные workarounds типа cargo chef или хранить кеш прямо в build image
- Из хорошего, что может сильно ускорить ваши тесты до миграции - nextest, рекомендую

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

### Bazel

Bazel - это система сборки и тестирования с открытым исходным кодом, подобный Make, Maven и Gradle. Он использует человекочитаемый высокоуровневый язык сборки. Bazel поддерживает проекты на разных языках и собирает продукты для различных платформ. Разработан как внутренний тул инженерами Google, их внутренний инструмент называется Blaze. Потом они его опнсорснули и теперь его поддерживает сообщество.

Билд файлы сборки подробные, иногда скучные, но это хорошо. Они точно передают читателю, какие артефакты и зависимости есть у модуля.

Раньше мы не хотели его использовать по двум причинам:
- Год назад там слишком многого не хватало, чтобы мы решились на него переходить.
- Не хотели добавлять в фрагментирование экосистемы Rust. Но видя, в какую сторону развивается cargo, этот пункт отпадает - нам нужна билд-система.

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

Но, раз мы open-source разработчики, и в главных правилах у нас использование open-source софта, это же значит что мы контрибьютим в те проекты, которые используем. В рабочее время тоже.

Bazel достаточно прост в начальном освоении для каждодневного использования. Сильно сложнее на уровне инжиниринга.

Он предлагает множество возможностей, но нас в основном интересовали следующие:

- **Bazel использует content-addressable storage** для кэширования артефактов сборки, что означает, что он не зависит от временных меток модификации файлов, как это делает Cargo. Bazel также точно отслеживает зависимости и может пересобирать только затронутые цели, когда что-то меняется.
- Может запускать только те тесты, которые релевантны для изменений в коде.
- **Поддержка произвольных графов сборки**: Bazel может выражать сложные сценарии сборки, которые Cargo не может, такие как сборка и тестирование WebAssembly, постобработка бинарников или интеграция с другими языками и инструментами. Bazel также поддерживает кастомные правила сборки.
- **Гибкость**, позволяет охватить все наши сценарии использования, он управляется со всем, что нам нужно: Linux, macOS, Windows, образы ОС, контейнеры Docker. И что самое интересное: Мы можем комбинировать и смешивать эти артефакты любым удобным способом.
- **Агрессивное кэширование**. Функция sandboxing гарантирует, что действия сборки не используют необъявленные зависимости, что может быть важно для лицензирования, ещё это делает гораздо более безопасным кэширование артефактов сборки и, что наиболее важно для нас, результатов тестирования.
- **Удаленное кэширование**. Можно использовать кэш из CI-системы для ускорения локальных сборок разработчиков. Можно даже его публиковать (с доступом только на чтение), чтобы внешние контрибьюторы билдили и тестировали локально быстрее!
- **Распределенные сборки**. Bazel может распределять одну задачу сборки на несколько машин, чтобы завершить сборку еще быстрее. И не повторять сборку, если артефакт не требует изменений, а просто переиспользовать его.
- **Контроль видимости**. Bazel позволяет авторам пакетов помечать некоторые пакеты как внутренние, чтобы другие команды не могли импортировать код.
- **Контроль над графами зависимостей** очень важен для быстрой сборки. Он позволяет определить оптимальный порядок сборки проектов, избежать ненужных или повторяющихся сборок, и обнаружить ошибки или уязвимости в зависимостях. С помощью графа зависимостей можно также автоматизировать процесс сборки и тестирования, что ускоряет разработку и доставку продукта.
- Можно настраивать версии внешних зависимостей в одном файле.

Что еще более важно, Bazel унифицирует нашу среду разработчика и CI. Все тесты теперь будут тестами Bazel, а значит, каждый разработчик может запустить любой тест локально через `bazel test --config=ci ...`.

## Миграция

Миграция больших проектов будет непростой.

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

### Прототип

Первым делом нужно выбрать проект, который вызовет больше всего сложностей. Со сложным графом зависимостей, кучей разных тестов, компиляцией Rust в WebAssembly и нативный код за один вызов и настройку поддержки rust-analyzer.

Мы форкнем Polkadot с WebAssembly runtime и генерацией кода макросами, отрежем для начала некоторые части, чтобы сократить время компиляции. Когда с урезанной версией всё заработает, форкнем полную версию и доведем конфиги до конца.

Когда в прототипе всё будет работать, а это пока что MVP, который местами запускает Bazel'ом cargo, пора переходить в прод.

### Постепенный отказ от cargo

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

### Переписать Cargo.toml в файл WORKSPACE

Файл WORKSPACE в Bazel - корень вашего проекта. Он указывает внешние зависимости, на которые опирается ваш проект. Это как карта, по которой Bazel находит все необходимые файлы и зависимости для вашего проекта. Она помогает Bazel понять, с чего начать сборку проекта, и гарантирует, что все зависимости находятся на месте.

В конце доклада будут полезные ссылки, в одной из них хорошо описано, как это сделать.

### Сразу в CI

Как только у вас появится первый рабочий BUILD файл, сразу заменяйте CI джобы, которые смогут его использовать, это будет первый шаг для адопшена новой системы программистами. Они начнут видеть ошибки и логи уже из Bazel и начнут активно учиться на них, установят Bazel себе на компы и начнут помогать модифицировать BUILD файлы.

### Миграция тестов

Последняя часть миграции. Cargo обнаруживает тесты *автомагически*, в то время как файлы Bazel BUILD требуют явных целей для каждого типа тестов (crate-тесты, doc-тесты, интеграционные тесты). Нужно удостовериться что учтён каждый тест и что разработчики не забывают обновлять BUILD-файлы при добавлении новых тестов.

## Проблемы Bazel

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

- **Поддержка IDE**.
- **rules_rust**: Плагин Bazel экспериментально поддерживает rust-analyzer. Этот проект предоставляет правила для сборки проектов Rust с Bazel. Там есть правило `rust_analyzer`, которое может генерировать файл `rust-project.json`, описывающий структуру проекта Rust. Этот файл требуется rust-analyzer для не-cargo проектов.
- **cargo check**. Cargo не создает бинарники при запуске в режиме check, что делает его намного быстрее, чем `cargo build`. Разработчики часто используют этот режим для проверки компиляции всей кодовой базы.
- **Публикация пакетов**. Мы публикуем некоторые из наших пакетов Rust на crates.io, а плагин `rules_rust` Bazel пока не предоставляет замену `cargo publish`.
- **Недостаточная интеграция с экосистемой Rust**: Bazel не использует Cargo или crates.io для управления зависимостями Rust, что означает, что он не *получает преимуществ* менеджера пакетов Rust. Bazel также не поддерживает некоторые возможности Cargo, такие как функции, workspaces или profiles. Многие полезные инструменты полагаются на cargo и пока не имеют аналога в мире Bazel.

Тут придётся либо делать интеграции самим, либо временно поддерживать файлы cargo.

## Полезные ссылки

Рекомендую посмотреть мой прошлый доклад, он на русском, там много про CI, безопасность, оптимизации и как его правильно готовить https://www.youtube.com/watch?v=FAwEgQNcZ00&list=PLK6ihTQsAvc7WNUIEkS3Y8Ygt4fMfhUjO

https://github.com/actions/actions-runner-controller - GitHub Actions runner в Kubernetes.

https://bazel.build/ - официальный сайт и документация Bazel

https://earthly.dev/blog/bazel-with-rust/ - хороший пост о том, как внедрить Bazel в проект с нуля

https://github.com/bazelbuild/rules_rust и его официальный сайт http://bazelbuild.github.io/rules_rust/ - интеграция и базовые правила Rust и Bazel

https://github.com/google/cargo-raze - экспериментальный плагин Cargo для перевода Workspace Cargo.toml в BUILD файл.

http://bazelbuild.github.io/rules_rust/rust_analyzer.html - rust-analyzer с поддержкой Bazel