Basic questions on Buildbot-ros

[damien...@tecnalia.com]

Hi.
To make my story short, I need to build some deb packages to be able to distribute my ros applications to our clients. I do not want to use the Ros buildfarm since part of it is not open source due to client's confidentiality contracts...
The long story is explained here: http://answers.ros.org/question/192419/how-to-setup-bloom-to-generate-a-local-deb-outside-of-rosorg-buildfarm/

William from OSRF suggested to look at your buildbot-ros for the CI aspect.
But looking into your github, it sounds to me that if I use your project I'll be able to perform almost all I need, right?

I however have a few questions: I'm a complete newbie to distributing packages in Linux. I used to release some custom made windows installers in a previous position where we used Microsoft Robotics Studio though...

So can you please provide me some insights on the following topics:
- we're using our own SVN server and not GIT or github. Builbot-ros is setup to get sources from git . How complex would be change this to svn ( and generate the tests and documentation as well) ? any pointer on where this would happen?

- I'm not sure to understand what can run on my machine and what must be on a private server and/or on a public server: I've gone rapidly through the 5 minute tutorial of builbot and have understood quite well the more complex concepts, but not the basic arquitecture...
So, I indeed need to run buildbot on a specific machine. I guess I run it on a VM, no? But this machine must be a server? it must run a webserver as well to access the results of the build and tests? it must run an apt server?
Where are the generated .deb files located at the end?
As you can see, I'm a bit lost with the big picture...
Can you bring me light? :-)

- and finally, to distribute the debs to my clients, the usual way would be to setup a public apt server...
But I haven't got so many clients yet and would prefer to store the .deb on a FTP... Can and how can my client later install the deb he downloaded form this FTP??
I've just gone through your slides of Roscon2014. Does this Docker play this role of .deb distribution?


Sorry for these basic questions and thanks in advance for your answers!

Damien

[Michael Ferguson]

Damien,

See inline responses

So can you please provide me some insights on the following topics: 
- we're using our own SVN server and not GIT or github. Builbot-ros is setup to get sources from git . How complex would be change this to svn ( and generate the tests and documentation as well) ? any pointer on where this would happen? 

For documentation and test jobs (what the ROS buildfarm calls "devel" jobs), this should be somewhat straightforward. For the test job, there are two places where git is used: 

 * https://github.com/mikeferguson/buildbot-ros/blob/master/buildbot_ros_cfg/ros_test.py#L62 is where we setup the poller (the thing that goes out to check for changes). Buildbot itself contains an SVN version of this change source, so swapping that out should be easy. 

 * https://github.com/mikeferguson/buildbot-ros/blob/master/buildbot_ros_cfg/ros_test.py#L90 is where we check out the code. Again, SVN support exists in buildbot, I just haven't configured buildbot-ros to do this, so swapping Git with the appropriate SVN-related class should work.

