BrettRD/ros-gst-bridge

CI improvements

Opened this issue · 4 comments

Basic CI is up, it confirms the code builds, but nothing else.

  • add a basic automated CI framework
  • add a CI job to check the dockerfiles in particular
  • Create a testing package
  • Build with gst_bridge -werror
  • Test gst-inspect-1.0 can load the plugin
  • Basic functional testing
  • Unit testing
  • Collect past issues into regression tests
  • Code coverage
  • Fuzzing with hypothesis

Please add suggestions below

Test gst-inspect-1.0 can load the plugin

This works provided the path where the plugin is built (ros2_ws/install/lib/) are added to LD_LIBRARY_PATH and to GST_PLUGIN_PATH.

Thanks for the check, I don't think CI has run in a while
This checklist is for automated testing through github runners, I'd like to maintain a colcon test command that confirms the pipeline safely enters playback and moves a few image frames

I've been meaning to do something similar for a while now. I think there are broadly two approaches to functional testing of such a ROS-Gstreamer pipeline:

  1. The ROS way: (your suggestion) using colcon test to wrap pipeline execution checks.
  2. The GStreamer way: use gst-validate or a similar pipeline-level test framework and communicate results with a CI tool like Jenkins.

Both approaches would need test content (ex. a rosbag) that is fed to the pipeline and/or a topic monitor that checks that the pipeline spews out ros images/etc.

I'll have a dig at this in the coming weeks.

I'm aiming for a major release from the feat_modular branch very soon, it has a much more sensible pipeline handler and a basic colcon test configuration you can work with