ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

How do I use wstool recursively?

asked 2019-02-05 09:34:02 -0600

VictorLamoine gravatar image

Repository A contains a a.rosinstall file that contains it's source dependencies. Within a.rosinstall there is:

  • Repository B
  • Repository C

It happens that B also contains a rosinstall file, b.rosinstall that has repository D inside.

Is there a way with wstool to merge recursively so that every indirect dependency of A (E) is also cloned?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2019-02-05 09:52:06 -0600

gvdhoorn gravatar image

updated 2019-02-05 09:58:04 -0600

No, that is not one of the use-cases that wstool covers.

Repositories are almost completely opaque to wstool, it doesn't really understand anything about them (it essentially 'forwards' commands to vcs binaries that do all the work) and doesn't introspect the repositories that it clones.

It also (somewhat) follows the KISS principle: what you want could be done using a bash one-liner.

But it would also seem to result in nested .git (or other vcs) checkouts, which is not really something recommended.

It's not exactly what you are looking for, but vcstool's import verb does support git submodules:

  --recursive        Recurse into submodules (default: False)

and supports importing .rosinstall files.

Personally I don't like submodules at all, but it could provide an alternative approach.

edit flag offensive delete link more


Then I'll make my own script! It's for ros_gitlab_ci

VictorLamoine gravatar image VictorLamoine  ( 2019-02-05 09:53:16 -0600 )edit

Example bash function here. Be careful because this function deletes the rosinstall files along the way, only use in CI environment!

VictorLamoine gravatar image VictorLamoine  ( 2019-02-06 15:17:24 -0600 )edit

Can you comment on why you're not using industrial_ci? From reading the code of that script, it would seem to be doing what industrial_ci does (in a gitlab setup).

gvdhoorn gravatar image gvdhoorn  ( 2019-02-07 03:04:21 -0600 )edit

At the time I switched to GitLab industrial_ci was not compatible with GitLab CI. I like to be able to modify it on my own without waiting for someone to merge a request (usually takes weeks..). I could probably switch to industrial_ci but it would take a lot of time. And I would probably have

VictorLamoine gravatar image VictorLamoine  ( 2019-02-07 03:08:56 -0600 )edit

to re-implement some features that are missing in industrial_ci. Like being able to clone private repositories from GitLab using CI job tokens. industrial_ci uses SSH keys and the setup is MUCH more complicated.

I still think ros_gitlab_ci is simpler than industrial_ci

VictorLamoine gravatar image VictorLamoine  ( 2019-02-07 03:11:44 -0600 )edit

It's simpler, yes, agreed. I was just curious, not trying to say that you should switch.

All alternative approaches to a common problem tend to converge towards similar solutions though.

gvdhoorn gravatar image gvdhoorn  ( 2019-02-07 03:40:44 -0600 )edit

Question Tools

1 follower


Asked: 2019-02-05 09:34:02 -0600

Seen: 963 times

Last updated: Feb 05 '19