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.
