diff mbox

[U-Boot,1/2] travis-ci: set env vars to name jobs

Message ID 20161024224149.8520-1-swarren@wwwdotorg.org
State Accepted
Commit d7882210d3796a79a33da54a902b2a09a45f81d4
Delegated to: Tom Rini
Headers show

Commit Message

Stephen Warren Oct. 24, 2016, 10:41 p.m. UTC
From: Stephen Warren <swarren@nvidia.com>

Travis CI names sub-jobs after the first environment variable that is set
for a script. This doesn't produce meaningful results for any of the non-
buildman jobs. Add a dummy variable to give the jobs meaningful names.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
 .travis.yml | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

Comments

Tom Rini Oct. 24, 2016, 11:03 p.m. UTC | #1
On Mon, Oct 24, 2016 at 04:41:48PM -0600, Stephen Warren wrote:

> From: Stephen Warren <swarren@nvidia.com>
> 
> Travis CI names sub-jobs after the first environment variable that is set
> for a script. This doesn't produce meaningful results for any of the non-
> buildman jobs. Add a dummy variable to give the jobs meaningful names.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>

I'm not sure.  This un-does in part killing off TEST_CMD as a hook.  At
the end of the day, imho, what is important from travis-ci are the
emails it sends (which are starting and pass/fail/interrupted) and the
other notifications.

On the other hand it does seem to be common practice to do something
along these lines. So, in the end, I don't know.
Stephen Warren Oct. 24, 2016, 11:18 p.m. UTC | #2
On 10/24/2016 05:03 PM, Tom Rini wrote:
> On Mon, Oct 24, 2016 at 04:41:48PM -0600, Stephen Warren wrote:
>
>> From: Stephen Warren <swarren@nvidia.com>
>>
>> Travis CI names sub-jobs after the first environment variable that is set
>> for a script. This doesn't produce meaningful results for any of the non-
>> buildman jobs. Add a dummy variable to give the jobs meaningful names.
>>
>> Signed-off-by: Stephen Warren <swarren@nvidia.com>
>
> I'm not sure.  This un-does in part killing off TEST_CMD as a hook.  At
> the end of the day, imho, what is important from travis-ci are the
> emails it sends (which are starting and pass/fail/interrupted) and the
> other notifications.

I don't believe I've ever received emails from Travis, although I 
haven't used it in a while so perhaps it's a new feature.

Either way, I do like to look at the web UI to watch/check status 
sometimes, and certainly would after a failure to track down the 
problem, and this change makes the job list there possible to interpret, 
whereas it isn't without it:

https://travis-ci.org/swarren/u-boot/builds/170278972
Tom Rini Oct. 25, 2016, 12:20 a.m. UTC | #3
On Mon, Oct 24, 2016 at 05:18:24PM -0600, Stephen Warren wrote:
> On 10/24/2016 05:03 PM, Tom Rini wrote:
> >On Mon, Oct 24, 2016 at 04:41:48PM -0600, Stephen Warren wrote:
> >
> >>From: Stephen Warren <swarren@nvidia.com>
> >>
> >>Travis CI names sub-jobs after the first environment variable that is set
> >>for a script. This doesn't produce meaningful results for any of the non-
> >>buildman jobs. Add a dummy variable to give the jobs meaningful names.
> >>
> >>Signed-off-by: Stephen Warren <swarren@nvidia.com>
> >
> >I'm not sure.  This un-does in part killing off TEST_CMD as a hook.  At
> >the end of the day, imho, what is important from travis-ci are the
> >emails it sends (which are starting and pass/fail/interrupted) and the
> >other notifications.
> 
> I don't believe I've ever received emails from Travis, although I
> haven't used it in a while so perhaps it's a new feature.

Ah, https://docs.travis-ci.com/user/notifications#Email-notifications
explains and it's setup by default to not spam uninterested parties.
Which I think in turn means it also doesn't email interested parties
easily, sadly.

> Either way, I do like to look at the web UI to watch/check status
> sometimes, and certainly would after a failure to track down the
> problem, and this change makes the job list there possible to
> interpret, whereas it isn't without it:
> 
> https://travis-ci.org/swarren/u-boot/builds/170278972

Yeah, I spent a lot of time with the UI when I was doing the last
series.  And since it is indeed harder to get email notifications than I
would like, this makes sense too.

Reviewed-by: Tom Rini <trini@konsulko.com>
Tom Rini Oct. 29, 2016, 5:40 p.m. UTC | #4
On Mon, Oct 24, 2016 at 04:41:48PM -0600, Stephen Warren wrote:

> From: Stephen Warren <swarren@nvidia.com>
> 
> Travis CI names sub-jobs after the first environment variable that is set
> for a script. This doesn't produce meaningful results for any of the non-
> buildman jobs. Add a dummy variable to give the jobs meaningful names.
> 
> Signed-off-by: Stephen Warren <swarren@nvidia.com>
> Reviewed-by: Tom Rini <trini@konsulko.com>

Applied to u-boot/master, thanks!
diff mbox

Patch

diff --git a/.travis.yml b/.travis.yml
index d65c5705875f..a172180a9953 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -160,30 +160,42 @@  matrix:
 
     # QA jobs for code analytics
     # static code analysis with cppcheck (we can add --enable=all later)
-    - script:
+    - env:
+        - JOB="cppcheck"
+      script:
         - cppcheck --force --quiet --inline-suppr .
     # search for TODO within source tree
-    - script:
+    - env:
+        - JOB="grep TODO"
+      script:
         - grep -r TODO .
     # search for FIXME within source tree
-    - script:
+    - env:
+        - JOB="grep FIXME HACK"
+      script:
         - grep -r FIXME .
     # search for HACK within source tree and ignore HACKKIT board
       script:
         - grep -r HACK . | grep -v HACKKIT
     # some statistics about the code base
-    - script:
+    - env:
+        - JOB="sloccount"
+      script:
         - sloccount .
     # test/py
-    - script:
+    - env:
+        - JOB="test.py sandbox"
+      script:
         - ./test/py/test.py --bd sandbox --build
     - env:
+        - JOB="test.py ARM"
         - CROSS_COMPILE="/usr/bin/arm-linux-gnueabihf-"
       script:
         - ./test/py/test.py --bd vexpress_ca15_tc2 --id qemu --build;
           ./test/py/test.py --bd vexpress_ca9x4 --id qemu --build;
           ./test/py/test.py --bd integratorcp_cm926ejs --id qemu --build;
     - env:
+        - JOB="test.py MIPS"
         - TOOLCHAIN="mips"
           CROSS_COMPILE="${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/mips-linux/bin/mips-linux-"
       script:
@@ -192,10 +204,12 @@  matrix:
           ./test/py/test.py --bd qemu_mips64 --build -k 'not sleep';
           ./test/py/test.py --bd qemu_mips64el --build -k 'not sleep';
     - env:
+        - JOB="test.py PowerPC"
         - CROSS_COMPILE="/usr/bin/powerpc-linux-gnu-"
       script:
         - ./test/py/test.py --bd qemu-ppce500 --build -k 'not sleep'
     - env:
+        - JOB="test.py x86-64"
         - TOOLCHAIN="x86_64"
           BUILD_ROM=yes
           CROSS_COMPILE="${HOME}/.buildman-toolchains/gcc-4.9.0-nolibc/x86_64-linux/bin/x86_64-linux-"