Open johanneskastl opened 5 months ago
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.
Would a simple
if env::var("FOO").is_some() { return; }
do it or do we need something more complicated?
If possible, it'd be nice if we'd like to realize that the test has been skipped.
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:
Is there a way to disable or ignore just those three tests when running cargo test?
Kind Regards, Johannes