The documentation job has a similar checkout (https://github.com/mikeferguson/buildbot-ros/blob/master/buildbot_ros_cfg/ros_doc.py#L40) but no poller (since we usually just build docs each night). With both doc/test jobs, it should of course be possible to modify the code in such a way that the selection of git/svn is made based on the rosdistro file -- but up until now I haven't bothered adding support for anything except git...

Now, for debians, the repository is going to have to be a git repo (doesn't have to be on github though), since bloom (the ROS release tool) is creating a git-buildpackage to build the debian from.

 

- I'm not sure to understand what can run on my machine and what must be on a private server and/or on a public server: I've gone rapidly through the 5 minute tutorial of builbot and have understood quite well the more complex concepts, but not the basic arquitecture... 
So, I indeed need to run buildbot on a specific machine. I guess I run it on a VM, no? But this machine must be a server? it must run a webserver as well to access the results of the build and tests? it must run an apt server? 
Where are the generated .deb files located at the end? 
As you can see, I'm a bit lost with the big picture... 
Can you bring me light? :-) 

Typically, yes, you want your apt repo hosted by an instance of nginx or apache -- however, you can certainly run these programs on any existing linux machine, you don't need to run out and buy new servers. Further, the building of debians is somewhat segmented from hosting.

The overall setup looks like this:

 * buildbot-ros instance (since it is python, we frequently deploy this on an existing machine using virtual-env). This instance needs to be able to access your source repos and your release repos (those git-buildpackage repos that were created manually using bloom).

 * apt-repo: this is where your generated debs go. There are two things going on here. When new debs are built, buildbot-ros adds those new debs using a tool called reprepro. Reprepro acts on this directory of files/indexes to update them on the local file system -- so it wants this repo to be some local files. When we then are building other debs that depend on debs we have already built, we need to check those already uploaded debs out -- and here we want it to be a webserver. In theory, you could access file:/// repos, but this is currently unsupported (https://github.com/mikeferguson/buildbot-ros/issues/10).

Thus, if everything you are building is at most 1 layer deep (you aren't building any debians that depend on other private debians that you build first), then you don't really need a webserver, the only interaction with your own apt-repo is through a filesystem interface with reprepro when adding those debs. You can then manually sync the built debs somewhere else for people to access. Note also that there are some caveats when building on top of private repositories, mostly described here https://github.com/mikeferguson/buildbot-ros/blob/master/documentation/private_repositories.md

 

- and finally, to distribute the debs to my clients, the usual way would be to setup a public apt server... 
But I haven't got so many clients yet and would prefer to store the .deb on a FTP... Can and how can my client later install the deb he downloaded form this FTP?? 
I've just gone through your slides of Roscon2014. Does this Docker play this role of .deb distribution?

Once created, the apt repo is really just a set of files (debs + some index files that are updated as debs are added). You could certainly sync these files to any sort of server -- but I'm not sure whether the apt-get tool can work with FTP.

As for docker, currently, we have been playing with Docker as an alternative to a VM for deploying buildbot-ros instances -- however, this is not quite ready for primetime (as far as I know, I'm the only one to do it, so nobody has checked the completeness of my instructions).

-Fergs

--
You received this message because you are subscribed to the Google Groups "buildbot-ros-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buildbot-ros-s...@googlegroups.com.
To post to this group, send email to buildbot...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/84a51e53-70d0-40f3-8739-64b961c337bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[damien...@tecnalia.com]

Thanks for these insights.

I haven't setup anything yet, so let me try to go through all the required steps as I visualize them, and please correct me if/when I'm wrong...

1. Make sure in my local dev machine that everything runs smoothly

• Test catkin_make install -> relocate the /install folder and make sure the packages binaries are executed correctly. 
• tag the source repository for the desired release number
• configure Bloom correctly (not sure yet exactly what parameters should be taken care of...)
  
• run bloom-generate ...
• run fakeroot ... (or not)

2. When this is ok, then try to automate, using buildbot-ros

• I need to set-up a Git server to host the debs that will be generated
• I need to dedicate a specific machine in my local network to generate the builds
• I need to generate a rosdistro repository -> in the new git? in my current source svn? -> what should this repo include?(I won't need to recompile ROS, right?)
• I need to run on this build machine a webserver
• I need to run on another machine, in my company DMZ or anywhere accessible publicly, an apt server (I don't have a clue about which server/package/software to use... any recommendation?) Or is it the git server I had to setup on the first bullet point?
• On this build machine, setup and run buildbot-master and slave
• I guess I need to add a cron task to perform the builds periodically, right?

Is this more or less the required steps?

Am I missing a critical one?

And two more questions, from your experience:

• How can we configure bloom or whatever system to select what package should be provide with or without source code?
• In order to add obfuscation in the build process, I believe I will just need to add this task in the buildbot-master... right?

Thanks again to clarifying this complex process for me!...

Best 

Damien

[Michael Ferguson]

See inline responses:

1. Make sure in my local dev machine that everything runs smoothly

• Test catkin_make install -> relocate the /install folder and make sure the packages binaries are executed correctly. 
• tag the source repository for the desired release number

Yes, also take a look at catkin_prepare_release tool which will help automate this, especially if you are creating changelog files. 

• configure Bloom correctly (not sure yet exactly what parameters should be taken care of...)
  
• run bloom-generate ...
• run fakeroot ... (or not)

I have to admit, I wasn't aware of bloom-generate -- I've typically just run git-buildpackage on the debs, so the last step I can talk about is bloom-release...

 

2. When this is ok, then try to automate, using buildbot-ros

• I need to set-up a Git server to host the debs that will be generated

Just to be totally clear: the git-buildpackage (the source to build the deb) is held in a git repo, the actual generated debian packages are not (they are in an apt repo, which is really just a special filestructure served through a regular webserver) 

• I need to dedicate a specific machine in my local network to generate the builds

You obviously have to put buildbot on a machine, but the overhead is usually not much, so it may not need to be dedicated to just that use... 

• I need to generate a rosdistro repository -> in the new git? in my current source svn? -> what should this repo include?(I won't need to recompile ROS, right?)

Yes, you need a rosdistro that specifies what your farm is building. There are examples here: https://github.com/mikeferguson/rosdistro-buildbot-example. This should probably be in it's own git repo, but I'm not 100% sure on the limitations of the python-rosdistro parser or whether it supports other configs. 

• I need to run on this build machine a webserver

Yes, the webserver would host the apt repo, but as I stated earlier, this is only required if you build packages that depend on other packages you build. 

• I need to run on another machine, in my company DMZ or anywhere accessible publicly, an apt server (I don't have a clue about which server/package/software to use... any recommendation?) Or is it the git server I had to setup on the first bullet point?

If you build packages that depend on other packages you build, the apt server has to be accessible to the buildbot. After that, once everything is built, you want to sync the packages to your actual hosting server that people access (usually these are two different apt repos, because you don't want to build into the same repo as you are hosting, you want to control the sync) 

• On this build machine, setup and run buildbot-master and slave
• I guess I need to add a cron task to perform the builds periodically, right?

By default, builds will run nightly, the cron job is to reload the rosdistro, otherwise you have to manually kick the buildbot after each rosdistro update (which happens each time you push a new release).

 

And two more questions, from your experience:

• How can we configure bloom or whatever system to select what package should be provide with or without source code?
• In order to add obfuscation in the build process, I believe I will just need to add this task in the buildbot-master... right?

 I'm not sure I understand either of these questions...

-Fergs

[William Woodall]

On Fri, Sep 19, 2014 at 12:51 PM, Michael Ferguson <mfe...@gmail.com> wrote:

See inline responses:

1. Make sure in my local dev machine that everything runs smoothly

• Test catkin_make install -> relocate the /install folder and make sure the packages binaries are executed correctly. 
• tag the source repository for the desired release number

Yes, also take a look at catkin_prepare_release tool which will help automate this, especially if you are creating changelog files. 

• configure Bloom correctly (not sure yet exactly what parameters should be taken care of...)
  
• run bloom-generate ...
• run fakeroot ... (or not)

I have to admit, I wasn't aware of bloom-generate -- I've typically just run git-buildpackage on the debs, so the last step I can talk about is bloom-release...

 

2. When this is ok, then try to automate, using buildbot-ros

• I need to set-up a Git server to host the debs that will be generated

Just to be totally clear: the git-buildpackage (the source to build the deb) is held in a git repo, the actual generated debian packages are not (they are in an apt repo, which is really just a special filestructure served through a regular webserver) 

• I need to dedicate a specific machine in my local network to generate the builds

You obviously have to put buildbot on a machine, but the overhead is usually not much, so it may not need to be dedicated to just that use... 

• I need to generate a rosdistro repository -> in the new git? in my current source svn? -> what should this repo include?(I won't need to recompile ROS, right?)

Yes, you need a rosdistro that specifies what your farm is building. There are examples here: https://github.com/mikeferguson/rosdistro-buildbot-example. This should probably be in it's own git repo, but I'm not 100% sure on the limitations of the python-rosdistro parser or whether it supports other configs. 

You can have a local rosdistro folder, you can set the ROSDISTRO_INDEX_URL to something like file:///path/to/my/rosdistro/index.yaml. Basically you can set that to anything that urllib.request.urlopen supports.

 

• I need to run on this build machine a webserver

Yes, the webserver would host the apt repo, but as I stated earlier, this is only required if you build packages that depend on other packages you build. 

• I need to run on another machine, in my company DMZ or anywhere accessible publicly, an apt server (I don't have a clue about which server/package/software to use... any recommendation?) Or is it the git server I had to setup on the first bullet point?

If you build packages that depend on other packages you build, the apt server has to be accessible to the buildbot. After that, once everything is built, you want to sync the packages to your actual hosting server that people access (usually these are two different apt repos, because you don't want to build into the same repo as you are hosting, you want to control the sync) 

• On this build machine, setup and run buildbot-master and slave
• I guess I need to add a cron task to perform the builds periodically, right?

By default, builds will run nightly, the cron job is to reload the rosdistro, otherwise you have to manually kick the buildbot after each rosdistro update (which happens each time you push a new release).

 

And two more questions, from your experience:

• How can we configure bloom or whatever system to select what package should be provide with or without source code?
• In order to add obfuscation in the build process, I believe I will just need to add this task in the buildbot-master... right?

 I'm not sure I understand either of these questions...

-Fergs

--

You received this message because you are subscribed to the Google Groups "buildbot-ros-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buildbot-ros-s...@googlegroups.com.
To post to this group, send email to buildbot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/CAF0acfTrkGm6XDu5dq6oXHtkngEFGfKHBhVandeNRL%2BWZmA5LQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

William Woodall

ROS Development Team

wil...@osrfoundation.org

http://wjwwood.io/

[damien...@tecnalia.com]

Hi.
One more question, related to Bloom, before really running builbot-ros.

Since we want to build our packages locally, we want to use bloom to generate the debian config files but no more.

From bloom webpage and tutorials, it appears that running

bloom-release --rosdistro hydro --track hydro repository_name

Does generate a pull request to the ros.org buildfarm...

So, since we do NOT want that, what option or file should I change in order to disable the pull request?
The bloom-release -help doesn't propose this option... unless the pull request is related with this Track feature??

Thanks



[damien...@tecnalia.com]

Or maybe we shouldn't run

bloom-release   ...

But run instead?

bloom-generate rosdebian --os-name ubuntu --os-version precise --ros-distro hydro

I really don't want to mix up with Ros official build farm....

Also, isn't this supposed to be executed by buildbot-ros?
Based on the rosdistro that I need to specify, no?

Damien

[Michael Ferguson]

Damien,

I just ctrl-C when I get to the pull request part, not sure if there is a more elegant solution.

The buildbot will use the git-buildpackage *created* by bloom to generate the actual debian file. The output of bloom simply includes the code + build instructions required to make the debian.

-Fergs

[Jon Binney]

Did you have to add all of the entries from the main ROS rosdistro file to your own rosdistro files? I tried using William's suggestion of setting ROSDISTRO_INDEX_URL to my own local index.yaml, but then when i do bloom-release, it complains about not being able to find message_runtime. This seems to be related to http://answers.ros.org/question/135976/bloom-could-not-resolve-rosdep-key-message_runtime/ which doesn't seem to have a clear solution yet.

--

You received this message because you are subscribed to the Google Groups "buildbot-ros-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buildbot-ros-s...@googlegroups.com.
To post to this group, send email to buildbot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/38db531e-d6a9-4043-a242-3ffd4cdc81ba%40googlegroups.com.

[Michael Ferguson]

Jon, 

I manually update my rosdistro, but would certainly be interested in a cleaner solution...

-Fergs

[William Woodall]

bloom is designed to use the ROSDISTRO_INDEX_URL environment variable. You should set this to point to your index.yaml of your rosdistro fork before running bloom-release. That way bloom will open a pull request against your fork of rosdistro if it is able (hosted on github). If you point that env variable at a file://... url or some non-github git repo url then it will not try to open a pull request.

--
You received this message because you are subscribed to the Google Groups "buildbot-ros-sig" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buildbot-ros-s...@googlegroups.com.
To post to this group, send email to buildbot...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/042c0861-00ac-46fb-b8e3-622bf4c29847%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Jon Binney]

I wasn't even trying to get it to do the pull request, i just wanted to make it easier for bloom to find my release repo. Setting ROSDISTRO_INDEX_URL turned out to not be feasible, though, because then rosdep couldn't find any normal ROS packages.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/CAFe2DWj94pmSVAaUd34L6uF7v0H4xQDDyd7-p_s5JghCoNuHXw%40mail.gmail.com.

[Jon Binney]

Actually, now I'm really confused. If i run bloom-release without setting ROSDISTRO_INDEX_URL, then it fails with

"""

####

#### Generating 'saucy' debian for package 'savi_map' at version '0.1.1-0'

####

Generating debian for saucy...

No homepage set, defaulting to ''

Could not resolve rosdep key 'savibot_sensor_msgs'

Try to resolve the problem with rosdep and then continue.

"""

Where savibot_sensor messages is another package that I'll be releasing using buildbot-ros (but of course it isn't in the main ROS rosdistro.) If I do set ROSDISTRO_INDEX_URL to my own rosdistro file, then bloom-release fails with:

"""

####

#### Generating 'trusty' debian for package 'savi_navigator' at version '0.1.1-0'

####

Generating debian for trusty...

No homepage set, defaulting to ''

Could not resolve rosdep key 'message_runtime'

Try to resolve the problem with rosdep and then continue.

"""

So I'm not sure what to do. I could take every single ROS package that is in the main ROS rosdistro and copy it into my own, but that seems incredibly painful.

[G.A. vd. Hoorn - 3ME]

Isn't the idea to create a fork of the main rosdistro repository, add
your own rules to it (for your local packages), and _then_ set
ROSDISTRO_INDEX_URL to point to that local fork?

At least, that is what I understood from William's reply, earlier.

>>>> <https://groups.google.com/d/msgid/buildbot-ros-sig/042c0861-00ac-46fb-b8e3-622bf4c29847%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .

>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>> --
>>> William Woodall
>>> ROS Development Team
>>> wil...@osrfoundation.org
>>> http://wjwwood.io/
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "buildbot-ros-sig" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to buildbot-ros-s...@googlegroups.com.
>>> To post to this group, send email to buildbot...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/buildbot-ros-sig/CAFe2DWj94pmSVAaUd34L6uF7v0H4xQDDyd7-p_s5JghCoNuHXw%40mail.gmail.com

>>> <https://groups.google.com/d/msgid/buildbot-ros-sig/CAFe2DWj94pmSVAaUd34L6uF7v0H4xQDDyd7-p_s5JghCoNuHXw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .

[Michael Ferguson]

Jon,

See https://github.com/mikeferguson/buildbot-ros/blob/master/documentation/private_repositories.md#solution-for-bloom-release for my workaround, I basically create a couple local rosdep keys. I know this works for both myself and Clearpath. I also know that Mike Purvis and I were discussing that it would be really awesome to be able to chain rosdistros (so my rosdistro is on top of the public one), but I don't think that is currently supported, and neither of us had the time to look into it yet.

-Fergs

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/CANmm_TkFrFo3nQq0bEbRiKF8RyBC9wES2OE%2BwkVkoeLPkWnwkg%40mail.gmail.com.

[William Woodall]

Yeah this is the crux of the above linked answer on answers.ros.org, bloom and rosdep respect the ROSDISTRO_INDEX_URL, but you want rosdep to pull from both the upstream rosdistro and your custom one. Currently this isn't supported, but you could imagine a rosdistro config which identifies an "upstream" rosdistro, from which rosdep could be modified to additionally pull from.

Current options are to fork rosdistro and add your packages or come up with a solution by which you create rosdep keys for ROS packages in the official rosdistro repo which you use.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/CAF0acfQ2QLpQBhobbKTA%3DV-x7c6fx52UZzs0mx2ehW356%3DR6_w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jon Binney]

Got it, thanks. Just in case anyone else runs into this, I had some trouble with rosdep when switching back and forth between the main index.yaml and my own local one. After I ran it once with ROSDISTRO_INDEX_URL set to my local file, it couldn't find any normal ROS packages, even after I unset that environment variable. Running "rosdep update" didn't resolve the issue either - I finally had to "rm -rf ~/.ros; rosdep update" to get it to re-find the packages in the main ROS rosdistro file.

To view this discussion on the web visit https://groups.google.com/d/msgid/buildbot-ros-sig/CAFe2DWi5rfjGi0f%2Bhfi_cp9XrBqX%2B4OJMutOtetOGBnaJ2bEbg%40mail.gmail.com.

[damien...@tecnalia.com]

Hi all,

I've been unable to work on this for the past weeks, but I'm still moving on step by step...
I now have all codes ready for deployment and could generate manually a debian with gbp.
I still have to work out my own rosdistro and the local mirrors... in order to get buildbot-ros set properly...


I now have 3 sets of questions:

A: WORKFLOW

So now, I have a doubt that I'd like to clarify on the WORKFLOW you are following with buildbot-ros and bloom...

I had in mind that buildbot-ros would perform all the steps at every nightbuild: checkout the source, compile, test, boom, generate the doc and the debian...

But I've looking deeply in the master.cfg and the slaves python examples you are providing.
And I now think (please confirm) that your workflow is the following:

1. Check source updates (check for newcommits)
2. When source updated, then run a build and test slave. (Here, I don't see where you perform catkin_make, since the cmake flags you are using are not setting the devel overlay, just the test ones... Is there a reason for that? Isn't that required?)
I'm not quite sure either if you run the doc slave now also or not.

This will provide some nightly build and testing results.
But it won't provide a nightly stable version of the packages to the developpers. Will just check for breaks in the build. Right?

Then when you consider that you are ready for a new release, based on your release plan and strategy, you MANUALLY run catkin_prepare_release and bloom-release.
Still correct?

Then go to the buildbot-ros webpage and manually force a build on the deb generator slave.
Is this correct? or do you also automatically check for source updates on the bloom/debian_files git server to run the build with the deb builder slave?

Can you confirm that this is the current workflow you are using with buildbot-ros?


B. Private git for bloom-release and git-buildpackage
I've been running some preliminary tests using non critical packages on a public github account, to get up to speed on the process.
But I'll need shortly to setup this process on our private internal git server.
And there's a lot of info about private repos, and stuff to make sure, this it is disseminated on many webpages...
So I would appreciate if you could try to summarize the pitfalls I have to avoid when setting this up on our private servers...
configs, ssh keys etc...
Thanks a lot in advance.


C. TESTING

And then I have another question, related to the Build and test part.
We haven't generalized the use of unit tests in our team, so we have really few unit tests available and no regression tests...

In that case of almost no tests available, what kind of feedback will buildbot provide? missing dependencies, compilation errors etc...?
Can we set the level of the warnings to be considered?

Then if/when we implement the gtest or unittest or rostest, I understand that buildbot will also provide the outputs of those tests, in the buildbot webpage or by email if added to the master config file. correct?

And a final question for today:
when running catkin_make and catkin_install, this doesn't prevent for a badly configured Install section of the CMakelist.txt or package.xml or setup.py...
So basically, the complete process can go through (up to generating bloom and the debian) without detecting that the application will not be functional because of a missing file for example only called in python at runtime; or because a python node hasn't been declared as an executable node...

So at the moment I need to manually execute and test all the roslaunch applications of my product, testing the GUIs etc to make sure that what I ship is really operational...
How can I automate those tests? So I'm not talking about intra-node functions testing, nor individual node publish/subscribe testing (that I can perform with gtest or unittest if I understood this well), but at the whole application level, loading the correct robot part program from the gui for example, and checking in simulation that the robot is really doing something... and that no runtime error or exception are thrown...

Is that feasible?
What links/pointers could you advise me to look into?

And by the way, since you are not running "catkin_make install" in the slave, how can you test that your "installed" files will be correct? The slave will be running in the /devel overlay when you run the testing buildbot slave, no? So you won't check for missing files or badly setup Install section of the Cmakelist.txt...
Am I not getting something? because I believe you need to execute the testing in the /install overlay to test your to-be-deployed application...




As you can, it is still not crystal clear to me, even if I feel that I'm quite close now...

Thanks for your support and patience!

Damien