ci: unblock and broaden the ros2 matrix for Rolling/Resolute by nbbrooks · Pull Request #301 · PickNikRobotics/rviz_visual_tools

nbbrooks · 2026-08-02T21:53:39Z

Why

CI on ros2 currently reports nothing useful. Three problems stack.

1. No `fail-fast: false`

The matrix omits it, so it defaults to true. The rolling job fails in ~60s (problem 2) and GitHub cancels every sibling before it can finish. From #300, run 30764760558 attempt 3:

Job	Window	Result
`rolling-main + ccov`	20:49:41 → 20:50:45	failure
`humble-main`	20:49:47 → 20:50:51	cancelled
`humble-testing`	20:49:47 → 20:50:52	cancelled
`rolling-testing`	20:49:41 → 20:50:52	cancelled

Re-running reproduced it exactly. One broken-by-environment job was discarding three jobs' worth of signal.

2. `rolling` + `ROS_REPO: main` cannot work on Resolute

Rolling's base OS moved to Ubuntu Resolute, and Rolling's main apt repo has no Resolute packages yet — the job dies in setup, before CMake:

'sudo apt-get install ... ros-rolling-ros-environment' returned with 100
'setup_rosdep' returned with code '100' after 0 min 7 sec

Not PR-specific — #297 fails the identical job.

3. Three released distros had no CI at all

This repo ships a single ros2 branch to five distros but tested two. jazzy (4.1.4-4), kilted (4.1.4-4) and lyrical (4.1.4-5) are all released from this branch with zero coverage. Unlike moveit2 — which can omit distros from main because it maintains per-distro branches — there's no second branch here to pick up the slack.

That gap lands exactly where it hurts for the Qt work: jazzy and kilted are Ubuntu Noble, the platform where Qt5 and Qt6 can be installed side by side — precisely what the rviz-version Qt gate in #300 guards against. humble covers jammy/Qt5 and rolling covers resolute/Qt6; the interesting middle was untested.

How

distro	base OS	`ROS_REPO`	Qt	blocking
humble	jammy	main + testing	Qt5	✅
jazzy	noble	main	Qt5	✅
kilted	noble	main	Qt5	✅
lyrical	resolute	main	Qt6	✅
rolling	resolute	testing	Qt6	⚠️ non-blocking (+ccov)

fail-fast: false.
rolling → ROS_REPO: testing, with OS_CODE_NAME: resolute pinned explicitly rather than relying on industrial_ci's default (that default has changed before).
rolling marked non-blocking, matching the policy moveit2 applies to its own rolling-resolute job ("non-blocking until all Resolute packages are released"). CCOV rides on this job, so coverage is non-blocking too.
Added jazzy, kilted, lyrical.

lyrical is Resolute and released, so its main repo is populated. That gives a blocking Qt6-on-Resolute job that should stay green, instead of leaving all Qt6 coverage on the non-blocking rolling job.

continue-on-error is placed on the job, which is valid here because this is a step-based job — it would be silently ignored on a job that calls a reusable workflow via uses:.

Restore the rolling + main entry, and drop the NONBLOCKING flag, once Rolling publishes to main for Resolute.

Expected result

humble-*, jazzy, kilted and lyrical should all report. The rolling job may stay red during the transition without blocking.

Note the new jazzy/kilted/lyrical jobs build the current ros2 branch, which still has the unconditional find_package(Qt5). On lyrical (Resolute/Qt6) that is expected to fail with:

CMake Error: The INTERFACE_QT_MAJOR_VERSION property of "Qt5::Core" does
not agree with the value of QT_MAJOR_VERSION already determined

That is the bug #300 fixes — this PR makes it visible rather than cancelled. Merge order: this PR first, then rebase #300 on top so its Qt change is finally validated against real jazzy/kilted/lyrical jobs.

🤖 Generated with Claude Code

