From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bme6F-0005y3-7h for qemu-devel@nongnu.org; Wed, 21 Sep 2016 05:45:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bme6A-0003fu-4y for qemu-devel@nongnu.org; Wed, 21 Sep 2016 05:45:54 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:37696) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bme69-0003eV-23 for qemu-devel@nongnu.org; Wed, 21 Sep 2016 05:45:50 -0400 Received: by mail-wm0-f51.google.com with SMTP id b130so81364127wmc.0 for ; Wed, 21 Sep 2016 02:45:48 -0700 (PDT) References: <20160920135616.2215-1-alex.bennee@linaro.org> <20160921040901.GC20653@lemon> <87lgylbsj1.fsf@linaro.org> <20160921081018.GA10804@lemon> From: Alex =?utf-8?Q?Benn=C3=A9e?= In-reply-to: <20160921081018.GA10804@lemon> Date: Wed, 21 Sep 2016 10:44:46 +0100 Message-ID: <87k2e5bn8x.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] test/docker/Makefile.include: add a generic docker-run target List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: qemu-devel@nongnu.org Fam Zheng writes: > On Wed, 09/21 08:50, Alex Bennée wrote: >> >> Fam Zheng 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 >> >> >> >> --- >> >> 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