ci: add moveit2_rolling.repos for Resolute source-build workarounds#3760
Open
nbbrooks wants to merge 6 commits into
Open
ci: add moveit2_rolling.repos for Resolute source-build workarounds#3760nbbrooks wants to merge 6 commits into
nbbrooks wants to merge 6 commits into
Conversation
7c2528f to
ada701e
Compare
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #3760 +/- ##
==========================================
- Coverage 46.28% 46.25% -0.02%
==========================================
Files 726 726
Lines 59507 59515 +8
Branches 7624 7624
==========================================
- Hits 27536 27523 -13
- Misses 31805 31823 +18
- Partials 166 169 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
27ffd6c to
2d01c1e
Compare
|
I can confirm that this builds and works on Ubuntu Resolute with ROS Rolling :-) I don't necessarily feel competent enough to properly review this since this seems to touch a lot of internals that I am not familiar with. |
The rolling-resolute (experimental) CI job currently fails at rosdep install because several moveit2 dependencies are released in rosdistro but have no Resolute apt binary yet: - ompl (pinned to 2.0.1, ahead of rosdistro 1.7.0-3 — see note) - osqp_vendor 0.2.0 - ros_industrial_cmake_boilerplate 0.5.4 (transitive via stomp) - stomp 0.1.2 - warehouse_ros_sqlite (pinned to ros2 HEAD c3847d5f — see note) The CI workflow already supports per-distro source-build .repos files (introduced for rolling-resolute in moveit#3743). Add moveit2_rolling.repos with the five packages. Three workflow tweaks accompany the .repos additions: - DOCKER_RUN_OPTS injects CMAKE_POLICY_VERSION_MINIMUM=3.5 into the rolling-resolute container so osqp_vendor 0.2.0's ExternalProject_Add of OSQP v0.6.2 (cmake_minimum_required(3.2)) can configure under Resolute's CMake 4. The env-var form propagates through ExternalProject sub-builds; the -D form does not. - ompl is pinned to 2.0.1 instead of the rosdistro release (1.7.0): 1.7.0 calls find_package(Boost COMPONENTS system ...) which Boost 1.90 no longer provides (same shape as moveit2#3727). 2.0.1 dropped Boost from CMakeLists. Tracked upstream at ompl/ompl#1429. - warehouse_ros_sqlite is pinned to ros2 HEAD c3847d5f instead of the rosdistro release (1.0.7): same Boost::system situation, fixed on the ros2 branch but not yet released. Repo also moved from ros-planning/ to moveit/. - SUPPRESS_CPP_ERROR=true on the rolling-resolute matrix entry adds -Wno-error=cpp to CXXFLAGS. System liboctomap-dev's OcTreeKey.h includes the C++20-deprecated <ciso646>, which under GCC 15 + CI's -Werror becomes a fatal build error in moveit_core. The fix (<ciso646> -> <version>) needs to land upstream at OctoMap/octomap and then propagate through Debian repackaging to Ubuntu; until then, drop the -Werror on this category for rolling-resolute. Upstream issue: OctoMap/octomap#434. Documented under .github/DISTRO_COMPAT_POLICY.md §2.1. Each .repos entry and workflow workaround carries a removal trigger; audit on every Rolling sync via https://repo.ros2.org/status_page/ros_rolling_default.html
GCC 15 (default on Ubuntu Resolute / ROS Lyrical) rejects template-id on a constructor declaration with -Werror=template-id-cdtor: error: template-id not allowed for constructor in C++20 59 | PlanningContextBase<GeneratorT>(const std::string& name, ...) Inside a class template, the constructor name shouldn't carry the template-id <GeneratorT> suffix — it's just the class name. Drop the <GeneratorT> redundancy. Behavior is unchanged on every supported distro; the existing form happened to compile under earlier GCC due to DR1004 allowing the construct as a deprecated extension. C++20 explicitly removed that allowance. Surfaces in moveit2's rolling-resolute (experimental) CI under GCC 15.2.0.
GCC 15 (default on Ubuntu Resolute / ROS Lyrical) rejects implicit capture of 'this' via '[=]' with -Werror=deprecated: error: implicit capture of 'this' via '[=]' is deprecated in C++20 Affected lambdas live inside member functions and reference 'this' indirectly through member access (e.g. ui_->...). Replace [=] with explicit captures of the actual values needed plus 'this'. Three sites fixed: - planning_scene_rviz_plugin/src/planning_scene_display.cpp:416 - motion_planning_rviz_plugin/src/motion_planning_frame.cpp:390 - motion_planning_rviz_plugin/src/motion_planning_frame.cpp:427 Behavior is unchanged; only the capture spelling changes. Surfaces in moveit2's rolling-resolute (experimental) CI under GCC 15.2.0.
…0.1+) rviz_common 16.0.1 removed the deprecated update(float, float) overload in favor of update(std::chrono::nanoseconds, std::chrono::nanoseconds) (ros2/rviz#1533, merged 2025-08-18). Our InteractiveMarkerDisplay subclass declared `void update(float, float) override` which no longer matches the base — GCC reports "marked 'override', but does not override". Conditionally compile the new signature on Rolling per .github/ DISTRO_COMPAT_POLICY.md §1.1 (RCLCPP_VERSION_GTE >= 30 = Rolling). Humble (rviz 11), Jazzy (rviz 14), and Kilted (rviz 15) still ship update(float, float) as the canonical signature, so they keep the old form. The body discards both args either way — only the signature changes. Remove the #if branch when Kilted goes EOL (last distro on rviz < 16).
The pilz_industrial_motion_planner_test_utils library is built in the test/ subdirectory but never installed. The installed unit-test binaries at lib/pilz_industrial_motion_planner/ load it implicitly, so they need it on a runtime search path. On Resolute (Ubuntu 26.04, CMake 4.2) the installed test binaries fail at load with: unittest_trajectory_functions: error while loading shared libraries: libpilz_industrial_motion_planner_test_utils.so: cannot open shared object file: No such file or directory Earlier distros tolerate the missing install because the build-tree path remains visible to the loader (build-rpath, ament-cmake test wrapper behavior, or similar). The fix is the same on every distro: install the library alongside the test binaries so $ORIGIN-based RPATH resolves it. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
…ute CI On Rolling/Resolute (Ubuntu 26.04) this gtest deadlocks at runtime when WarehouseFixture loads warehouse_ros_sqlite and connects to a :memory: database. Confirmed not a slow run — still hangs at a 300s timeout; the same binary runs in ~0.3s on Rolling/Noble. Root cause is platform-side (sqlite, pluginlib, or rclcpp shutdown on Resolute) and out of scope for this repo. Guard the gtest in CMake with an explicit /etc/os-release codename check so the rolling-resolute job can go green. Remove the guard when the deadlock is identified and fixed upstream. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
991570c to
96fc4ce
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Unblocks the
rolling-resolute (experimental)CI job, which has been failing atrosdep installwith errors likeE: Unable to locate package ros-rolling-warehouse-ros-sqlitesince the Rolling-on-Resolute transition.Five moveit2 dependencies (one transitive) are released in rosdistro for Rolling but have no Resolute apt binary yet:
ompl1.7.0-3ros-rolling-omplon Resoluteosqp_vendor0.2.0-4ros_industrial_cmake_boilerplate0.5.4-2stompbuild_depend)ros-rolling-ros-industrial-cmake-boilerplatestomp0.1.2-4ros-rolling-stompwarehouse_ros_sqlite1.0.7-2ros-rolling-warehouse-ros-sqliteChanges
moveit2_rolling.repos— new file. The CI workflow already supports per-distro source-build.reposfiles via the mechanism introduced in #3743:For
IMAGE: rolling-resolute, this loadsmoveit2_rolling.reposin addition to the basemoveit2.repos. Each entry pins the rosdistrorelease:version exactly..github/workflows/ci.yaml— addDOCKER_RUN_OPTS: '-e CMAKE_POLICY_VERSION_MINIMUM=3.5'to therolling-resolutematrix entry.osqp_vendor 0.2.0usesExternalProject_Addto fetch and build OSQP v0.6.2, whose CMakeLists.txt hascmake_minimum_required(3.2). CMake 4 (default on Resolute) hard-errors on pre-3.5 compatibility. TheCMAKE_POLICY_VERSION_MINIMUM=3.5escape hatch only works if it's set as an environment variable — passing it via-DCMAKE_POLICY_VERSION_MINIMUM=3.5does not propagate throughExternalProject_Addto the bundled OSQP sub-build. Setting it as an env var viaDOCKER_RUN_OPTSmeans every CMake invocation inside the container (including ExternalProject sub-builds) sees it.Verification
Tested locally on
ubuntu:resolute(CMake 4.2.3, GCC 15.2.0):colcon build --packages-select osqp_vendor(no flag)Compatibility with CMake < 3.5 has been removedcolcon build --packages-select osqp_vendor --cmake-args -DCMAKE_POLICY_VERSION_MINIMUM=3.5CMAKE_POLICY_VERSION_MINIMUM=3.5 colcon build --packages-select osqp_vendorlibosqp.so, installsosqp_vendorConfig.cmakerosdep install --from-paths upstream_ws/src(with all 5 source-built)#All required rosdeps installed successfullyCMAKE_POLICY_VERSION_MINIMUM=3.5 colcon build --packages-up-to moveit_coremoveit_corebuilt clean, realosqp::osqplinkedConvention
This follows
.github/DISTRO_COMPAT_POLICY.md§2.1 (CI source-build via.repos). Each entry carries an inline removal-trigger comment; both theosqp_vendorentry and theCMAKE_POLICY_VERSION_MINIMUMenv var get retired together when the upstream osqp situation resolves and a Resolute deb appears.Checklist