Three problems, all of which make CI on `ros2` uninformative today. 1. fail-fast The matrix had no `fail-fast: false`, so it defaulted to true. The rolling job fails in ~60s (problem 2) and GitHub then cancels every sibling before it can report. From PR #300, run 30764760558 attempt 3: rolling-main + ccov 20:49:41 -> 20:50:45 failure humble-main 20:49:47 -> 20:50:51 cancelled humble-testing 20:49:47 -> 20:50:52 cancelled rolling-testing 20:49:41 -> 20:50:52 cancelled The matrix reported nothing at all, and re-running reproduced it exactly. 2. rolling + ROS_REPO: main on Resolute Rolling's base OS moved to Ubuntu Resolute. Rolling's `main` apt repo has no Resolute packages yet, so the job dies before CMake: 'sudo apt-get install ... ros-rolling-ros-environment' returned with 100 'setup_rosdep' returned with code '100' after 0 min 7 sec Not PR-specific: PR #297 fails the identical job. Switch it to `testing`, which does work on Resolute, and pin OS_CODE_NAME explicitly rather than relying on industrial_ci's default -- that default has changed before. Mark it non-blocking, matching the policy moveit2 applies to its own rolling-resolute job ("non-blocking until all Resolute packages are released"). CCOV rides on this job, so coverage is non-blocking too. 3. Three released distros had no CI at all This repo ships a single `ros2` branch to five distros but only tested two. jazzy (4.1.4-4), kilted (4.1.4-4) and lyrical (4.1.4-5) are all released from this branch with zero coverage. Unlike moveit2 -- which can omit distros from `main` because it maintains per-distro branches -- there is no second branch here to pick up the slack. That gap lands exactly on the case that matters most for the Qt work: jazzy and kilted are Ubuntu Noble, the platform where Qt5 and Qt6 can be installed side by side, which is precisely what the rviz-version Qt gate in CMakeLists guards against. humble covers jammy/Qt5 and rolling covers resolute/Qt6; the interesting middle was untested. lyrical is Resolute and released, so its `main` repo is populated -- it gives a blocking Qt6-on-Resolute job that should stay green, instead of leaving all Qt6 coverage on the non-blocking rolling job. Restore the rolling+main entry once Rolling publishes to `main` for Resolute, and drop the NONBLOCKING flag at the same time. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

nbbrooks · 2026-08-02T22:21:17Z

Failure are expected due to missing buildfarm releases.

tf2_ros::TransformBroadcaster used to accept a node pointer through a set of constructor overloads marked [[deprecated("Use rclcpp::node_interfaces::NodeInterfaces instead of NodeT")]] guarded by std::enable_if_t<rcpputils::is_pointer<NodeT>::value, bool>. ros2/geometry2#940 "Removed deprecated code" (ahcorde, merged 2026-07-01, +0/-978 across 13 files) deleted them. What remains takes rclcpp::node_interfaces::NodeInterfaces<NodeParametersInterface, NodeTopicsInterface>, which calls get_node_*_interface() directly on whatever it is handed -- so a std::shared_ptr<rclcpp::Node> no longer satisfies it: /opt/ros/rolling/include/rclcpp/rclcpp/node_interfaces/node_topics_interface.hpp:99:1: error: 'const class std::shared_ptr<rclcpp::Node>' has no member named 'get_node_topics_interface' 99 | RCLCPP_NODE_INTERFACE_HELPERS_SUPPORT( rclcpp::node_interfaces::NodeTopicsInterface, topics) Dereference instead. The remaining constructor is templated on node type and accepts a node reference on every supported distro, so no version guard is needed -- and this is the migration the deprecation notice asked for. First shipped in tf2_ros 0.46.2: 0.46.1 pointer ctor present -> old form compiles 0.46.2 removed by #940 -> old form fails 0.46.3 removed -> old form fails Verified by compiling both forms against each distro's real headers: distro (node) (*node) humble ok ok jazzy ok ok rolling osrf/ros:rolling-desktop ok ok (tf2_ros 0.46.1) rolling ros-testing on resolute FAILS ok (tf2_ros 0.46.3) Note the prebuilt rolling desktop image still ships 0.46.1 and therefore still accepts the old form; only the current ros-testing packages on Resolute reject it, which is what CI builds against. Surfaced by the rolling-testing job on #300 once #301 stopped fail-fast from cancelling it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

