as most of you know, we switched from Travis to Murdock as the _official_ RIOT-CI a while ago. However, legacy scripts and configuration files for Travis are still around in the latest RIOT master branch - but with time passing by these will get (or already are) outdated. PR #5855 [1] is an attempt to remove all Travis related files and migrate whats necessary to Murdock.
CAVEAT: such decision will affect those of you who use Travis-CI for their private RIOT fork. Thus, please add your comment and/or opinion on that matter to the discussion in #5855. If Travis is not required anymore, we may safely remove related files. On the other hand, if Travis is still used, we can close #5855 but also need volunteers to maintain Travis' config and scripts.
Note: as an alternative RIOT currently provides a Drone-CI configuration [2,3], too - added (and maintained?) by @gebart.
Dear developers,
Even though the official CI system is the Murdock server maintained by
Kaspar, it is not entirely clear what scripts are being run and in
what order. With the Travis and Drone scripts it is still possible to
run the same tests directly on your own PC without creating a PR. This
is perhaps especially useful for private projects and for
non-maintainers who don't have the required access permission on
Github to add the Ready for PR label, which is what triggers a Murdock
build.
Instead of removing it, I would like to see the script updated (and
renamed) to match what tests are actually performed by Murdock. This
way we can run the same tests as Murdock on our PCs. Drone also
provides a command line interface which makes it easy to run the tests
locally, simply run "drone exec" from the directory containing the
.drone.yml and the tests will be run locally instead of on a CI
server, and using the exact same environment (Docker image) as would
be run by the CI server. Migrating the test steps from Murdock to the
RIOT repo also makes it easy to use any other CI system, for example
when a company already has existing CI infrastructure such as Jenkins.
I can volunteer maintain the Drone YAML file, it's not a complex file
and the rate of changes upstream in the server is going to be less in
the future as the Drone project matures.