-
Notifications
You must be signed in to change notification settings - Fork 167
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
running upstream project tests via kola? #1176
Comments
Oh I forgot to add...I had short discussions with @jlebon about finding a generic way for running these kinds of upstream tests via |
Do we want/need these to be added to Here's some miscellaneous thoughts I've had on the subject of external tests in Ideally I'd like to avoid adding more vendor bloat to Another thing for running non-native My personal opinion (if we want to add these into Definitely open to hearing other alternatives. cc @bgilbert for other opinions |
We haven't generally had kola tests which wrap other test suites. We probably shouldn't build many tests of that kind, but it might make sense to do so in some cases. Pulling and running a container seems like the obvious way to implement them. I agree that vendoring tests directly into mantle doesn't seem great. |
Yeah, regardless we should probably at least have a basic invocation of e.g. One high level thing to keep in mind here is that since we now have two streams, that makes everything at least...four times more complicated =) Since we have to think about versioning a lot more. Additional complexity here is that rpm-ostree is used by other projects in Fedora too. So..... One approach would be for us to reuse kola's provisioning/teardown bits, and have it write out the ssh connection information (as a ssh-config file e.g.) and then something higher level can reuse that to execute other test suites. |
|
I think this is fixed by #1252 |
kola: Remove Distros{fcos,rhcos} from tests - it's the default
The
ostree
andrpm-ostree
projects have a robust set of tests that could be used to validate functionality on RHCOS/FCOS. Specifically, the vmcheck tests ofrpm-ostree
are such that they can be run against a VM which has anrpm-ostree
daemon running.While experimenting running these tests against RHCOS (without using
kola
), I ran into a few snags that made me question how the integration of the tests intokola
might work.The upstream tests can change with each release/commit, so
kola
would have to perform a checkout of the repo which matches the version of software under test. I didn't find any other examples of this kind of approach in the current codebase. Obviously, this doesn't mean we can't adapt, but I wanted to get a feel if this kind of approach would work out.I found the
vmcheck
suite has a decent amount of dependencies that need to be installed on the host running the test.kola
doesn't really have this problem, as it is just a golang binary after it is all compiled etc. Would this requirement on certain packages get pushed up to a higher layer to handle?The alternative to installing packages on the host running the test would be to pull a container with the required dependencies and execute the tests via the container, via
kola
. I'm not sure this is a better solution than what would be required for point 2.The extreme alternative is to punt on the upstream tests and re-implement some of the tests natively in 'kola`.
Maybe I'm getting ahead of myself with these kinds of questions, but I figured the folks more experienced with this codebase would be able to steer me in the right direction.
The text was updated successfully, but these errors were encountered: