I don’t know if it could be said as an advantage over those CI. But the reason my team creates this is because we need a CI with a workflow that we usually do when developing a ROS 2 package. Usually, we develop it on a standard Ubuntu system with the latest LTS. That system already exists as a docker image as in the link that i previously mentioned. But it came at a cost, there’s still no Docker image for Windows, Mac, or other OS that’s currently supported by the ROS 2.
Another thing is dependency management. I know there exist rosdep which handles dependency management for a ROS 2 package, but we rarely use that. We prefer to define everything that we need to install either by calling apt, pip, etc.
Also, when the package has other dependencies with our personal package that does not include in the repository, the build process will always fail. We solved that issue by introducing a custom command that could be called anywhere during the process. by providing command in the pre-build, we could clone the external repository to be included in the build workspace.
In short, by using this, the workflow of the build, and test process is more customized according to our need and resembles the workflow that is usually done when building and testing ROS 2 in a standar system (Ubuntu LTS).
