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