Improve build server / continuous integration logic

[RussTedrake]

We currently have

• Travis CI building with the public externals and running the C++ only unit tests, using g++ and clang on ubuntu. These spin up fresh virtual machines for every build.
• Custom build scripts / build servers (in my office) running unit tests with all externals and all of the matlab tests, on win32, win64, mac yosemite, ubuntu 12.04 and ubuntu 14.04. These do not spin up clean machines for every build, and sometimes make implicit assumptions about pre-installed libraries/components, etc. They also require maintenance.
• We manually run our (custom) packaging scripts to roll a new release. Aim to shift to automated nightly builds which get tagged with version numbers for major releases.

We need a better solution. Soliciting advice.

• I have toyed with AppVeyor and believe that could serve a role similar to travis for the windows builds. I haven't yet found a similar solution for Mac.
• Don't know (yet) how to serve licensed products (e.g., matlab + commercial solvers) on a virtual cloud machine. But need to find a way.
• This is an obvious place to start looking: https://github.com/integrations

[rdeits]

Deploying solver licenses on Travis is actually pretty easy (I have a mosek license in my Iris build server). Travis provides a mechanism for storing an encrypted file in your repo that their server can decrypt at build time.

[rdeits]

https://docs.travis-ci.com/user/encrypting-files/

[rdeits]

Correction: the Travis encrypted files aren't available for pull requests from forks (as a security precaution). That hasn't affected IRIS development much, but it might be a big problem for Drake.

[RussTedrake]

Summary of discussion:

• Need to switch to clean images for every build. Solutions exist for getting images onto e.g. AWS for ubuntu and windows, but we don't know one for mac.
• Travis will work with mac (but not with matlab).
• The only real reasons we're stuck with custom build server logic is (a) availability of matlab and (b) known issue logic. both feel surmountable. people use Jenkins and BuildBot.

[RussTedrake]

everyone agrees we want nightly releases, and that we need build servers running tests on those releases (ideally before it was posted, but github has a webhook for release postings that could make it easy to do things serially).
Specifically:

• nightly build should replace a single "nightly" release on the github release page.
• we can tag a good release (and increment the version num)
• we carry a branch "stable" which gets moved up to the latest release, and the default install instructions tell people to clone stable.

[psiorx]

Need to switch to clean images for every build

Maybe we could use Vagrant for something like this?

[RussTedrake]

Recommendation:

• turn on coverage tools for C++ now

[RussTedrake]

great lead from the mathworks: https://github.com/RobotLocomotion/mathworks-requests/issues/11#issuecomment-169677976

[rdeits]

Very cool!

[RussTedrake]

Note that we now running appveyor for minimal windows builds. Need to fill out the build matrix, and enable more externals. #1560