Option to release simultaneously to Rolling and another distribution

[SteveMacenski]

As part of my workflow / needs for Galactic, I ended up releasing or updating released identical packages to both Galactic and Rolling. This got me thinking that this must be a common need especially at the start of a new distribution or in the most recent distribution to give changes to both the new distro and its future distros.

I think it would be nice to have a “—rolling” flag or similar to indicate to release to the tracks requested but also to rolling with the same fields. That would cut my release time in half!

[danthony06]

I agree. I just ran into this, because we're now releasing packages for Melodic, Noetic, Foxy, Galactic, and Rolling. It's a pretty error prone process, especially when we have packages that depend on each other. For example, foo depends on foo_msgs getting released with it, I end up running the bloom command 10 times to get these two packages released for all supported distributions. It would be nice to at least cut this in half, and simultaneously released for Foxy, Galactic, and Rolling if possible.

[nuclearsandwich]

Off the top of my head I'm not sure how easily that could be done. Naively it could just invoke the bloom release process for each track.

That would cut my release time in half!

The release data generated for different rosdistros, even if all other platform-specific data is identical is specific to the distribution. So it wouldn't cut down on the actual time bloom spends performing releases. But I recognize that with long-running processes like bloom there's a delay introduced by having to go do something else before it completes which slows your return for the next step.

[SteveMacenski]

I don't think this would be a time saver (at least my view) as much as a quality of life improvement so I could "run-n'-done" bloom once on a new distribution that would give updates to the new distribution after sync and Rolling at once. Since a new distribution is bootstrapped from the last Rolling release, when I want to make my "real" release to the new distribution representing last changes, I'm updating both of them with identical versions.

This wouldn't help much for during distribution releases, but I would say about 75% of my total releases for a year are made right as a new distribution is being released to get packages and updates out the door for the new one. That would at least make it so releasing is 50% less active by having it take care of both at once. This is especially impactful for maintainers that maintain 5, 10, 20 repositories where I usually spend a solid day just releasing in May.

I agree though its a small quality of life improvement, it was more throwing out an idea to see if others felt it would be useful and sparked an 'ah ha' for someone. If you don't think its worth the time cost to benefit ratio, I can certainly appreciate that and you're welcome to close it. This is probably not something I'll work on myself so if the maintainers here aren't, no reason to keep it open.

[danthony06]

Thinking through alternatives, would it be possible to use GitHub's CD features to run bloom after we make a release? If we could configure the job to release to a set of distros, I think this would fit in well with our workflow, and do the automation that I think is at the core of this issue.

[nuclearsandwich]

Thinking through alternatives, would it be possible to use GitHub's CD features to run bloom after we make a release? If we could configure the job to release to a set of distros, I think this would fit in well with our workflow, and do the automation that I think is at the core of this issue.

Yes. Running bloom non-interactively from a GitHub Action is doable as long as the release track is already configured. The GitHub action will need to be given an authentication token to allow it to push changes to the release repository and use the GitHub API to create the ros/rosdistro pull request. You may also need a way to indicate which tags map to which bloom release tracks / rosdistros as re-blooming every track for any tag or some pre-scripts to figure out which tracks to run.

If you don't think its worth the time cost to benefit ratio, I can certainly appreciate that and you're welcome to close it. This is probably not something I'll work on myself so if the maintainers here aren't, no reason to keep it open.

Actually I quite like the thought of being able to specify multiple tracks/rosdistros in a single bloom interaction. I'd have to test it to see how well it works in practice but I'd like to leave this one open on the backlog.

[Timple]

A typical bloom-release involves answering some questions (or hitting enter a lot to use the defaults).

If all questions can be answered by commandline-options. Wouldn't solve the whole issue with a minimal bash script?

#!/bin/bash
bloom-release --rosdistro foxy --track foxy lots-of-options-here
bloom-release --rosdistro galactic --track foxy lots-of-options-here
bloom-release --rosdistro rolling --track foxy lots-of-options-here

[danthony06]

@Timple that definitely seems doable. Personally I'd like to pass in a YAML file or something, so that I can version control it for CI/CD pipelines.