fix: strip only the legacy prefix from GHA job names

[baszalmstra]

The generated GitHub Actions job names are wrong for any package that isn't named ros-<distro>-<something> (#136). On ros-rolling the mutex job shows up as mutex and ros2-ament-package shows up as package, which is pretty confusing when you're scanning a workflow run for the job that failed.

The cause is get_stage_name. It shortens names for display by dropping the first two dash-separated segments, but it never checks that those segments are actually the ros-<distro>- prefix — it just counts hyphens:

if len(pkg.split("-")) > 2:
    stage_name.append("-".join(pkg.split("-")[2:]))

That happened to work while every package was ros-<distro>-<name>. With package_name_mode: both it doesn't, because new-scheme names are ros2-<name>, so the second segment is part of the package name rather than the distro. It only goes wrong when the shortname itself contains a hyphen (i.e. the ROS package has an underscore), which is why two-segment names like ros2-rclcpp looked fine and hid the problem for a while.

The fix is to match the prefix instead of counting hyphens.

Before / after

recipe	before	after
ros-rolling-rclcpp	rclcpp	rclcpp
ros-rolling-ament-package	ament-package	ament-package
ros2-rclcpp	ros2-rclcpp	ros2-rclcpp
ros2-ament-package	package (wrong)	ros2-ament-package
ros2-distro-mutex	mutex (wrong)	ros2-distro-mutex

It's worse than just those two though. Truncating at a fixed offset throws away whatever makes a name unique, so unrelated packages end up sharing a label. A job name is the space-joined list of the packages in its batch, so in the current linux.yml on buildbranch_linux you get job names like vendor span cmake-auto coordinator cpp-vendor with no way to tell which packages are meant. 45 different packages are all displayed as msgs:

'msgs'   <- ros2-ackermann-msgs, ros2-action-msgs, ros2-actuator-msgs, ros2-can-msgs,
            ros2-geometry-msgs, ros2-sensor-msgs, ros2-std-msgs, ros2-tf2-msgs, ... (45 total)
'vendor' <- ros2-gtest-vendor, ros2-libyaml-vendor, ros2-mcap-vendor, ros2-mimick-vendor,
            ros2-osqp-vendor, ros2-pybind11-vendor, ros2-sdl2-vendor, ... (10 total)
'ros'    <- ros2-apriltag-ros, ros2-backward-ros, ros2-launch-ros, ros2-moveit-ros,
            ros2-pcl-ros, ros2-tf2-ros, ... (10 total)

I also kept the ros2- prefix on the new names rather than stripping that too. The issue suggests distro-mutex / ament-package as the nicer option, but in both mode the compatibility package and the canonical package are separate recipes, so stripping both prefixes makes almost every package collide with its own compat twin: 775 ambiguous labels covering 1550 of the 1551 recipes, which is far worse than what we have now. Five characters of prefix seemed like the better trade. Happy to change it if you'd rather have the shorter names.

Testing

I checked this against the real generated pipeline rather than only synthetic input. I took .github/workflows/linux.yml from ros-rolling's buildbranch_linux and re-derived every job name from the CURRENT_RECIPES env of each job:

• all 333 committed job names reproduce exactly under the old implementation, so the comparison is apples to apples;
• 173 of the 333 job names change;
• across the 1551 recipes in that pipeline the old naming produces 1391 distinct package labels, 62 of them ambiguous and covering 222 recipes. The new naming gives 1551 distinct labels with none ambiguous.

To be precise about the scope of that: whole job names were never duplicated, 333 distinct before and after, since a batch of five packages is a unique combination. What changes is that the individual package labels inside a job name now identify the package.

Also added vinca/test_generate_gha.py with the cases from the table.

I did not re-run the generator end to end, since replaying the committed output covers the part this PR touches. Only linux-64 was checked; the same code path produces the Windows and macOS pipelines.

[traversaro]

Stacked on top of #143, which fixes a pre-existing lint and test failure on master. Until that one merges, this PR's diff also contains its commit; review only vinca/generate_gha.py and vinca/test_generate_gha.py here.

I saw it, thanks! Can you rebase now on the latest master? Thanks!

[baszalmstra]

I saw it, thanks! Can you rebase now on the latest master? Thanks!

Done!

[traversaro]

Thanks!