Skip to content

ci: add moveit2_rolling.repos for Resolute source-build workarounds#3760

Open
nbbrooks wants to merge 6 commits into
moveit:mainfrom
nbbrooks:nbbrooks/resolute-source-build-repos
Open

ci: add moveit2_rolling.repos for Resolute source-build workarounds#3760
nbbrooks wants to merge 6 commits into
moveit:mainfrom
nbbrooks:nbbrooks/resolute-source-build-repos

Conversation

@nbbrooks

@nbbrooks nbbrooks commented Jun 22, 2026

Copy link
Copy Markdown
Collaborator

Description

Unblocks the rolling-resolute (experimental) CI job, which has been failing at rosdep install with errors like E: Unable to locate package ros-rolling-warehouse-ros-sqlite since the Rolling-on-Resolute transition.

Five moveit2 dependencies (one transitive) are released in rosdistro for Rolling but have no Resolute apt binary yet:

Package Rolling release Pulled in by Removal trigger
ompl 1.7.0-3 moveit2 direct dep Watch Rolling status page for ros-rolling-ompl on Resolute
osqp_vendor 0.2.0-4 moveit2 direct dep Same — gated on tier4/osqp_vendor#25 (osqp 1.0 migration) per tier4/osqp_vendor#26
ros_industrial_cmake_boilerplate 0.5.4-2 transitive (stomp build_depend) Watch Rolling status page for ros-rolling-ros-industrial-cmake-boilerplate
stomp 0.1.2-4 moveit2 direct dep Watch Rolling status page for ros-rolling-stomp
warehouse_ros_sqlite 1.0.7-2 moveit2 direct dep Watch Rolling status page for ros-rolling-warehouse-ros-sqlite

Changes

  1. moveit2_rolling.repos — new file. The CI workflow already supports per-distro source-build .repos files via the mechanism introduced in #3743:

    UPSTREAM_WORKSPACE: >
      moveit2.repos
      $(f="moveit2_$(sed 's/-.*$//' <<< "${{ matrix.env.IMAGE }}").repos"; test -r $f && echo $f)

    For IMAGE: rolling-resolute, this loads moveit2_rolling.repos in addition to the base moveit2.repos. Each entry pins the rosdistro release: version exactly.

  2. .github/workflows/ci.yaml — add DOCKER_RUN_OPTS: '-e CMAKE_POLICY_VERSION_MINIMUM=3.5' to the rolling-resolute matrix entry. osqp_vendor 0.2.0 uses ExternalProject_Add to fetch and build OSQP v0.6.2, whose CMakeLists.txt has cmake_minimum_required(3.2). CMake 4 (default on Resolute) hard-errors on pre-3.5 compatibility. The CMAKE_POLICY_VERSION_MINIMUM=3.5 escape hatch only works if it's set as an environment variable — passing it via -DCMAKE_POLICY_VERSION_MINIMUM=3.5 does not propagate through ExternalProject_Add to the bundled OSQP sub-build. Setting it as an env var via DOCKER_RUN_OPTS means 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):

Test Result
colcon build --packages-select osqp_vendor (no flag) ❌ as expected — Compatibility with CMake < 3.5 has been removed
colcon build --packages-select osqp_vendor --cmake-args -DCMAKE_POLICY_VERSION_MINIMUM=3.5 ❌ same error (flag doesn't propagate through ExternalProject)
CMAKE_POLICY_VERSION_MINIMUM=3.5 colcon build --packages-select osqp_vendor ✅ builds libosqp.so, installs osqp_vendorConfig.cmake
rosdep install --from-paths upstream_ws/src (with all 5 source-built) #All required rosdeps installed successfully
CMAKE_POLICY_VERSION_MINIMUM=3.5 colcon build --packages-up-to moveit_core ✅ all upstream + moveit_core built clean, real osqp::osqp linked

Convention

This follows .github/DISTRO_COMPAT_POLICY.md §2.1 (CI source-build via .repos). Each entry carries an inline removal-trigger comment; both the osqp_vendor entry and the CMAKE_POLICY_VERSION_MINIMUM env var get retired together when the upstream osqp situation resolves and a Resolute deb appears.

Checklist

  • Required by CI: Code is auto formatted (YAML; pre-commit hooks pass)
  • Extend the tutorials / documentation — N/A
  • Document API changes relevant to the user in the MIGRATION.md notes — N/A (CI-only)
  • Create tests, which fail without this PR — N/A
  • Include a screenshot if changing a GUI — N/A

@nbbrooks nbbrooks force-pushed the nbbrooks/resolute-source-build-repos branch 3 times, most recently from 7c2528f to ada701e Compare June 22, 2026 05:39
@codecov

codecov Bot commented Jun 22, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 16.66667% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 46.25%. Comparing base (d98fc1f) to head (991570c).
⚠️ Report is 1 commits behind head on main.

Files with missing lines Patch % Lines
...planning_rviz_plugin/src/motion_planning_frame.cpp 0.00% 3 Missing ⚠️
...ing_rviz_plugin/src/interactive_marker_display.cpp 0.00% 1 Missing ⚠️
...g_scene_rviz_plugin/src/planning_scene_display.cpp 0.00% 1 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@nbbrooks nbbrooks force-pushed the nbbrooks/resolute-source-build-repos branch 3 times, most recently from 27ffd6c to 2d01c1e Compare June 22, 2026 10:12
@urfeex

urfeex commented Jun 23, 2026

Copy link
Copy Markdown

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.

nbbrooks and others added 6 commits June 24, 2026 10:50
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>
@nbbrooks nbbrooks force-pushed the nbbrooks/resolute-source-build-repos branch from 991570c to 96fc4ce Compare June 24, 2026 02:50
@nbbrooks nbbrooks linked an issue Jun 26, 2026 that may be closed by this pull request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Lyrical Luth/Rolling Ament changes and cmakelist incompatibility.

2 participants