On Fri, Sep 6, 2013 at 12:10 PM, Edwards, Shaun M. <sedwards@swri.org> 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:

 

 

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:

 

 

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 <thomas.moulard@gmail.com> wrote:

On Fri, Sep 6, 2013 at 10:48 PM, Edwards, Shaun M. <sedwards@swri.org> 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


_______________________________________________
ros-users mailing list
ros-users@code.ros.org
http://lists.ros.org/mailman/listinfo/ros-users