Rosanswers logo

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...

Originally posted by peci1 on ROS Answers with karma: 1366 on 2022-08-26

Post score: 2


1 Answer 1


Rosanswers logo

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-release/blob/master/noetic.ignored

There's an older question here with more details: https://answers.ros.org/question/66545/to-ignore-some-pkgs-upon-release-by-bloom/

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.

Originally posted by tfoote with karma: 58457 on 2022-08-26

This answer was ACCEPTED on the original site

Post score: 2

Original comments

Comment by peci1 on 2022-08-27:
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).

Comment by peci1 on 2022-08-27:
Bloom wiki updated. Feel free to improve the wording: https://wiki.ros.org/action/info/bloom/Tutorials/ReleaseCatkinPackage?action=diff&rev2=41&rev1=40 .

Comment by tfoote on 2022-08-29:
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 default and have a separate entry point for the specific tests.

Comment by peci1 on 2022-08-29:
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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.