Platform generators being run for removed packages.

[nuclearsandwich]

This was reported by @clalancette earlier this week and I've been investigating off and on as well as waiting for some data to come back from GitHub.

The initial error was

 ! [rejected]          debian/ros-rolling-rosbag2-converter-default-plugins_0.6.0-1_focal -> debian/ros-rolling-rosbag2-converter-default-plugins_0.6.0-1_focal (already exists)
error: failed to push some refs to '[email protected]:ros2-gbp/rosbag2-release.git'
hint: Updates were rejected because the tag already exists in the remote.
Pushing changes failed, would you like to add '--force' to 'git push --tags'?

Thankfully clalancette saved the full log.

Looking at it we see that the rosrelease generator, which takes the upstream repo and carves it up into release branches that each contain just one package.

The list of released packages isn't explicitly passed to the platform generators (rosdebian, rosrpm, etc). Instead the platform generators take a --prefix argument and generate platform data for each branch found matching that prefix. To prevent performing releases for removed packages, by default each generator actually does examine the upstream branch to filter out packages not found in the branch.

But when the rosdebian generator runs it does list the extra rosbag2_converter_default_plugins package. This ought only be the case if the upstream branch includes that package. But given that the earlier git bloom-import-upstream ran successfully we'd expect the upstream branch to match the tagged target release.

It seems that somehow either the state of the upstream branch got altered during the bloom-release; a theory for which there is no supporting evidence. Or that the logic pruning missing packages contains a bug which expressed during this run. Since it's

I also requested the release repository push logs from GitHub to see if it was possible that the previous state of the release repository could have contained an upstream branch with stale data but there isn't a recent push to upstream with a commit containing that package at the HEAD.

I'm thus a bit stuck as I can neither reproduce the problem with the current state of the release repository nor find a smoking gun among the prior states. One possible mitigation to try is an update to the pruning logic to explicitly check out the upstream/VERSION tag for the target version, which would guard against changes to the upstream branch but for a typical bloom release flow the tag is created from the state of the upstream branch and so they should be the same.

If anyone else sees phantom extra packages being released please save a copy of the bloom-release output and share any additional details here.