[U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/21/2016 04:15 PM, Alexander Graf wrote:
>
>
> 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 :).

I believe each test job configures a new container, so no, the change I 
suggested would mean a given job would either:

a) Run a build without downloading the test EFI RPM.

b) Run a test and download the EFI RPM once.

It seems trivial to just put this in the right place, although 
admittedly if it's quick it's not going to save much, except that it 
will make all the compile-only tests not depend on so many 
potentially-intermittent network accesses.

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