From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexander Graf Date: Tue, 22 Nov 2016 00:15:50 +0100 Subject: [U-Boot] [PATCH v2] travis: Add efi_loader grub2 test In-Reply-To: <20161121223106.GH2546@bill-the-cat> References: <1479471480-164355-1-git-send-email-agraf@suse.de> <3632a05a-0759-84e9-d7fa-6da8d3e69994@wwwdotorg.org> <20161121223106.GH2546@bill-the-cat> Message-ID: <5f85260f-ad5d-2483-332f-e3dc08ae4e21@suse.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 21/11/2016 23:31, Tom Rini wrote: > On Mon, Nov 21, 2016 at 03:21:43PM -0700, Stephen Warren wrote: >> On 11/18/2016 05:18 AM, Alexander Graf wrote: >>> We have all the building blocks now to run arbitrary efi applications >>> in travis. The most important one out there is grub2, so let's add >>> a simple test to verify that grub2 still comes up. >> >>> diff --git a/.travis.yml b/.travis.yml >> >>> @@ -45,6 +48,9 @@ install: >>> - virtualenv /tmp/venv >>> - . /tmp/venv/bin/activate >>> - pip install pytest >>> + - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal echo lsefimmap lsefi lsefisystab efinet tftp minicmd >>> + - mkdir ~/grub2-arm >>> + - ( cd ~/grub2-arm; wget -O - http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm | rpm2cpio | cpio -di ) >> >> Do we really want to do this for all the build-only jobs too? I >> might have expected to do this inside the test scripts that actually >> use those binaries. > > So, it's the difference between making various jobs / stanzas more > correct vs taking more time to do stuff. Unless this starts to push the > "catch-all" arm job over the time limit, I don't think it's a big deal > either way. And since travis-ci will tell us how long a given stanza > takes we'll have a good idea pretty quick on if that's starting to take > too long. That said, I don't have a strong opinion here and it wouldn't > be too hard to move all of this into being under the TEST_PY_BD check > and since we aren't relying on apt, it's not going to be time-in-apt > factor. If we move it into TEST_PY_BD, we would either run the same sequence over and over again for individual tests or check if the file exists inside the generation path. Either way, it will get less readable :). Overall, we're talking of 1s of build time for this: https://travis-ci.org/agraf/u-boot/jobs/177000864 so I'd definitely prefer to keep it simple rather than optimized. Alex