An attempt at a minimal, opinionated ROS workspace that can be built and tested using GitLab CI
This has been made for experimental use on a bare-metal server, so configuration for Docker, more complicated mock hardware systems, or really any non-trivial setup would likely need some more work.
The expected testing cases for a sensible robot project would be something like:
- Unit/library tests, which test library code and functions in isolation from the ROS system. These tests are primarily simple
gtesttests. - Integration tests, which spin up more complicated test cases. These tests make use of
rostestandgtest. - Acceptance tests, which spin up the entire system and manipulate it externally. While this can be done using any number of communication protocols, I've chosen HTTP as it plays nice with everyone.
This testing setup makes use of a few tools which are assumed to be pre-installed on the target machine. The tools used are:
- ROS and Catkin for the builds and the actual project, and ROS GTest for testing. I've put in flags for checking for Kinetic or Melodic. This was built with a server deployment in mind, so I've used
sudo apt-get install ros-{DISTRO}-ros-baseas the base installation - xsltproc for parsing JUnit test output into HTML
- Gitlab Pages for displaying said HTML pages
- Newman for running acceptance tests.
newmanrequires NodeJS as a pre-requisite
If you are trying to run this on a local server, to get Pages to run you will need a DNS server if you don't have one already - dnsmasq or bind9 worked for me.
Be first sure your GitLab instance is set up fully with a Runner and Pages both working. Being able to build and view one of the example GitLab page repos is a good indication things are working.
Make a new CI project from the Github source. Then, go to CI and start a pipeline. Gitlab should pick up the .gitlab-ci.yml file and start building the phases. Once completed, go to Pages in the Project overview, and you should have a rough hewn page containing all the results.
- This has only been tested with a single remote repository setup. Multiple remotes will likely need to have some of the static site generation code reworked.
Props to all the Open Source authors that make this stuff possible.
Also to nlohmann's JSON C++ lib which I've used as an example submodule - its an excellent library.
XML parsing adapted from wadefelix's XML style sheet - cheers buddy!