On Fri, Sep 6, 2013 at 12:10 PM, Edwards, Shaun M. wrote: > William,**** > > ** ** > > I’m not sure I quite understand what you are saying here, but it would be > my preference to use the build farm over anything else. Here are a couple > of questions:**** > > ** ** > > **・ **Can the build farm build multiple repo branches for a > single ROS release? We typically have a stable release branch (groovy) and > a similar branch with the latest and greatest (groovy_devel). Is it > possible to build both on the build farm? > Yes, they just need to be added to the index. https://github.com/ros/rosdistro/blob/master/hydro/source.yaml You can see the jobs here: http://jenkins.ros.org/view/Hdev/ > **** > > **・ **Does the build farm monitor repos for changes or is it > triggered in the release process and/or when dependencies change? The > ROS-I Jenkins server monitors the repo and triggers a build whenever > anything has changed. > The source jobs monitor the source repo for changes. RIght now it's configured to run hourly. > **** > > **・ **Can we add metrics or other analysis to the build farm, > like Bosch did (see Tully’s email)? Things like reporting warning, line > counts, and code coverage could be done without much configuration of the > build server (just minor modifications to the build scrips). Jenkins would > have to be reconfigured to display the associated plots/charts as well. > Yes. The jenkins configuration for the jobs is all autogenerated. If you submit a pull request to add these features to the templates it will propogate to all jobs on the build farm. https://github.com/ros-infrastructure/jenkins_tools/tree/master/src/jenkins_tools/resources/templates And the code which is run inside the jobs is in this repo: https://github.com/ros-infrastructure/jenkins_scripts Johannes also added a new build type the metrics one, and if we can work with people to do the same as well, though I think extending/improving the current jobs will be more useful than generating a new set. Likely we should also merge the metrics and standard unit tests too now that we've shown that they work. Tully > **** > > ** ** > > Shaun Edwards**** > > Senior Research Engineer**** > > Manufacturing System Department**** > > ** ** > > ** ** > > http://robotics.swri.org**** > > http://rosindustrial.swri.org/**** > > http://ros.swri.org**** > > Join the ROS-Industrial Developers List > **** > > Southwest Research Institute**** > > 210-522-3277**** > > ** ** > > *From:* ros-users-bounces@code.ros.org [mailto: > ros-users-bounces@code.ros.org] *On Behalf Of *William Woodall > *Sent:* Friday, September 06, 2013 1:10 PM > > *To:* User discussions > *Subject:* Re: [ros-users] Software Status Reporting and Custom Builds**** > > ** ** > > So, yes travis-ci is awesome, I use it frequently to build ROS and ROS > agnostic things:**** > > ** ** > > https://github.com/wjwwood/serial/blob/master/.travis.yml**** > > > https://github.com/ros-perception/perception_pcl/blob/hydro-devel/.travis.yml > **** > > https://github.com/ros-infrastructure/bloom/blob/master/.travis.yml**** > > ** ** > > But I would also point out that if you have your repository (containing > one or more packages) listed in the `source.yaml` file for a given ROS > distribution, like this one:**** > > ** ** > > https://github.com/ros/rosdistro/blob/master/hydro/source.yaml**** > > ** ** > > Then our buildfarm (jenkins.ros.org) will do "devel" jobs for your > packages which build it, run the tests, and report back to you. The benefit > of this approach over travis-ci is that for catkin packages it already > knows how to resolve your dependencies for you, build your code and run the > tests (and hook into the test results). So it is a bit more zero > configuration than travis-ci for catkin (ROS) packages.**** > > ** ** > > Not saying we shouldn't use travis-ci, I just wanted to make sure people > knew about this option.**** > > ** ** > > --**** > > ** ** > > On Fri, Sep 6, 2013 at 10:51 AM, Thomas Moulard > wrote:**** > > On Fri, Sep 6, 2013 at 10:48 PM, Edwards, Shaun M. > wrote: > > All, > > > > > > > > I looked at Travis briefly but it seemed to be set up for stand-alone > > libraries or those with minimal dependencies. I assume “installing” ROS > was > > not an option and building ROS packages would be impossible. Am I > missing > > something?**** > > Travis is providing you with a Ubuntu 12.04 virtual machine at each build. > Starting from that, there is no reason to not be able to install ROS on it > and > check your build. > The tricky part is that they decide whether or not your use is "fair" or > not. > Without notifying them first a full switch of the ROS community is > therefore > risky. AFAIK if your build takes less than 30 minutes they are fine. > > So for vision_visp I am fine: > https://travis-ci.org/laas/vision_visp/branches > > As for how to do it, it is exactly what you would do on your own machine. > The .travis.yml call the .travis/before_install script which setup the apt > repositories, get the key and run apt-get install. > > https://github.com/stack-of-tasks/redundant_manipulator_control/blob/master/.travis.yml > > https://github.com/stack-of-tasks/redundant_manipulator_control/blob/master/.travis/before_install > > Best, > -- > Thomas Moulard（ムラー トマ） > CNRS-AIST JRL (Joint Robotics Laboratory), UMI3218/CRT, Tsukuba, Japan > http://thomas.moulard.net | Tel: +81 (0)80-9436-1985 | GPG Key Id: > 516FC68F31496D58 > Add me on LinkedIn: http://www.linkedin.com/in/moulard**** > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > http://lists.ros.org/mailman/listinfo/ros-users**** > > > > **** > > ** ** > > -- > William Woodall**** > > ROS Development Team**** > > william@osrfoundation.org**** > > http://williamjwoodall.com/**** > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > http://lists.ros.org/mailman/listinfo/ros-users > >