Skip to content

Issue #252 solved: build and test the Rust crates in CI - #253

Open
PRINCEKK122 wants to merge 1 commit into
oss-slu:mainfrom
PRINCEKK122:rust-ci
Open

PRINCEKK122 wants to merge 1 commit into
oss-slu:mainfrom
PRINCEKK122:rust-ci

Conversation

@PRINCEKK122

Copy link
Copy Markdown
Contributor

Closes #252.

Problem

Nothing in CI builds or tests the Rust crates. .github/workflows/ holds meson-build.yml, which builds the C++ plugin on Windows with its test step commented out, and super-linter.yml, which lints YAML, GitHub Actions and clang-format. Neither runs cargo at all.

So relay, src/server and baton — where most current development happens — have had no automated coverage. That is how main came to be failing two relay tests with nobody aware of it (#251).

Change

A Rust workflow running on pull requests and pushes to main:

  • A matrix over relay, src/server and xplane_plugin/subprojects/baton, so each crate reports as its own check.
  • fail-fast: false, so one broken crate does not hide the state of the other two.
  • cargo build then cargo test per crate.
  • Cargo registry and target/ cached per crate, keyed on that crate's Cargo.lock.
  • No toolchain named: rust-toolchain.toml at the repository root decides, once Issue #188 solved: rename rust-toolchain.toml so the pin takes effect #243 lands. Until then runners use their default stable, which is the behaviour today.

The relay step installs wayland, x11, drm, udev and fontconfig headers first. Its iced dependency tree needs them to build; the other two crates are plain std and skip that step.

About the check on this PR

This may well come back red, and that is the point.

Two tests fail on main on Linux (#251): a_slow_python_reader_does_not_pace_imotions and a_python_process_that_stops_reading_is_dropped_not_waited_on. Both assert on socket backpressure that never materialises when the kernel buffers are large enough to absorb the test's volume.

Whether they also fail on a GitHub runner is unknown — nothing has ever run them there. This PR is the first time anyone finds out:

Either way the result is information the project does not currently have. I would rather surface it than special-case those two tests to get a green check.

Scope

Deliberately limited to the Rust crates. Re-enabling the commented-out Meson test step and the commented-out Ubuntu job is a separate question for whoever owns the plugin build.

Nothing in CI touched the Rust side. meson-build.yml builds the C++
plugin on Windows with its test step commented out, and super-linter
lints YAML and clang-format. So relay, src/server and baton had no
automated coverage at all, which is how main came to be failing two
relay tests without anyone noticing (oss-slu#251).

Add a workflow that builds and tests all three crates on pull requests
and on pushes to main, as a matrix so each crate reports separately,
with fail-fast off so one failure does not hide the others.

The relay needs wayland, x11, drm and fontconfig headers because of its
iced dependency tree, installed only for that crate. No toolchain is
named: rust-toolchain.toml at the repository root decides, once oss-slu#243
lands. Cargo registry and target output are cached per crate, keyed on
each Cargo.lock.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

No CI builds or tests the Rust crates

1 participant