-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add modularity checks in CI #268
Conversation
I just wonder if the checks for the CI should be done by directly testing the examples. |
The thing is examples z_sub, z_query, and z_queryable don't return by themselves, they need to receive a 'q' through scanf |
In zenoh-python, we have a python script that spawns the things in parallel, writes to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @Mallets on this. Either on the examples or the z_client_test
.
Also, if I recall correctly, e.g. the queryable
example shall not compile if the feature is disable (being explicitly on misconfiguration at compile time instead of runtime). But all the others examples shall compile as work as expected, including the existing tests.
Otherwise, @p-avital approach seems the way to go.
1420795
to
e00ed6a
Compare
9e86cbb
to
4c7f141
Compare
Ok so I added a Python script to run the examples, write to their "stdin" pipes and check their outputs according to the compile-time feature configurations value. A bit of issues translating from my machine to the CI but it should be good now. |
e4b4bf4
to
e16a788
Compare
As the number of possible compile configuration evolve in 2^n, with n the number of configuration tokens, it will quickly become impossible to test them all manually. The goal with this automated check in CI is to: