Fam Zheng <f...@redhat.com> writes:
> On Wed, 09/21 08:50, Alex Bennée wrote:
>> Fam Zheng <f...@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.ben...@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
> a simple minded tester.
> For now, we have:
> And staging (pending because of some mysterious false positives):
> 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
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
> 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.