Ask Your Question
0

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
2

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

Comments

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

VictorLamoine gravatar imageVictorLamoine ( 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 imageVictorLamoine ( 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 imagegvdhoorn ( 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 imageVictorLamoine ( 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 imageVictorLamoine ( 2019-02-07 03:11:44 -0600 )edit
1

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 imagegvdhoorn ( 2019-02-07 03:40:44 -0600 )edit

Your Answer

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

Add Answer

Question Tools

1 follower

Stats

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

Seen: 92 times

Last updated: Feb 05