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