exhausted Travis

Dear hard-working Developers,

I just wanted to share with you the chart in [1] with the caption “Active Linux Builds for Open Source Projects (GCE)”

All our current jobs are build on that infrastructure and looking at the chart: travis is pretty flat-lining. It seems that there are more jobs available than builders and there is nothing that we can do about that.

I once tried to move our jobs to the container based infrastructure, but this requires to remove all “sudo” operations that we currently have in our travis script. Unfortunately, certain compilers are not in the default Ubuntu 12.04 repository (or are outdated), therefore we would need to download/build all compilers by hand. That’s the point where I failed.

Do you think it makes sense to invest some time into bringing our jobs to the container based infrastructure, or should we just wait until we hit the next great invention (Kaspar (; ) ?

And btw. to clarify things: 1 job is not a pull request in the queue. We currently have 11 jobs per pull request (: And we still need to share all those builders with other open source projects.

Best, Cenk `` [1]

Have you looked at CircleCI? This seems to be the rage for IETF repos at this point. (ISTR I couldn't get it to work for my repos, but I probably just didn't try hard enough.)

Grüße, Carsten

Hey,

The KasparCI will be ready soon :wink:

Hello Carsten,

Thank you for the hint. CircleCI looks nice, but its free plan includes only one (concurrent) build at a time. I think this won't help much in our case (: Currently, we have about 11 jobs that need to be processed before one pull request can be marked as "checked". And each job takes about 40 min to complete on travis (worst case).

We definitely have a lot of room for improvement, like grouping common tests into one test binary, omitting similar boards for certain tests,..

@all: Do we need a CI-TaskForce?

Best, Cenk

Hi all,

recently CI (bashing?) seems to be major topic here :wink: And as a result, some people are working on bringing up a new (homegrown) CI environment for RIOT. However, from what I read in the wiki there was a (working?) Jenkins-CI setup for RIOT in the past, before using/switching to Travis - what happened?

I mean, currently we are talking about setting up a dedicated RIOT-CI - again. Why not revive or start using Jenkins, maybe someone can enlighten me?! However, I think Cenk has a point here:

@all: Do we need a CI-TaskForce?

At least it should be defined what are the requirements on a _RIOT-CI_ - mandatory features - nice-to-have stuff - possible CI frameworks

For the latter I would rather opt for some well-known implementation, that easily scales to multiple machines. Though Jenkins supports this and has plugins for virtually everything, it is a huge bulk of software and might not be the best fitting CI for RIOT.

Briefly said: (IMHO) its no wonder that a free CIs such as Travis cannot handle RIOT with its ever growing community, highly active and dynamic development.

Best Sebastian

Hey,

I mean, currently we are talking about setting up a dedicated RIOT-CI - again.

Yes... The last CI guy moved on to other things, unfortunately before getting to a usable state.

@all: Do we need a CI-TaskForce?

I guess we implicitly have people working on it, so yeah, let's formalize.

At least it should be defined what are the requirements on a _RIOT-CI_ - mandatory features

- builds RIOT - fast - stable - github-integration

- nice-to-have stuff

- run tests on real hardware

- possible CI frameworks

For the latter I would rather opt for some well-known implementation, that easily scales to multiple machines. Though Jenkins supports this and has plugins for virtually everything, it is a huge bulk of software and might not be the best fitting CI for RIOT.

I'm about to introduce a simple homebrew solution. The code is here [1], but it doesn't have setup instructions, yet.

Kaspar [1] GitHub - kaspar030/murdock: A simple CI (continuous integration) server written in Python

Hi Sebastian,

Hey Martine, Hi all,

Hey,

Yeah, I perfectly understand ... I don't really _like_ Jenkins for its Java "dependencies", too :wink: All in all it works like charm, they even use Github integration ... somehow ... but I know they have some trouble with that, too.

That was my feeling with the available systems.

I'm using buildbot a lot for CI for one of my clients, and it's a bitch to customize. I've set up strider a while ago, but at some point it didn't do what we need, and bam! you have to sip through a nightmare forest of node.js code.

After that experience, I thought, all we need is something that watches github and then queues builds, spawning a script to build stuff. Can't be that hard. So I write something from scratch. It is now a little less than 600 lines of python code, and works like a charm, with perfect github integration.

I'd say it is easily customizable, but ask me again after I've added support for distributed builds...

IMHO a master-slave concept (as in Jenkins) with ability to add worker nodes ... zzZzZZ ... Sweet dreams :slight_smile:

We're close! :wink:

Kaspar

I'd say it is easily customizable, but ask me again after I've added support for distributed builds...

Sounds more like fun :wink:

Hi Kaspar, Adam, Nick, Cenk, Sebastian (and everyone else who offered her/his help here)!

>> @all: Do we need a CI-TaskForce? I guess we implicitly have people working on it, so yeah, let's formalize.

I agree that this sounds like a good idea. I added an entry to the wiki page [1]. So, we need two persons who would volunteer to shepherd this task force. Kaspar, for starters, I listed you as a shepherd, please change this, if you don't want to lead this task force.

Finally, I wanted to thank all of you who offered help or already contributed (in terms of hardware resources, manpower, and consulting) for this badly needed improvement! It's (once again) great to see the power and helpfulness of this community. Big thanks!

Cheers, Oleg

[1] Task Forces · RIOT-OS/RIOT Wiki · GitHub

Hey all,

+1 for CI task force

I'll be happy to contribute and help on this topic, for starters I created an initial wiki page and added some content [2]. Feel free to add and modify ...

Best, Sebastian

Hey,

seems like you don't like RIOT CI?

Kaspar

Hi back,

Hey,

seems like you don't like RIOT CI?

No hard feelings -- However, IMHO we have to define (and find consensus on) basic requirements of a future RIOT-CI, first.

Cheers,   Sebastian

Hiho Kaspar,

   the ultimate goal is to do this best.

   If smlng can improve, that's fine. If not, you can blame him.

   In any case: Critical questions are always welcome.

Cheers,   thomas