Message ID | 20161024224149.8520-1-swarren@wwwdotorg.org |
---|---|
State | Accepted |
Commit | d7882210d3796a79a33da54a902b2a09a45f81d4 |
Delegated to: | Tom Rini |
Headers | show |
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.
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
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>
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 --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-"