Ask Your Question
0

Tracking package dependencies in pre-release builds

asked 2017-01-03 07:35:47 -0500

Christian Rauch gravatar image

TL;DR: How do I define dependencies between not-yet-released catkin packages in distribution.yaml such that their dependencies are resolved during the automatic build that is triggered by new commits.

I added two catkin packages (from separate git repos) to the distribution.yaml mainly for generating documentation and for automatic tests on the build farm. Let's call these packages L (a driver library) and N (a ROS node with L as dependency). Both of these packages have not been released yet.

As I understand from these topics:

http://answers.ros.org/question/23843... http://answers.ros.org/question/19006...

the build farm cannot track the dependency on L when building N because L has not been released yet. E.g. a pre-release build will fail with the script generated at http://prerelease.ros.org if only package N is selected. I can workaround this in local pre-release builds by selecting both packages (Land N) in the pre-release script generation.

I don't want to release L yet because it is still in development and I would need to re-release it every time when I change its interface or behaviour. However, I want to use the continuous integration feature on the build farm, e.g. get notification on failed builds. Currently, the build fails each time I commit to N because its dependency on L cannot be resolved automatically.

The build of N definitely succeeds if L is checked out manually. Thus, how do I define the dependency between N and L such that L gets checked out when N is built?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-01-03 10:53:17 -0500

Dirk Thomas gravatar image

For documentation you can reference other repository names using the depends entry (see REP 141). An example making use of this is multiwii.

For the devel jobs no such information exists. A devel job operates only on a single repository and installs all its dependencies from Debian packages. Since those are not available for L it doesn't work for your repository N. Therefore you might want to disable the devel job for repo N for now which you can do by adding test_commits: false to the source entry (see an example).

A depends entry could be added to source blocks too. Then the devel job would need to be a hybrid of the devel and prerelease process. We haven't implemented since its use is very limited. E.g. if you want to make correlated changes to L and N (e.g. change API and use the modified API) a pull request job would still fail. Simply because it uses the branch from one repo (e.g. N) but not the one from L. So you need a prerelease job to cover this case. If you on the other hand just commit the changes to L without trying if N actually works with it the failing CI job of N is pretty late (and would e.g. not even be triggered if you don't commit to N after committing the change to L).

For adding a depends entry for the source block it would require an updated version of REP 143 (the successor of REP 141) as well as support from the buildfarm. If you see a need for this it would be great if you could work on PRs for this. I am happy to help in that process.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2017-01-03 07:35:47 -0500

Seen: 57 times

Last updated: Jan 03 '17