[CRIU] [PATCH] tests: add a runc based test

Adrian Reber areber at redhat.com
Wed Jul 25 09:03:25 MSK 2018


On Tue, Jul 24, 2018 at 10:26:03PM -0700, Andrei Vagin wrote:
> On Wed, Jul 18, 2018 at 10:23:55PM +0200, Adrian Reber wrote:
> > Is this a better runc test setup? It is a bit hacky to get the runc
> > test suite running standalone as it can be seen in my patch.
> > 
> > So should we rather use the this approach or my older approach with our
> > own runc test setup?
> > 
> > I liked the previous a bit better, but this also works for me.
> > 
> >
> 
> Look at this
> https://github.com/avagin/runc/commit/fbe69e8b5c68bb52b48dfaa43b80ce693fe3da2f
> 
> I'm thinking about the idea to have a separate repo to run additional
> tests in travis-ci.
> 
> I spent a few minutes and create the "ideal" runc test. Mr Travis allows
> tuning a job to execute it once a day. Yes, it will not be executed for
> each patch, but I think our current travis test suite is too big
> already.

Right, it takes sometimes over 4 hours which really seems too long. So
something like a minimal test on each supported architecture after each
push or something like that. And once a day a full test run.

Would patchwork still do the full test suite run?

> I am not sure whether it is the good way to run runc tests.
> What do you think?

For me this are two questions. Splitting the travis testing and how we
integrate the runc test.

About your changes to use the runc test suite: This runs the complete
runc test suite which might not be what we are interested in. At least
we are not interested if there are other failures in the runc test suite
which are CRIU unrelated.

I kind of like the idea of a faster result from travis. Before
submitting a patch I usually do a push to my github CRIU clone for a
travis run on my repository. If I could get the result faster, I think I
would like that.

		Adrian


More information about the CRIU mailing list