ros-infrastructure / ros_buildfarm_config

ros_buildfarm_config

The configuration for the ROS buildfarm available under http://build.ros.org.

The master branch is from where we run our testing farm and is the recommended place to fork from.

The production branch is what we actually run on http://build.ros.org Please do not fork from that version as it does things like turn on maintainer emails which are not appropriate for a private fork. Doing that will cause maintainers to get emails both from the main buildfarm run by OSRF, as well as duplicates from any private buildfarm which is running.

The two branches should be maintained as closely as possible.

To deploy a custom buildfarm using this configuration you might want to use the ros_buildfarm repository.

Contributing guidelines

Branch hygiene

Be careful about which branch you fork from and submit a pull request to.

If you are contributing a configuration change (e.g. changing the values of keys) to be deployed on build.ros.org, make a pull request to the production branch.

If you are contributing a change to be deployed on the testing farm or a more structural change, make a pull request to the master branch.

Guide to blacklisting packages

If you wish to blacklist a package on build.ros.org, submit a pull request to production doing the following:

Find the release-build.yaml file which is appropriate for the platform you wish to blacklist your package for under the folder for the appropriate distribution.

For example, if you want to blacklist a package on 32-bit ARM in Kinetic Kame, you want to edit the file kinetic/release-armhf.build.

Add the name of the package in alphabetical order to blacklist under the entry package_blacklist, e.g.

  package_blacklist:
    - my_blacklisted_package

When you submit a pull request, please link to an upstream ticket in your pull request to blacklist the package so that there is somewhere to track whether the issue has been resolved and the blacklist entry can be removed.

If you never want your package to be unblacklisted, you don't need to do this, but if you are waiting on a system dependency to be released or updated, then you should state that in the ticket/in your pull request and, if you can, link to an external issue tracker related to the problem.

ros_buildfarm_config's Issues

change / document branches

It is rather intuitive that the default branch is not the one being used. The existence of the production branch is neither visible nor discoverable to users.

Please either:

• document the production branch in the README on the master branch and in a CONTRIBUTING file or
• (much preferred) rename the master branch to testing and production to master

Please upgrade the Vivid repo for the current buildfarm

I know, I know, it's not even released yet so feel free to discard but you'll have to do it at some point :)

I am tracking a weird bug and trying on as many configs as possible. The current Vivid on the farm is really our of sync and that forces me to recompile the whole ROS (because of log4cxx and OpenCV issues). Thx

Otherwise, please upgrade at a strategic moment: https://wiki.ubuntu.com/VividVervet/ReleaseSchedule (if not Alpha2, Beta1 ?)

Consider removing master branch and changing default branch to production

Hi,

Right now, the default branch is master which hasn't been updated in a couple of years. It looks like production is what's being used. As the non-default branch, it looks like this repo isn't active since master hasn't been updated in several years.

I suggest deleting that branch and having production be the default branch so that its clear and PRs are automatically targeting the intended branch

blacklist a package build for a Ubuntu distro

I want to blacklist a package for a Ubuntu distro (all saucy builds of my packages for example, since saucy is EOL)...
Is there a way to do this ?

The readme describe only how to blacklist a package for a target platform for a ROS distro.

change job priority of ARM jobs

Since ARM jobs take a lot of time they tend to block other jobs from running for days. I would suggest we give them a lower priority then all other job types. Basically only let them run when the build farm has no other jobs to run.

extend doc jobs to support job_weight parameter

The rosindex job needs the oversized memory machines. This works fine right now if the machine is mostly idle. But tonight I merged several packages during the rosindex run and I believe that it ran out of memory just before it finished.

I manually changed the doc_rosindex to use job_weight: 4 which will guarentee that the job has a dedicated executor

But that manual change won't persist. We'll need to add the parameter to the config here and to ros_buildfarm to know how to parse it and inject it.

update sync limits

@wjwwood Jade needs a significantly higher sync limits:

• ros_buildfarm_config/jade/release-build.yaml

  Line 15 in b174c88

  package_count: 140

• ros_buildfarm_config/jade/release-armhf-build.yaml

  Line 75 in b174c88

  package_count: 140