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

bloom: How to release a single package from a multi-package repo?

asked 2022-08-26 17:41:09 -0600

peci1 gravatar image

I've just started publishing one of our packages that sits in a subfolder of a git repo (along with a few other packages). There is no metapackage built on top of these packages, but they live in the single repo as they are loosely coupled.

I've noticed a lot of hurdles along the way - both catkin_generate_changelog and caktin_prepare_relase expect to be run in the root of the repo and handle all the packages. I haven't seen an option to tell them to act just on one package.

With bloom, it's even more complicated - it automatically generates a list of all packages in the repo, even though I do not want (for now!) to release all of them. As a dirty workaround, I've done the rosdistro PR manually and edited it to suit my intentions, but I can't imagine doing this too often. Is there a nice way to release a single ROS package from a multi-package repo? Should I have used the melodic.ignore file I've read about somewhere? Where is it documented?

My general idea is to gradually add all the packages to the release distribution, but it will take some time, and I wanted to go ahead with the first one that's ready. However, even then, it seems to me it's unnecessary to rebuild some 10 packages every time I change just one of them...

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
2

answered 2022-08-26 19:49:14 -0600

tfoote gravatar image

Yes, the correct way to prevent bloom from releasing packages it to use the <track>.ignore file.

An example is here: https://github.com/ros-gbp/geometry2-...

There's an older question here with more details: https://answers.ros.org/question/6654...

For the tools for generating the changelog and preparing for the release. They are driven by the limitation of our common modern distributed source control systems that tags are cross cutting across the repo. As such if you tag a repo with a version, the assumption is that everything in that repo is at that version. It would be possible to extend the capabilities to ignore more. Or you might be able to stop the discovery with AMENT_IGNORE/CATKIN_IGNORE but I haven't confirmed that they are using the full abstraction which would honor those files.

However, even then, it seems to me it's unnecessary to rebuild some 10 packages every time I change just one of them...

It turns out that this cost is actually moderately low. And is likely incurred anyway if any of the changed packages have inter-dependencies which is often the case for closely maintained packages. I would generally suggest not worrying about this much.

edit flag offensive delete link more

Comments

Thanks for the really prompt answer! I'll try with the ignore file, and I'll probably also update bloom docs. I've noticed one more thing - even though I released only the one package, the dev job on Jenkins still builds and tests all packages in the repo. In this case, it's bad, as I have a package with 30-min long tests that I yet have to make faster :) Is there a way to configure the dev job, too, without placing CATKIN_IGNORE in the repo (which I do not want, as we have a lot of from-source users who actually need all of the packages).

peci1 gravatar image peci1  ( 2022-08-27 13:05:23 -0600 )edit

Bloom wiki updated. Feel free to improve the wording: https://wiki.ros.org/action/info/bloo... .

peci1 gravatar image peci1  ( 2022-08-27 15:46:50 -0600 )edit
1

Thanks for updating the docs!

Unfortunately the dev jobs stanzas are entirely separate from the release stanza and do not have the ability to be tuned in the same way. We have to check out the whole repository because that's how git and mercurial work. But beyond that the goal of the dev jobs is to tell you the same thing as the from source users should expect with a clean workspace. So it would be possible to add that but we've specifically avoided that specifically. Basically if they're on by default for users the CI should test it too, otherwise you can get into states where CI passes but it breaks for users. I'd also suggest that if it's too slow for CI it's probably also too slow for an effective default for users. You could make the test not enabled/run by ...(more)

tfoote gravatar image tfoote  ( 2022-08-29 13:04:14 -0600 )edit
1

Thanks for the explanation. It does make sense and now I fully understand it ;) I've fortunately managed to speed up my tests several orders of magnitude just replacing hztest nodes with custom code, so now the tests are finished in a minute.

peci1 gravatar image peci1  ( 2022-08-29 14:30:14 -0600 )edit

Question Tools

2 followers

Stats

Asked: 2022-08-26 17:41:09 -0600

Seen: 136 times

Last updated: Aug 26 '22