Rosanswers logo

I'm following custom_rosdistro.rst#add-on-fork and this ros-sig-buildfarm thread about using the custom rosdistros

list that additional distribution file after the "normal" one in the index.yaml

in rosdistro/index.yaml is this adding a second jade: entry like:

    distribution: [indigo/distribution.yaml]
    distribution_cache: http://repositories.ros.org/rosdistro_cache/indigo-cache.yaml.gz
    distribution: [jade/distribution.yaml]
    distribution_cache: http://repositories.ros.org/rosdistro_cache/jade-cache.yaml.gz
    distribution: [jade/addon_distribution.yaml]
    distribution_cache: http://ros-build-farm-repo/rosdistro_cache/jade-cache.yaml.gz
type: index
version: 3

Or add duplicate entries for all of the distributions? Or don't have the extra 'jade:', just add another distribution and distribution_cache directly under the other two?

To my addon_distribution.yaml I added:

- custom 

Do I need to refer to this anywhere else? Will the tag become prominent in jenkins?

I created an import_jade.yaml like suggested and put it into my forked buildfarm_deployment_config:

        ensure: 'present'
        content: |
            name: ros_bootstrap
            verify_release: blindtrust
        ensure: 'present'
        content: |
            name: backfill-ros
            method: http://packages.ros.org/ros/ubuntu/
            suites: [trusty]
            component: main
            architectures: [amd64, source]
            filter_formula: Package (% ros-jade-* )

Some sources suggested it should go into /home/jenkins-slave/workspace, but I think reprepro_config is easier to get to jenkins when setting the job parameter.

If you want to maintain and use your custom version of the rosdep database included in the forked rosdistro repository you have to perform the following changes:

I don't want more maintenance, but do I have to in order to do the add-on fork? How do my custom packages get into the rosdep database if I don't modify it? Otherwise what is the basis for making this decision beyond the additional work/further divergence from upstream files?

After forking the repository you must update the URLs to your custom locations for each distribution:

Is this just for my one addon_distribution entry like shown above, or every distribution_cache in that list needs an updated url to point at my local repo machine?

Every user must set an environment variable on the machine to use the custom rosdistro database:

Does this matter within the virtual environment on my repo machine, the master or the slave? Or just users elsewhere?

Note if you're overlaying you need to add a rodep file for the underlayed rosdistro if using one: https://github.com/mikepurvis/rosdep-generator

Is overlaying different than add-on forking? Does it interact with the choice above to have a custom rosdep database?

So far after going through the above steps with the above assumptions I can generate_all_jobs.py on my custom ros_buildfarm_config index.yaml, and it completes without error. The next thing to do is import_upstream, which is now in jenkins, so I went there, clicked 'Build with Parameters' and edit the config_file text entry box to use import_jade.xml (Which does exist). I then see a message pending--There are no nodes with the label 'building_repository'

Many of the other jenkins jobs are getting triggered and failing repeatedly, one prominent error is that some of them are try to get packages from my repo (after looking for others at archive.ubuntu.com), but because nothing has been built yet or other components are misconfigured that fails, and the rest of the job is never gotten to.

Originally posted by lucasw on ROS Answers with karma: 8729 on 2016-03-03

Post score: 1


2 Answers 2


Rosanswers logo

For the first quiestion about index.yaml, you cannot have duplicate entries in the dict. You would want to have myproject-jade or something like that to differentiate your packages from the mainline ones. Note that to extend jade you should add to the list of distribution files not add a new entry.

For the reprepro_config's your location is fine. They just need to be consistent enough for you

You don't have to use a custom rosdep database. That's only necessary if you want to be able to support injecting your own non-ros packages as dependencies.

The custom rosdistro paths should be dealt with on the buildfarm from the config files. That should only require customization for the end users/ non-buildfarm machines.

The repo machine should be running and connected to the jenkins instance as a slave named building_repository so that it can execute all the jobs. You should review the deployment docs to make sure you have all 3 types of machines deployed correctly: https://github.com/ros-infrastructure/buildfarm_deployment

We haven't fully defined the overlay term. docs for addon and rosdep rules can be found here: https://github.com/ros-infrastructure/ros_buildfarm/blob/master/doc/custom_rosdistro.rst

Note creating a separable questions is usually more effective on this forum. (If there are related questions cross linking can help give context, but try to keep them self contained) I've tried to answer as much as I can but iterating it back and forth between a list of questions and a list of answers can be hard to follow when reading later.

Originally posted by tfoote with karma: 58457 on 2016-03-04

This answer was NOT ACCEPTED on the original site

Post score: 1

Original comments

Comment by lucasw on 2016-03-04:
I've been going through the ros-sig-buildfarm messages and it looks like that is better suited to multiple question dumps because it supports inline answering (and is more likely to reach a focused audience of already knowledgeable people instead of the subset also monitoring questions here).

Comment by lucasw on 2016-03-04:
distribution: [jade/distribution.yaml, jade/addon_distribution.yaml] distribution_cache: http://ros-build-farm-repo/rosdistro_cache/jade-cache.yaml.gz (overwrite the previous distribution_cache entirely since it is not a list)


Rosanswers logo

pending--There are no nodes with the label 'building_repository'

This was the result of a misconfigured repo/common.yaml (one of the ssh keys wasn't consistent with the master/common.yaml jenkins::private_ssh_key).

Upon trying to run reconfigure.bash repo a couple of times it looked like the change wasn't working. I ended up doing this on the repo machine:

rm -rf /var/log/puppet.log  # Just to get a clean log, not necessary
sudo deluser jenkins-slave
sudo rm -rf /home/jenkins-slave
sudo su
./reconfigure.bash repo

And now I have a 'building_repository' build executor on my master jenkins server. I also reran reconfigure on the master and slave several times, so I'm not 100% sure cleaning out jenkins-slave on the repo was the entire solution.


I encountered some issues where simply deleting jenkins-slave did not do enough- trying to run reconfigure did not recreate the jenkins-slave home directory. I ended up reinstalling ubuntu 14.04 server on the same repo vm instance and starting from scratch (and cloned the vm prior to making changes to save a little time if this step needed again).

Originally posted by lucasw with karma: 8729 on 2016-03-04

This answer was ACCEPTED on the original site

Post score: 0


Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.