Set up Travis builds

[psigen]

As mentioned by @mkoval in #12, we should set up Travis builds for automated testing. A few questions:

• Should we build standalone, catkin, or both? (I prefer standalone, but maybe both since we have aikido_rviz, etc.)
• Which version(s) of kido should we test against?
• Can we use Travis's container-based infrastructure? (https://docs.travis-ci.com/user/workers/container-based-infrastructure/)
  • Are the dependencies we need available on their whitelist (assuming we build kido from source)?
  • Alternative: docker images (https://hub.docker.com/_/ros/)?

[mkoval]

Should we build standalone, catkin, or both? (I prefer standalone, but maybe both since we have aikido_rviz, etc.)

I plan to use the pr-cleanroom architecture I already have setup, which builds aikido in a Catkin workspace. It also sense to build aikido (without any of the ROS-dependent addon packages, like aikido_rviz) to verify that no ROS dependencies crept in, but I don't plan on doing this myself. 😉

Which version(s) of kido should we test against?

We're currently stuck building against master because we're using bleeding-edge features. We'll need to revisit this once things settle down. Hopefully we can use the official Debian builds.

Can we use Travis's container-based infrastructure?

No. There is a request open to whitelist ROS, but it has not yet been approved. I don't think the container-based infrastructure will ever be a viable choice for us unless Travis removes the Apt whitelisting requirement. Travis is pretty bad about approving whitelist requests: there are 182 requests open, some pending for 9 months, and only 20 have been approved. I would be shocked if they ever approve ROS, which has hundreds of packages from different authors.

[jslee02]

I'm also against to use container-based infrastructure. I have three PRs waiting to be reviewed but as @mkoval said they never approved. Also, Simbody found that it runs much slower, which is not the expect.