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