Travis Backlog

Dear Developers,

This is a friendly reminder that we should take more care of our travis backlog.

Everytime a pull request gets rebased/squashed/new commits travis will enqueue a new task. This enqueing takes up space in the travis backlog and hinders us from getting quick feedback about important pull requests, which are basically ready to merge.

I know that everyone loves to see her/his pull request checked by travis as soon as possible as means of a smoke test, but this "first check" can almost always be done by compiling locally!

So please follow these two steps: 1) If your pull request has commits with a message      that includes "SQUASH" or "FIXME" then travis will fail      anyways. So why let it enqueue at the first place?      Please use "[ci skip]" somewhere in your commit message      if this is the case. Travis will ignore a pull request if the last commit      message has "[ci skip]" somewhere in it.

2) (Maintainers only) If you notice several jobs in Travis for the same      pull request, then please take the initiative and stop old jobs      for obsolete commits.

I also know that it's sometimes inevitable, especially when the pull request was already squashed and is basically ready to merge, but another small remark forces us to commit/amend a change. (This often happens at hack'n'acks) If a maintainer is involved in this, then again, a pointer to 2), cancel jobs for obsolete commits.

Take a glance at our current travis backlog [1]. The queue is still full from yesterday's hack'n'ack session, and that was about 8-9 hours ago.

Develop cautiously!



Hey Cenk!

Thanks for this very important reminder!

Cheers, Oleg


Some tears came out of my eyes when reading this message, I never gave any thought to the T-guy, lots of pressure on him and nobody but you took care of this…

Thanks and next time we can try to be aware of this problem.



Would it be an idea to add a make commando to run most off the tests that travis runs? Like the static tests and different board builts, or a sub set.

It would be great if this could be run from the RIOT root directory. :slight_smile:


I’m second to Nick’s sugestion. Nice to have ‘make’ to run unit tests and compile examples.

Vào 19:00 Th 4, 02 thg 3 2016 DipSwitch <> viết:


do you mean

BUILDTEST_MCU_GROUP=foobar ./dist/tools/travis-scripts/

(BUILDTEST_MCU_GROUP can be chosen from .travis.yml)? That’s exactly the script that Travis is using. You can also run make buildtest to build a single application for all boards and the unittests can be executed with make all test.

Cheers, Martine

Hello Martine,

IMHO, make all the test (unit tests, compile with set of mcus) should be simple in localhost so that we can run it more frequently. Then how about single make command for all equivalent travis tests?


Vào Th 4, 2 thg 3, 2016 vào lúc 21:30 Martine Lenders <> đã viết: