Travis docker

[diegoferigo]

After discussing with @traversaro, I added docker support to Travis CI. In addition to the committed file, please refer to robotology-playground/docker_images and the new dockerhub account.

In short, using docker's ephemeral containers in Travis CI opens the doors to the following features and scenarios:

1. Commands executed with docker spawn a new container that dies right after their execution. The code of the DUT is 1) built and 2) installed and tested in different clean containers.
2. We are not anymore tied to the default version of Ubuntu shipped with Travis. This is currently a problem when Gazebo 8 is required. Potentially, we can use as guest every linux distribution we like, not only Ubuntu, and also legacy versions. This freedom also allows to use the most recent versions of the build tools, that often require installing them in Travis' VM from an external repo.
3. sudo can be disabled inside Travis, operation that allows switching to a container-based mode.
4. The only code built by Travis is the DUT itself. The TDD framework and tools are shipped with the yarp-tdd image, which is downloaded from DockerHub. Before that, the docker image is built directly by DockerHub, and its build can be triggered by a new commit pushed into the robotology-playground/docker_images repository. This method, in addition to ccache support, should consistently improve compile time. First tests show that build time could be reduced by a factor of 3. I can already hear and feel the happiness of Travis' servers.
5. As far as I understood, when a devel branch built against yarp-devel is merged into its master branch, a manual operation on .travis.yml is required. This docker way, at least for the gazebo-yarp-plugins requirements, automates the selection of the correct yarp branch by pulling a different docker image. The implemented strategy is the following: if the targeted branch by Travis is master, use yarp:master image, else use yarp:devel.

Some TODOs and comments:

1. Only Gazebo 7 and 8 have been implemented. Are earlier Gazebo versions still used?
2. This method only works for testing on Linux platforms, I have no experience with macOS and for the time being docker cannot "containerize" macOS.
3. There is a big code duplication in the docker_images repository's directory tree that can be handled in better ways.
4. Referencing point 5. above, and considering git flow, if a developer needs to test his/her branch (which name won't be master) against yarp:master (circumstance that could be thought as an exception), it could be possibile to parse somewhere in .travis.yml the triggering commit searching for a custom tag (e.g. [travis-use-yarp-master]).
5. In order to trigger the generation of the yarp-git images, a signal external to robotology-playground/docker_images is required (when the images will be stable, they won't change but the code inside them does. Right now only new commits into docker_images trigger an automatic image build). A possibile trigger could be the yarp's after_success travis step, even if it would probably trigger too many image rebuilds considering the activity on the project. The images are tightly linked and nested, the build process order is yarp > (icub && yarp-gazebo) > yarp-tdd, and it takes a lot of time with the CPU power that DockerHub provides for free. Other ideas on triggers are welcome.
6. The test against yarp binary packages from ppa is already supported (yarp-tdd:gazeboXbin) but not used.
7. @traversaro mentioned something about Jenkins, probably the docker images could be useful to set up an internal build system.

[traversaro]

I did not know of the TRAVIS_BRANCH env variable, great!

[traversaro]

Thanks. :D

[diegoferigo]

I know you were already missing them xD

[traversaro]

As in #276 , I think we can drop support for Gazebo 5 & 6 on both master and devel . Given that we don't know when a new release will be made, I think it is beneficial to have Gazebo 8 testing in master, so I would move this PR to target master.

[traversaro]

Ok, the only requested change is to target master rather then devel.

[diegoferigo]

Now the pull request targets master.

[traversaro]

I think one review is enough to merge.