test_ros_launch.py in blueboat_gazebo and bluerov2_gazebo is skipped in CI as a short-term bypass (#68), so unrelated PRs are not blocked. It still runs locally in drydock and passes there.
IMHO this is an example of two foundational issues: 1) We have never decided on a common development environment (so everyone is using different combinations of rosdep, vcs, docker, pip, pixie, apt and git (source) installs) and 2) the CI maturity outpaces the project maturity, so we have to unnecessarily deal with CI failures too early in the process. The CI should just check the bare bones basics for now and should be based on the common dev environment which we never agreed to. This issue is an attempt to move when we address these issues further into the future so they don't slow us down.
What fails
component_container exits at startup with:
symbol lookup error: /opt/ros/lyrical/lib/libsimulation_interfaces__rosidl_typesupport_fastrtps_c.so: undefined symbol: has_buffer_fields_unique_identifier_msgs__msg__UUID
so the ROS–Gazebo bridge never comes up, and the tests report "no /clock over the bridge", "no latched description" and "topic not bridged".
Why
A version skew in CI's environment, not a change in this repository. bsb/sitl_phase3, which contains all of #68, passed on 2026-09-18.
- The
ros:lyrical-ros-base image preinstalls ros-lyrical-unique-identifier-msgs 2.8.1-3resolute.20260811.
- rosdep then installs
ros-lyrical-simulation-interfaces 2.1.0-3resolute.20260915, built against the 2026-09-15 rebuild of unique-identifier-msgs — also 2.8.1, with new symbols.
- rosdep installs what is missing and does not upgrade what is present, so the older library stays.
Nothing fails at install or build time; it shows up only at runtime, three layers from the cause.
The bypass
.github/workflows/ci.yml, Test step: --ctest-args -E test_ros_launch. Every other test, including both test_gz_launch suites, still runs.
Likely fix, when someone picks this up
apt-get upgrade -y after apt-get update in the CI job, so the image's preinstalled ROS packages come up to the same sync as what rosdep adds — or a newer base image once one is published. Then remove the -E test_ros_launch.
Part of the broader CI question in #66.
test_ros_launch.pyinblueboat_gazeboandbluerov2_gazebois skipped in CI as a short-term bypass (#68), so unrelated PRs are not blocked. It still runs locally in drydock and passes there.IMHO this is an example of two foundational issues: 1) We have never decided on a common development environment (so everyone is using different combinations of rosdep, vcs, docker, pip, pixie, apt and git (source) installs) and 2) the CI maturity outpaces the project maturity, so we have to unnecessarily deal with CI failures too early in the process. The CI should just check the bare bones basics for now and should be based on the common dev environment which we never agreed to. This issue is an attempt to move when we address these issues further into the future so they don't slow us down.
What fails
component_containerexits at startup with:so the ROS–Gazebo bridge never comes up, and the tests report "no /clock over the bridge", "no latched description" and "topic not bridged".
Why
A version skew in CI's environment, not a change in this repository.
bsb/sitl_phase3, which contains all of #68, passed on 2026-09-18.ros:lyrical-ros-baseimage preinstallsros-lyrical-unique-identifier-msgs2.8.1-3resolute.20260811.ros-lyrical-simulation-interfaces2.1.0-3resolute.20260915, built against the 2026-09-15 rebuild ofunique-identifier-msgs— also 2.8.1, with new symbols.Nothing fails at install or build time; it shows up only at runtime, three layers from the cause.
The bypass
.github/workflows/ci.yml, Test step:--ctest-args -E test_ros_launch. Every other test, including bothtest_gz_launchsuites, still runs.Likely fix, when someone picks this up
apt-get upgrade -yafterapt-get updatein the CI job, so the image's preinstalled ROS packages come up to the same sync as what rosdep adds — or a newer base image once one is published. Then remove the-E test_ros_launch.Part of the broader CI question in #66.