Interfacing BebopS with TravisCI

In this wiki, section is illustrated the employed solution to link the continuous integration (CI) open-source platform TravisCI with the BebopS repository. Moreover, it is described as the corresponding advantages that a CI system may give when developing a ROS component like BebopS.

In the Listing below is reported the script used to configure the BebopS repository with TravisCI. The code is based on an existing open-source project and has been customized to make it compatible with the Kinetic Kame distro of ROS.

# Use ubuntu xenial (16.04) with sudo privileges.
os: linux
dist: xenial
sudo: required

language:
 - generic
cache:
 - apt

# Configuration variables. All variables are global now, but this can be used to
# trigger a build matrix for different ROS distributions if desired.
env:
 global:
   - ROS_DISTRO=kinetic
   - ROS_CI_DESKTOP="`lsb_release -cs`"  # e.g. [precise|trusty|...]
   - CI_SOURCE_PATH=$(pwd)
   - ROSINSTALL_FILE=$CI_SOURCE_PATH/dependencies.rosinstall
   - CATKIN_OPTIONS=$CI_SOURCE_PATH/catkin.options
   - ROS_PARALLEL_JOBS='-j8 -l6'
   # Set the python path manually to include /usr/-/python2.7/dist-packages
   # as this is where apt-get installs python packages.
   - PYTHONPATH=$PYTHONPATH:/usr/lib/python2.7/dist-packages:/usr/local/lib/python2.7/dist-packages

################################################################################

# Install system dependencies, namely a very barebones ROS setup.
before_install:
 - sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $ROS_CI_DESKTOP main" > /etc/apt/sources.list.d/ros-latest.list'
 - wget http://packages.ros.org/ros.key -O - | sudo apt-key add -
 - sudo rm /var/lib/dpkg/lock
 - sudo dpkg --configure -a
 - sudo apt-get update
 - sudo apt-get install ros-$ROS_DISTRO-desktop-full ros-$ROS_DISTRO-joy ros-$ROS_DISTRO-octomap-ros 
 - sudo apt-get install python-wstool python-catkin-tools
 - sudo apt-get install protobuf-compiler libgoogle-glog-dev
# Prepare rosdep to install dependencies.  
 - sudo rosdep init 
 - rosdep update
 - source /opt/ros/$ROS_DISTRO/setup.bash
 
# Create a catkin workspace with the package under integration.
install:
 - mkdir -p ~/catkin_ws/src
 - cd ~/catkin_ws/src
 - catkin_init_workspace
 - wstool init
 # Create the devel/setup.bash (run catkin_make with an empty workspace) and
 # source it to set the path variables.
 - git clone https://github.com/gsilano/BebopS.git
 - git clone https://github.com/gsilano/rotors_simulator.git
 - git clone https://github.com/gsilano/mav_comm.git
 - git clone https://github.com/gsilano/med_aerial_challenge_launch.git
 - git clone https://github.com/gsilano/bebop_autonomy.git
 - cd ~/catkin_ws/src/rotors_simulator 
 - git checkout med18
 - cd ~/catkin_ws/src/mav_comm 
 - git checkout med18
 - rosdep update
 - cd ~/catkin_ws
 - rosdep install --from-paths src -i
 - catkin build
 - echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc
 - source ~/.bashrc

In order to use TravisCI, a GitHub account and the TravisCI script are all the necessary components. The script, i.e., the .travis.yml file, has to be put in the root of the active repository (for students or academics, GitHub gives the possibility to build infinite private builds, 1).

Looking at the listing, the file is split into five main parts: _include_, _language_ and _cache_, _env_, _before install_ and _install_. The first part tells TravisCI to create a Unix machine with the Xenail (16.04) distro of Ubuntu. That allows to build and to test the code with the Kinetic Kame distro of ROS.

The second part, _language_ and _cache_, enables the installing of the required ROS packages (the needed to use BebopS, as explained in the README.md file). It allows to customize the environment running in a virtual machine. Finally, the parts env and before install configure all variables (they are used to trigger a build matrix) and system dependencies.

When the process starts, the catkin workspace is build with all the packages under integration (the commands listed in the install section). TravisCI clones the GitHub repository(-ies) into a new virtual environment, and carries out a series of tasks to build and test the code. If one or more of those tasks fails, the build is considered broken. If none of the tasks fails, the build is considered passed, and TravisCI can deploy the code to a web server, or an application host. In particular, the build is considered broken when one or more of its jobs complete with a state that is not passed:

• _errored_: a command in the before install or install phase returned a nonzero exit code. The job stops immediately;
• _failed_: a command in the script phase returned a non-zero exit code. The job continues to run until it completes;
• _canceled_: a user cancels the job before it completes.

At the end of the process, email notifications are sent to all the listed contributors members of the repository. The notifications can be forwarded: on success, on failure, always or never. Finally, the CI system can be also employed to automatically generate documentation starting from the source code and to link it to an online hosting. It is very useful when the project is going to increase or a lot of people are working on it or, more generally, when it is difficult to have an overview of the developed code. Further information on how to use the CI system and how to configure it can be found in 1.

Such procedure allows to easily verify the code quality, underlying errors and warnings through automated software build (including tests), that may not appear when building on own machine. It also ensures that modules working individually (e.g., SLAM, vision or sensors fusion algorithms) do not fail when they are put together due to causes that were difficult to predict during the development phase. For all such reasons, having a software tool able to catch what happened and why it happened, and able to suggest possible solutions, is extremely desirable when working with complex platforms as Gazebo and ROS.