tf2_ros::TransformBroadcaster used to accept a node pointer through a set of constructor overloads marked [[deprecated("Use rclcpp::node_interfaces::NodeInterfaces instead of NodeT")]] guarded by std::enable_if_t<rcpputils::is_pointer<NodeT>::value, bool>. ros2/geometry2#940 "Removed deprecated code" (ahcorde, merged 2026-07-01, +0/-978 across 13 files) deleted them. What remains takes rclcpp::node_interfaces::NodeInterfaces<NodeParametersInterface, NodeTopicsInterface>, which calls get_node_*_interface() directly on whatever it is handed -- so a std::shared_ptr<rclcpp::Node> no longer satisfies it: /opt/ros/rolling/include/rclcpp/rclcpp/node_interfaces/node_topics_interface.hpp:99:1: error: 'const class std::shared_ptr<rclcpp::Node>' has no member named 'get_node_topics_interface' 99 | RCLCPP_NODE_INTERFACE_HELPERS_SUPPORT( rclcpp::node_interfaces::NodeTopicsInterface, topics) Dereference instead. The remaining constructor is templated on node type and accepts a node reference on every supported distro, so no version guard is needed -- and this is the migration the deprecation notice asked for. First shipped in tf2_ros 0.46.2: 0.46.1 pointer ctor present -> old form compiles 0.46.2 removed by #940 -> old form fails 0.46.3 removed -> old form fails Verified by compiling both forms against each distro's real headers: distro (node) (*node) humble ok ok jazzy ok ok rolling osrf/ros:rolling-desktop ok ok (tf2_ros 0.46.1) rolling ros-testing on resolute FAILS ok (tf2_ros 0.46.3) Note the prebuilt rolling desktop image still ships 0.46.1 and therefore still accepts the old form; only the current ros-testing packages on Resolute reject it, which is what CI builds against. Surfaced by the rolling-testing job on #300 once #301 stopped fail-fast from cancelling it. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Three problems, mirroring the fix landed in PickNikRobotics/rviz_visual_tools#301. 1. fail-fast The matrix had no `fail-fast: false`, so it defaulted to true. When the rolling job fails (problem 2), GitHub cancels every sibling before it can report, and the matrix produces no signal at all. 2. rolling + ROS_REPO: main on Resolute Rolling's base OS moved to Ubuntu Resolute. With no OS_CODE_NAME pinned, industrial_ci builds rolling on ubuntu:resolute -- and Rolling's `main` apt repo has no Resolute packages yet, so the job dies before CMake: 'sudo apt-get install ... ros-rolling-ros-environment' returned with 100 'setup_rosdep' returned with code '100' Switch it to `testing`, which does work on Resolute, and pin OS_CODE_NAME explicitly rather than relying on industrial_ci's default -- that default has already changed once. Mark it non-blocking until the Resolute packages are all released. 3. Three released distros had no CI at all graph_msgs is released to five distros from this single branch but only tested two: humble 0.2.0-3 tested jazzy 0.2.0-6 NOT tested kilted 0.2.0-6 NOT tested lyrical 0.2.0-7 NOT tested rolling 0.2.0-6 tested lyrical is Resolute and released, so its `main` repo is populated -- it gives a blocking Resolute job that should stay green, rather than leaving all Resolute coverage on the non-blocking rolling job. Restore the rolling+main entry, and drop the NONBLOCKING flag, once Rolling publishes to `main` for Resolute. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Three problems, mirroring the fix landed in PickNikRobotics/rviz_visual_tools#301. 1. fail-fast The matrix had no `fail-fast: false`, so it defaulted to true. When the rolling job fails (problem 2), GitHub cancels every sibling before it can report, and the matrix produces no signal at all. 2. rolling + ROS_REPO: main on Resolute Rolling's base OS moved to Ubuntu Resolute. With no OS_CODE_NAME pinned, industrial_ci builds rolling on ubuntu:resolute -- and Rolling's `main` apt repo has no Resolute packages yet, so the job dies before CMake: 'sudo apt-get install ... ros-rolling-ros-environment' returned with 100 'setup_rosdep' returned with code '100' Switch it to `testing`, which does work on Resolute, and pin OS_CODE_NAME explicitly rather than relying on industrial_ci's default -- that default has already changed once. Mark it non-blocking until the Resolute packages are all released. 3. Three released distros had no CI at all graph_msgs is released to five distros from this single branch but only tested two: humble 0.2.0-3 tested jazzy 0.2.0-6 NOT tested kilted 0.2.0-6 NOT tested lyrical 0.2.0-7 NOT tested rolling 0.2.0-6 tested lyrical is Resolute and released, so its `main` repo is populated -- it gives a blocking Resolute job that should stay green, rather than leaving all Resolute coverage on the non-blocking rolling job. Restore the rolling+main entry, and drop the NONBLOCKING flag, once Rolling publishes to `main` for Resolute. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

