Some Travis CI machines have 32 CPUs. This sets our concurrency level to 33.
Travis CI kills our buildtest for obvious reasons.
This PR limits the concurrency level to 8 on Travis CI.
It can happen that two PRs don't interfere with each other in the sense
that they hurt automatic rebasing, but still do not work together. The
prime example is PR1 changes the API of some function that PR2 uses. If
PR1 is merged, and PR2 is not rebased before merging, the error might
get unnoticed before the next build. Travis CI would have have told both
PR1 and PR2 are fine, but will complain (rather unnoticedly) that our
master does not compile.
This PR automatically rebases the PR on top of the current master,
before running the tests. If the automatic rebase fails, then this is
fine, because you will need to manually rebase again before merging,
anyway. The manual rebase, i.e. new push, will trigger Travis CI.
So, the main idea of this PR is that to can hit the "Restart Build"
button in Travis CI before hitting the merge button in Github.
pkg/ Makefiles based on `Makefile.git` fail in Travis when attempting to apply patches with `git am` because no committer info is set.
This patch adds a dummy Travis username and mail in the 'install' step to satisfy git.
This PR adds the basic integration for [Travis CI][tci].
The config file `.travis.yml` tells the server to setup the basic build
system, and run `compile_test.py`. If not all examples and tests could be
built, then the Travis CI integration adds a warning to "merge" button on
the bottom of the Github page.
Of course this integration makes little sense until #1049 is resolved,
because new bugs and old bugs cannot be told apart. Also (of course)
only because everything still builds, a PR still can intruduce a
multitude of runtime errors.
This integrations is meant to work additionally to our Jenkings. Users
can activate the test in their own RIOT forks to run the test before
opening a PR to master.
[tci]: https://travis-ci.org/
