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.
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.)
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,..
recently CI (bashing?) seems to be major topic here 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.
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.
Yeah, I perfectly understand ... I don't really _like_ Jenkins for its Java "dependencies", too
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
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!
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 ...