Rosanswers logo


We have over time accumulated many different ros packages in a private repository. The code quality is varying and to cleanup the current situation (before potentially releasing some of the packages publicly) and to avoid such a situation in the future we would like to setup a continuous integrations system.

I saw that there are multiple "tools" related to this existing (bloom, buildfarm, jenkins_scripts, jenkins_tools). But all these seem to be tightly linked into some central ros infrastructure and not necessarily suitable for a private ros repository situation. I found a document REP 137 according to which our usecase should be supported (I am unsure if REPs describe targets or current situation).

So, to bring this down to one question: How do I easily setup a continuous integration system that builds packages in a private ros repository?

A few constraints in our case:

  • Support for fuerte and dry packages. [We are right now on fuerte using dry packages. In the mid term we will switch to groovy (or later) and wet packages. But it would be ideal to already have the continuous integration for the old setup to easy transition (e.g. did the switch break things or were the broken before?). If dry/fuerte is out of the question I am still interested in hearing about a solution for wet/groovy.]
  • Ability to find out about all packages in the repository and schedule them all as jobs (with predefined sub-jobs like build, run tests, cpp-check, ...) according to their dependencies. (If every package has to be dealt with individually one creates yet another place where dependencies have to be defined.)

Originally posted by dk on ROS Answers with karma: 176 on 2013-07-09

Post score: 5


1 Answer 1


Rosanswers logo

REP 137 only affects Groovy and later as well as wet packages only. Setting up a build farm for Fuerte and dry stuff will be quite an effort. I would not recommend doing that.

For Groovy (or later) and wet packages you can find a draft at http://www.ros.org/wiki/buildfarm but it might not be complete.

If you plan to release the packages anyway you should really consider using the existing ROS buildfarm for the job.

As soon as Hydro is released (and Fuerte is EOL-ed) the buildfarm will receive another update to fully implement the features specified in REP 137. This should make it even easier to run a custom buildfarm.


By running your own buildfarm you will get exactly the same functionality as the ROS buildfarm. Customizing it is a completely different thing. The ROS buildfarm does: packaging into Debian packages from gbp repos, integration build from the source repos includes running all tests, and doc jobs.

For setting up the buildfarm you do not have to configure dependencies etc. This is all done automatically. All jobs on jenkins.willowgarage.com are autogenerated - there is not a single manually configured job anymore.

Originally posted by Dirk Thomas with karma: 16276 on 2013-07-09

This answer was ACCEPTED on the original site

Post score: 6

Original comments

Comment by dk on 2013-07-10:
Thanks a lot for this answer. It helped me to avoid to waste a lot of time. We will wait until we have switched to groovy/wet. The documentation on the buildfarm page / the REP seems extremely sparse when it comes to my usecase (checking if things built, running tests, ... for a private repository).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.