You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I just discovered by accident that bloom seems to allow inconsistent specification of the targeted ROS distribution between command line argument and input during the script.
Steps to reproduce:
Call bloom providing a certain ROS distro as argument, e.g., bloom-release --rosdistro rolling ...
When asked for the ROS release during execution, provide a different ROS distro, e.g., galactic (rolling will be the default answer for the question in this case)
This will lead to a PR changing rolling/distribution.yaml (according to the initial command line argument). The distribution given during execution of the script doesn't seem to have any effect. This might lead to a user assuming he is releasing for galactic, therefor answering subsequent questions accordingly, which will lead to a wrong PR (to the rolling distro in the above example).
So it seems that 2. is pretty much ignored when the distribution is given via command line? I have to say that this was discovered during the initial release of a package. I will try if this is the same when doing subsequent releases once the initial PRs are merged.
I just discovered by accident that bloom seems to allow inconsistent specification of the targeted ROS distribution between command line argument and input during the script.
Steps to reproduce:
bloom-release --rosdistro rolling ...
galactic
(rolling
will be the default answer for the question in this case)This will lead to a PR changing
rolling/distribution.yaml
(according to the initial command line argument). The distribution given during execution of the script doesn't seem to have any effect. This might lead to a user assuming he is releasing for galactic, therefor answering subsequent questions accordingly, which will lead to a wrong PR (to the rolling distro in the above example).So it seems that 2. is pretty much ignored when the distribution is given via command line? I have to say that this was discovered during the initial release of a package. I will try if this is the same when doing subsequent releases once the initial PRs are merged.
This is an example of the above situation.
The text was updated successfully, but these errors were encountered: