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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
