feat: add github action to cut release and preserve distribution cache

[asymingt]

Duplicates: #42984

This adds a new release-cutting GitHub action, which automatically tags a release for us. Specifically, it regenerates the distribution cache tarball for the release, and then pushes an orphaned commit that updates the keys in index-v4.yamland index.yaml to point to the release artifact in GitHub. Finally it tags this commit, an bundles the updated yamls and distribution cache alongside it as artifacts. Example:

The action is triggered manually through the github Action tab, by clicking on Cut a new ROS release and then using the drop-down manual menu item to select the distribution and date stamp.

One Lyrical merges I will submit a follow-on PR to automatically manage sync holds for us. Including this as part of this PR is too complicated and hard to review.

[github-actions]

Thanks for sending a pull request to ROS distro!

This is an automated tool that helps check your pull request for correctness.
This tool checks a number of attributes associated with your ROS package and generates a report that helps our reviewers merge your pull request in a timely fashion. Here are a few things to consider when sending adding or updating a package to ROS Distro.
ROS Distro includes a very helpful CONTRIBUTING.md file that we recommend reading if it is your first time submitting a package.
Please also read the ROS Distro review guidelines which summarizes this release process.

ROS Distro Considerations

• ROS Distributions are created using REP-134 Standards Track as a guide.
• Your package name should comply to REP-144 ROS Package Naming
• Your package must build for all platforms and architectures on the ROS buildfarm. See REP-2000 ROS Releases and Supported Platforms for all supported platforms for your ROS Distro.
• Your package must contain an OSI approved license. Your package.xml file must also include that license in a machine readable format. See REP-149 Package Manifest Format Three Specification for additional details.
• A publicly available, open source, repository for your ROS package.
• While not required, we recommend that you create an account for ROS Discourse and subscribe to the appropriate release topic.
• If you would like, you may join our Zulip Server and ask questions in the Infrastructure General channel.

Package Considerations

Having your package included in a ROS Distro is a badge of quality, and we recommend that package developers strive to create packages of the highest quality. We recommend package developers review the following resources before submitting their package.

• REP-2004 Package Quality Declaration-- The ROS 2 TSC has created a quality rating system for ROS packages. These ratings should serve as a guide for package developers. We recommend package developers achieve a quality level of three or higher.
• Documentation -- it is recommended that ROS packages include an extensive README.md file, and API level documentation using the Sphinx documentation system.
• Maintainer Responsibilities -- the ROS 2 documentation includes a guide to ROS package maintainer responsibilities that summarizes your responsibilities as an open source maintainer. While we do not enforce these requirements on package maintainers they should be considered best practices.
• We recommend that your package should strive to conform to the ROS 2 Developer Guide and the ROS 2 Style Guide.

Need Help?

Please post your questions to Robotics Stack Exchange or refer to the Infrastructure General channel on our Zulip server.

---

For changes related to yamllint:

• ❌ One or more linter violations were added to YAML files

[github-actions]

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[github-actions]

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[ros-discourse]

This pull request has been mentioned on Open Robotics Discourse. There might be relevant details there:

https://discourse.openrobotics.org/t/ros-pmc-minutes-for-march-17-2026/53310/1

[tfoote]

As we discussed in the ROS PMC meeting the use of a visible variable in the distro index itself seems to make the most sense to make sure things are visible.

To that end it was suggested sync_status to mirror distribution_status

rosdistro/index-v4.yaml

Line 93 in d0ceb4c

distribution_status: active

However I would suggest that we think of it more holsitically as it's more about what's the syncs status is. Potentially:

merge_policy: [open, regression_fix_only, closed]

• Open means merges accepted, please submit
• Regression fix only is our sync freeze but not using our jargon.
• Where closed is when you're at EOL or otherwise in a code freeze.

In the future we could add some new merge policies. We can define these in the contributor guide and it will be clear what it means to users, versus using the name of the process that we think about.

[asymingt]

As we discussed in the ROS PMC meeting the use of a visible variable in the distro index itself seems to make the most sense to make sure things are visible.

To that end it was suggested sync_status to mirror distribution_status

rosdistro/index-v4.yaml

Line 93 in d0ceb4c

distribution_status: active

However I would suggest that we think of it more holsitically as it's more about what's the syncs status is. Potentially:

merge_policy: [open, regression_fix_only, closed]

• Open means merges accepted, please submit
• Regression fix only is our sync freeze but not using our jargon.
• Where closed is when you're at EOL or otherwise in a code freeze.

In the future we could add some new merge policies. We can define these in the contributor guide and it will be clear what it means to users, versus using the name of the process that we think about.

Will do this in a follow on, and keep the focus of this PR on release-cutting with distribution cache preservation.

[github-actions]

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[github-actions]

For changes related to yamllint:

• ✅ All new lines of YAML pass linter checks

[cottsay]

This workaround can't make it into production. If there's a bug in the index, it should be fixed.

[asymingt]

Great point. I forgot about this step in the workflow. It won't be needed going forward as the GBP repos are correct on master. I needed this workaround when trying to rebuild a distribution cache for an older release in 2025. Fixing the error in the way you suggest would be rewriting git history, which I assume can't happen. Is it ok if I just remove this step completely?

[cottsay]

Why are we force-pushing to rosdistro?

[asymingt]

To overwrite an existing tag from the past if we choose to update it to include the distribution cache artifacts. If we plan to use this action strictly for future releases then it should be fine to remove the force in this command. Would that work for you?