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

["Alex Bennée" <alex.bennee@linaro.org>]

Fam Zheng <famz@redhat.com> writes:

> 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).

FWIW we already have some coverage of the MacOSX builds via Travis
(although being able to run it quickly on a dev system would be useful).

>
> 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.

It is much slower although qemu-user can at least take advantage of all
those extra cores on your server ;-)

32 bit builds are also an area that needs good coverage as I'm pretty
sure most devs have only x86_64 boxes these days.

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


--
Alex Bennée