This repo ships a single `ros2` branch to five distros but only tested two, and neither gave a Resolute signal: humble 4.1.2-1 tested (humble-source image) jazzy 4.1.2-1 NOT tested kilted 4.1.2-2 NOT tested lyrical 4.1.2-3 NOT tested rolling 4.1.2-2 tested (rolling-source image -- see below) Move the whole matrix to plain ROS_DISTRO/ROS_REPO jobs, matching PickNikRobotics/rviz_visual_tools#301 and PickNikRobotics/graph_msgs#20: humble-main jammy blocking jazzy-main noble blocking kilted-main noble blocking (takes over CLANG_TIDY) lyrical-main resolute non-blocking rolling-testing resolute non-blocking The rolling-source job had to go. With a *prebuilt* image, ROS_DISTRO: rolling does not imply Resolute the way it does for a bare-OS job -- the OS comes from the image. moveit/moveit2:rolling-source is Ubuntu noble, built 2026-01-24, with MoveIt compiled inside it, so the job never asked apt for ros-rolling-moveit-core and never touched Resolute. Rolling moved to Resolute, so it was testing a distro/OS pairing that no longer ships, and reporting green for it -- concealing the blocker below. It could not self-heal either: moveit2's docker.yaml is 12 successes to 85 failures, and even its last success (2026-06-24) did not refresh that tag. The usual argument for a source image -- exercising MoveIt main -- was not being served by a January snapshot. Dropping humble-source too keeps the matrix uniform and removes this repo's last dependency on the moveit2 image pipeline. MoveIt is released as debs on every distro here (humble 2.5.9, jazzy 2.12.4, kilted 2.14.3), so binary jobs test what users actually install. moveit_visual_tools.repos still source-builds rviz_visual_tools and graph_msgs, which is where the unreleased fixes live. With no image left, DOCKER_IMAGE, UNDERLAY (and its AFTER_SETUP_UPSTREAM_WORKSPACE_EMBED predecessor) and the IMAGE fallbacks in CACHE_PREFIX / name are all removed as dead plumbing. lyrical and rolling both fail today for the same reason: E: Unable to locate package ros-lyrical-moveit-core Only moveit_common, moveit_configs_utils, moveit_msgs and moveit_resources are published for Resolute; moveit_core is not. That blocks every downstream package on Resolute -- lyrical as well as rolling. Both jobs are non-blocking and will start passing on their own once moveit2 is released there. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

This repo ships a single `ros2` branch to five distros but only tested two, and neither gave a Resolute signal: humble 4.1.2-1 tested (humble-source image) jazzy 4.1.2-1 NOT tested kilted 4.1.2-2 NOT tested lyrical 4.1.2-3 NOT tested rolling 4.1.2-2 tested (rolling-source image -- see below) Move the whole matrix to plain ROS_DISTRO/ROS_REPO jobs, matching PickNikRobotics/rviz_visual_tools#301 and PickNikRobotics/graph_msgs#20: humble-main jammy blocking jazzy-main noble blocking kilted-main noble blocking (takes over CLANG_TIDY) lyrical-main resolute non-blocking rolling-testing resolute non-blocking The rolling-source job had to go. With a *prebuilt* image, ROS_DISTRO: rolling does not imply Resolute the way it does for a bare-OS job -- the OS comes from the image. moveit/moveit2:rolling-source is Ubuntu noble, built 2026-01-24, with MoveIt compiled inside it, so the job never asked apt for ros-rolling-moveit-core and never touched Resolute. Rolling moved to Resolute, so it was testing a distro/OS pairing that no longer ships, and reporting green for it -- concealing the blocker below. It could not self-heal either: moveit2's docker.yaml is 12 successes to 85 failures, and even its last success (2026-06-24) did not refresh that tag. The usual argument for a source image -- exercising MoveIt main -- was not being served by a January snapshot. Dropping humble-source too keeps the matrix uniform and removes this repo's last dependency on the moveit2 image pipeline. MoveIt is released as debs on every distro here (humble 2.5.9, jazzy 2.12.4, kilted 2.14.3), so binary jobs test what users actually install. moveit_visual_tools.repos still source-builds rviz_visual_tools and graph_msgs, which is where the unreleased fixes live. With no image left, DOCKER_IMAGE, UNDERLAY (and its AFTER_SETUP_UPSTREAM_WORKSPACE_EMBED predecessor) and the IMAGE fallbacks in CACHE_PREFIX / name are all removed as dead plumbing. lyrical and rolling both fail today for the same reason: E: Unable to locate package ros-lyrical-moveit-core Only moveit_common, moveit_configs_utils, moveit_msgs and moveit_resources are published for Resolute; moveit_core is not. That blocks every downstream package on Resolute -- lyrical as well as rolling. Both jobs are non-blocking and will start passing on their own once moveit2 is released there. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Four problems, all of which leave CI on `ros2` uninformative today. 1. fail-fast The matrix had no `fail-fast: false`, so it defaulted to true. The rolling-main job fails in ~60s (problem 2) and GitHub then cancels every sibling before it can report. From run 29725301361 on 5e2fd13: rolling-main + ccov 07:39:31 -> 07:40:39 failure rolling-testing 07:39:31 -> 07:40:47 cancelled humble-main 07:39:31 -> 07:40:47 cancelled humble-testing 07:39:32 -> 07:40:47 cancelled iron-main 07:39:31 -> 07:40:47 cancelled iron-testing 07:39:31 -> 07:40:46 cancelled One environmental failure, five results discarded -- including the two humble jobs that would have passed. As a result #62, the only commit on this branch since 1.0.8, had never been validated by CI. 2. rolling + ROS_REPO: main on Resolute Rolling's base OS moved to Ubuntu Resolute, and Rolling's `main` apt repo has no Resolute packages yet, so the job dies in setup before CMake: E: Unable to locate package ros-rolling-ros-environment 'setup_rosdep' returned with code '100' after 0 min 8 sec Switch it to `testing`, which does work on Resolute, and pin OS_CODE_NAME explicitly rather than relying on industrial_ci's default -- that default has already changed once. 3. iron is EOL and this package is not released to it Iron reached EOL in November 2024, and iron/distribution.yaml carries no `release:` version for warehouse_ros_sqlite. A third of the matrix was testing a distro that never ships. 4. Three released distros had no coverage Released from this single `ros2` branch, versus what was tested: humble 1.0.8-1 tested jazzy 1.0.8-1 NOT tested kilted 1.0.8-1 NOT tested lyrical 1.0.8-1 NOT tested rolling 1.0.8-2 tested (broken) Coverage moves off the deleted rolling-main job onto rolling-testing, making it non-blocking -- the same trade PickNikRobotics/rviz_visual_tools#301 made. lyrical gates. It is released, it is Resolute, and ros-lyrical-warehouse-ros is published, so it gives a blocking Resolute signal rather than leaving all Resolute coverage on the non-blocking rolling job. Verified green. rolling stays non-blocking because ros-rolling-warehouse-ros is not published: E: Unable to locate package ros-rolling-warehouse-ros warehouse_ros 2.0.7 carries the tf2 .h -> .hpp fix that unblocks that build; drop NONBLOCKING from rolling once it is on the buildfarm. Note this renames rolling-testing and deletes rolling-main + ccov, both of which are required status checks on `ros2`, so branch protection must be updated to Format, humble-main, humble-testing, jazzy-main, kilted-main, lyrical-main before this can merge. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

