In CI, avoid duplicating work that is already done in Docker

[briansmith]

We have a test stage in Docker that builds and tests the code within Travis CI, without using Docker. Then we have a separate docker-deploy stage that builds the code again inside of Docker and saves the Docker images. It seems wasteful and hard to maintain to have two different ways of building the code within CI. We should build the code in Docker and then test the code using the Docker-built code. At the very least, we should find some way to avoid needing to have a build/test script for Travis CI that's separate from the build/test script used within our Dockerfiles.

[klingerf]

The test stage runs on every CI build, regardless of branch, but the docker-deploy stage only runs on master branch builds, triggered by master commits. The stages are configured as follows:

stages:
  - name: test
  - name: docker-deploy
    if: branch = master AND type != pull_request

I agree that ideally we would run the tests inside docker containers, as that's more reflective of the actual runtime environment. In practice, however, building docker images as a prerequisite to running tests is going to slow our branch builds down, a lot.

Here's what the timing for both stages looked like on a recent master commit run:

[briansmith]

I agree that we shouldn't slow down CI by any significant amount. Let's see if #292 results in anything useful that would make the Docker builds as fast or faster than the non-Docker builds. I don't see any reason why the Docker builds must inherently be significantly slower.

[briansmith]

I'm going to close this since it turned out that the work isn't actually duplicated, but subtly different. For example, the Rust tests are for debug builds in the non-Docker Travis CI configuration, and for the release builds for Docker builds.