Сборка и тесты

Эта страница помогает добиться зеленых тестов на своей машине и объясняет, что CI запускает на вашем pull request. Как поставить Rust и драйвер GPU, здесь не описано.

Что где лежит в репозитории

Путь	Что там лежит
`crates/`	Крейты на Rust, всего 122.
`tools/`	Инструмент обновления снапшота, фикстуры, ванильный оракул и бенчмарки.
`xtask/`	Запускалка проверок, которой пользуются CI и локальные хуки.
`assets/`	Файл версии, отчеты из игры и локальные датапаки.
`docs/`	Спецификации и заметки по дизайну. Их перечисляет индекс docs.
`docs-site/`	Этот сайт.

Запустите тесты

cargo nextest run -p <crate>        # один крейт
cargo nextest run --workspace       # все, перед коммитом
cargo nextest run --profile full    # плюс исчерпывающие прогоны

Тесты запускает cargo-nextest. Версию тулчейна Rust репозиторий фиксирует в rust-toolchain.toml, а минимальную версию раннера - в .config/nextest.toml. Не пользуйтесь cargo test, потому что он не читает .config/nextest.toml, а в большинстве крейтов стоит doctest = false. Хук Claude Code в репозитории его отклоняет.

Тесты читают датапак игры, поэтому каждый профиль сначала запускает setup-скрипт, который ставит клиентский jar игры и распаковывает его датапак в ваш каталог кеша. Руками ничего скачивать не нужно, но первому запуску нужен доступ в сеть к Mojang.

В имени теста есть префикс уровня, например exhaustive:: или gpu::, и каждый профиль отбирает тесты по этому префиксу.

Профиль	Что запускает
`default`	Все, кроме тестов `exhaustive::`, `gpu::`, `online::` и `vanilla_server::`.
`ci`	Тот же фильтр, что у `default`, и прогон не останавливается на первом падении.
`ci-hosted`	Фильтр как у `ci`, для job `test` на машине GitHub с четырьмя ядрами. Один тест может идти 5 минут, весь прогон 30 минут.
`full`	Уровень default плюс `exhaustive::` и `online::`. Им пользуется job CI по расписанию.
`gpu`	Только тесты `gpu::`. Им нужна машина с Metal GPU.
`vanilla-server`	Только тесты `vanilla_server::`. Они запускаются через `vanilla-server/run.sh`.

Ни один прогон тестов не должен идти дольше пяти минут, кроме ci-hosted. Тесту, который работает дольше, место на уровне exhaustive::.

Запустите проверки xtask перед push

CI и локальные хуки вызывают одну и ту же запускалку, scripts/hooks/run-checks <trigger>. Она собирает xtask и выполняет проверки, которые относятся к триггеру. Те же проверки можно запустить самому перед push:

scripts/hooks/run-checks commit

У каждого триггера свой постоянный набор проверок. Чтобы увидеть все триггеры, запустите scripts/hooks/run-checks без аргументов.

Триггер	Проверки
`commit`, `push`	`parity`, `fmt`
`lint`	`parity`, `fmt`, `keys`
`clippy`	`clippy`
`test`	Тесты измененных крейтов и тех, что от них зависят.
`portability`	`no-bevy`, `layers`, `wasm32`, `no-std`

fmt и clippy запускают одноименные команды Cargo. Остальные проверки написаны для mcrs, а списки пакетов, по которым они идут, лежат в xtask/src/checks.rs.

Проверка	Что она требует
`parity`	Тест, который заявляет ванильное поведение, должен загружать фикстуру, выданную игрой. За сравнение с литералом проверка выдает предупреждение. О parity-тестах рассказывает страница Спецификации и parity-тесты.
`keys`	Сгенерированные исходники ключей реестров должны совпадать с тем, что генератор пишет по сохраненным отчетам. Никогда не правьте сгенерированный файл руками.
`no-bevy`	100 пакетов должны собираться без Bevy.
`no-std`	9 пакетов должны собираться под таргет без std.
`wasm32`	11 пакетов должны собираться под wasm32.
`layers`	Крейты уровней wire и network не должны линковать игровые данные, чтобы прокси или бот могли взять только их.

Перезапишите устаревший blessed-файл через MCRS_BLESS

Некоторые тесты сравнивают сгенерированный файл с копией в репозитории, ее называют blessed-файлом. Так проверяются запеченные ассеты сущностей и таблица полей шейдера. Когда копия устарела, тест падает, а в его сообщении названа переменная окружения. Запустите тест еще раз с этой переменной, и он перезапишет копию:

MCRS_BLESS=1 cargo nextest run -p <crate>

Перед коммитом прочитайте diff. Если blessed-файл изменился, а вы не можете сказать почему, ошибка в вашем изменении, и тест упал правильно. Переменную читают тесты в crates/mcrs_minecraft_mesh/src/pack.rs и crates/mcrs_minecraft_entity_model/tests/it/mob_assets.rs.

Что CI запускает на вашем pull request

Workflow .github/workflows/checks.yml запускается на каждом pull request в main и на каждом push в main. Его первый job, changes, читает список файлов pull request. Если каждый файл лежит в docs/, или это Markdown-файл в корне репозитория, или файл LICENSE-*, остальные job не запускаются и проверка проходит. Изменение в docs-site/ запускает полный набор.

Какие job запустятся, зависит от того, откуда пришел pull request.

Источник	Job
Ветка этого репозитория	`lint` на машине GitHub `ubuntu-24.04`. Один job `self-hosted` на собственном раннере проекта запускает триггеры `clippy`, `test` и `portability` одновременно.
Форк	`lint`, `clippy`, `test` и `portability`, каждый на машине GitHub `ubuntu-24.04`. Они стартуют с кешей сборки, которые сохраняет каждый push в `main`.
Push в `main`	Оба набора.

Последний job, checks, падает, если не прошел хотя бы один из job, которые должны были запуститься.

На машине GitHub триггер test берет профиль ci-hosted, и Cargo разрешает фичи только для выбранных пакетов. В CI тесты пропускают каждый крейт, который зависит от wgpu, и все, что стоит выше него. Эти тесты идут только локально, поэтому запускайте их сами, когда трогаете клиент или рендерер.

Второй workflow, docs, предупреждает о страницах этого сайта, у которых изменились источники. Он описан на странице Как писать эту документацию.

В работе#507 Планирует отчет о правилах спецификаций, которые не проверяет ни один тест. ↩

Источники и проверка

Проверено: 26.4-snapshot-7, 3540f457b, 2026-11-10

Переведено с версии 3540f457b

Следить: #507