nbbrooks mentioned this pull request Aug 2, 2026

CMakeLists: dual-support Qt5 and Qt6 #300

Merged

nbbrooks force-pushed the nbbrooks/ci-resolute-fail-fast branch from fbf9371 to 57eac37 Compare August 2, 2026 22:12

nbbrooks changed the title ~~ci: unblock the ros2 matrix on Rolling/Resolute~~ ci: unblock and broaden the ros2 matrix for Rolling/Resolute Aug 2, 2026

nbbrooks merged commit 61796ab into ros2 Aug 2, 2026
5 of 7 checks passed

nbbrooks mentioned this pull request Aug 2, 2026

tf_visual_tools: pass Node by reference to TransformBroadcaster #302

Merged

This was referenced Aug 3, 2026

ci: unblock and broaden the ros2 matrix for Rolling/Resolute PickNikRobotics/graph_msgs#20

Merged

ci: add distro coverage for jazzy, kilted and lyrical moveit/moveit_visual_tools#157

Merged

nbbrooks mentioned this pull request Aug 12, 2026

ci: cover kilted and lyrical, drop the impossible rolling-main job moveit/warehouse_ros#111

Merged

Navigation Menu

ci: unblock and broaden the ros2 matrix for Rolling/Resolute - #301

ci: unblock and broaden the ros2 matrix for Rolling/Resolute#301
nbbrooks merged 1 commit into
ros2from
nbbrooks/ci-resolute-fail-fast

nbbrooks commented Aug 2, 2026 •

edited

Loading

Uh oh!

nbbrooks commented Aug 2, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

nbbrooks commented Aug 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why

1. No fail-fast: false

2. rolling + ROS_REPO: main cannot work on Resolute

3. Three released distros had no CI at all

How

Expected result

Uh oh!

nbbrooks commented Aug 2, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

nbbrooks commented Aug 2, 2026 •

edited

Loading

1. No `fail-fast: false`

2. `rolling` + `ROS_REPO: main` cannot work on Resolute