CI improvements

[BrettRD]

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

• [x] 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

[sandman]

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.

[BrettRD]

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

[sandman]

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.

[BrettRD]

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