Re: [Qemu-devel] [RFC] test/docker/Makefile.include: add a generic docker-run target

[Fam Zheng <famz@redhat.com>]

On Wed, 09/21 08:50, Alex Bennée wrote:
> 
> Fam Zheng <famz@redhat.com> writes:
> 
> > On Tue, 09/20 14:56, Alex Bennée wrote:
> >> This re-factors the docker makefile to include a docker-run target which
> >> can be controlled entirely from environment variables specified on the
> >> make command line. This allows us to run against any given docker image
> >> we may have in our repository, for example:
> >>
> >>     make docker-run TEST="test-quick" IMAGE="debian:arm64" \
> >>          EXECUTABLE=./aarch64-linux-user/qemu-aarch64
> >>
> >> The existing docker-foo@bar targets still work but the inline
> >> verification has been shunted into other target prerequisites before a
> >> sub-make is invoked for the docker-run target.
> >
> > Hi Alex,
> >
> > I understand sometimes one can have specialized images, but still: is it
> > possible to convert them to Dockerfile and include in the tree?
> >
> > Or, is this for testing/debugging purpose?
> 
> A bit of both. In this particular use case I'm using a debootstrap image
> while updating the binfmt_misc executable. Currently there is a 1->N
> relationship for debootstrap as we can bootstrap multiple architectures
> in different images. By splitting the docker-run from the expansions we
> give ourselves a little more flexibility for running stuff.
> 
> But I think it's also useful for testing/debugging. I wrote this up as I
> was trying to debug a Travis build failure with gcc-6 so I was
> generating lots of test images and wanting to build against those. I
> would also like to add a travis Dockerfile at some point but at the
> moment what exactly goes into one of those is a little opaque to me.

Thanks for clarifying, and I agree this feature is really nice in general.

> 
> >
> >>
> >> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >>
> >> ---
> >> NB: I dropped the awk magic that verifies the image exists before
> >> running. I couldn't get the thing to work in my shell so wasn't quite
> >> sure what it was doing.
> >
> > It was to allow "make docker-test" to skip debian-bootstrap image if it is not
> > there (e.g. when qemu-user not available).
> 
> Ahh ok. I got a little confused as the docker images command can filter
> things based on tag so maybe we can come up with a cleaner test?

For once it used a format option of "docker images" that isn't available on
RHEL 7, per requested I changed it to the unobvious awk test.

> 
> >
> > I'm not much too concerned about that though, since most of the time we will
> > use docker-FOO@BAR, for specific combinations, instead of docker-test for a
> > blanket coverage.
> 
> What does patchew use?

The general strategy of patchew is good coverage of both tests and images,
without multiplexing them which could make testing one patch infinitely long on
a simple minded tester.

For now, we have:

    docker-test-quick@centos6
    docker-test-mingw@fedora

And staging (pending because of some mysterious false positives):

    docker-test-quick@min-glib

I also plan to extend to centos7 and ubuntu in the middle term, and give cross
compiling for OSX a try in the long run (googling says it's technically
possible).

I haven't prioritied debootstrap for now, because arm is not too different than
x86 in terms of endianness and stuff, and qemu-user is probably much slower
than native compilers.

But still, BE images will be a compelling reason, if there comes one.

Fam