containers / youki

A container runtime written in Rust

Home Page:https://containers.github.io/youki/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Packaging youki for openSUSE: How to disable the tests that need dbus?

johanneskastl opened this issue · comments

I am trying to package youki for openSUSE, where the builds are executed in a limited environment without internet connectivity. In addition, there is no dbus running inside the build VM.

Hence some of the tests fail:

> [  830s] 
> [  830s] failures:
> [  830s] 
> [  830s] ---- systemd::dbus_native::dbus::tests::test_dbus_function_calls stdout ----
> [  830s] Error: DBus(ConnectionError("ENOENT: No such file or directory"))
> [  830s] 
> [  830s] ---- systemd::dbus_native::dbus::tests::test_dbus_connection_auth stdout ----
> [  830s] thread 'systemd::dbus_native::dbus::tests::test_dbus_connection_auth' panicked at crates/libcgroups/src/systemd/dbus_native/dbus.rs:475:9:
> [  830s] assertion failed: conn.is_ok()
> [  830s] note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
> [  830s] 
> [  830s] ---- systemd::dbus_native::dbus::tests::test_dbus_function_calls_errors stdout ----
> [  830s] thread 'systemd::dbus_native::dbus::tests::test_dbus_function_calls_errors' panicked at crates/libcgroups/src/systemd/dbus_native/dbus.rs:528:69:
> [  830s] called `Result::unwrap()` on an `Err` value: DBus(ConnectionError("ENOENT: No such file or directory"))
> [  830s] 
> [  830s] 
> [  830s] failures:
> [  830s]     systemd::dbus_native::dbus::tests::test_dbus_connection_auth
> [  830s]     systemd::dbus_native::dbus::tests::test_dbus_function_calls
> [  830s]     systemd::dbus_native::dbus::tests::test_dbus_function_calls_errors
> [  830s] 
> [  830s] test result: FAILED. 134 passed; 3 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.55s

Is there a way to disable or ignore just those three tests when running cargo test?

Kind Regards,
Johannes

Thanks for your feedback and effort. There isn't a good way to avoid such a case for now. We have to check if your environment supports Dbus or not.

cc: @YJDoc2

Hey, as said currently there is no way to skip specific tests unless you directly invoke cargo test with some test filter.


@utam0k we can potentially support the test skipping here, similar to how we have done for runc in contest. So if SKIP_DBUS_TEST is set, we can skip these or so.


@johanneskastl , can you give me some more details about the build process / what are you planning to do, i.e. just checking if packaging work, or have a custom ppa-like thing where you are planning to distribute this build etc? Also if there is no specific need to run tests, you can directly use a release tag, as we make sure tests are passing when tagging a release.

@utam0k we can potentially support the test skipping here, similar to how we have done for runc in contest. So if SKIP_DBUS_TEST is set, we can skip these or so.

+1

Hey, as said currently there is no way to skip specific tests unless you directly invoke cargo test with some test filter.

And how would that test filter look like?

The macro used for starting the tests is based on cargo test with some options anyway, maybe I can just add some more?

@utam0k we can potentially support the test skipping here, similar to how we have done for runc in contest. So if SKIP_DBUS_TEST is set, we can skip these or so.

That would be great!

@johanneskastl , can you give me some more details about the build process / what are you planning to do, i.e. just checking if packaging work, or have a custom ppa-like thing where you are planning to distribute this build etc? Also if there is no specific need to run tests, you can directly use a release tag, as we make sure tests are passing when tagging a release.

Basically it is good practice to check that the binary that we build passes the tests. That is not always possible in toto, due to the environment there might be some tests that can not work and thus are skipped/ignored.

I'll try to find a good explanation of the build process in the OBS / Open Build Service. But basically a worker node spawns a new VM via qemu with the target OS and builds the package in this VM, which is then discarded. This VM is just the bare minimum, so there is no dbus available in this VM (AFAICT).

@johanneskastl Do you have a plan to contribute to youki implementing of this one? To be honest, we don't have a strong motivation to support it, but it would be acceptable.

@utam0k we can potentially support the test skipping here, similar to how we have done for runc in contest. So if SKIP_DBUS_TEST is set, we can skip these or so.

Hi @utam0k I have no knowledge of Rust, but if I find time I might try to understand the logic and copy from other examples.