Speed up Travis builds by eliminating the "sudo: required" directive in .travis.yml

[MikeTheCanuck]

Jaron is reporting network timeouts for civic builds in Travis: https://travis-ci.org/hackoregon/civic/jobs/389552399 https://travis-ci.org/hackoregon/civic/jobs/389589641

e.g.

590.04s$ npm i -g cross-env
npm ERR! code ETIMEDOUT
npm ERR! errno ETIMEDOUT
npm ERR! network request to https://registry.npmjs.org/lru-cache/-/lru-cache-4.1.3.tgz failed, reason: connect ETIMEDOUT 104.18.98.96:443
npm ERR! network This is a problem related to network connectivity.
npm ERR! network In most cases you are behind a proxy or have bad network settings.
npm ERR! network 
npm ERR! network If you are behind a proxy, please make sure that the
npm ERR! network 'proxy' config is set properly.  See: 'npm help config'
npm ERR! A complete log of this run can be found in:
npm ERR!     /home/travis/.npm/_logs/2018-06-08T07_36_22_782Z-debug.log
The command "npm i -g cross-env" failed and exited with 1 during .

And Travis acknowledges network issues in their sudo-enabled GCE infrastructure:

Network Instability for sudo-enabled builds on travis-ci.org Investigating - We are currently investigating reports of builds on our sudo-enabled GCE infrastructure experiencing network instability and failures on travis-ci.org. Jun 8, 15:51 UTC

I've wondered since last year whether we still require sudo: required in our Travis builds (e.g. https://github.com/hackoregon/transportation-systems-backend-2018/blob/staging/.travis.yml#L1) - this is the setting which is causing our Travis builds to run in this environment rather than containerized (https://docs.travis-ci.com/user/reference/overview/).

I've never had time or need to chase this down, but maybe's the time for us to experiment with a couple of repos and see if we can avoid it? I just did a search on transportation-systems-backend-2018 and it appears the only place we use sudo there is in the start.sh script, which isn't called in the Travis environment. So I'd like to start there:

• [ ] disaster-resilience-backend
• [ ] elections-2018-backend
• [ ] housing-2018
• [ ] neighborhoods-2018
• [ ] transportation-systems-backend-2018

Unfortunately, this sudo: required directive doesn't appear in the civic Travis config (https://github.com/hackoregon/civic/blob/master/.travis.yml), so I'm going to guess that the Travis network issues extend beyond just the "sudo-enabled GCE infrastructure".

[MikeTheCanuck]

I just ran a few experiments on the transportation-systems-backend-2018 repo to compare the build speed for a job with the sudo: required directive vs a job without that directive.

It appears that at best, the build jobs take about the same time - 2:07 vs 2:10 was the closest I could get them to go.

Diving deeper into Travis' blog and some of the interwebs articles, it's unclear whether the sudo: required directive does anything anymore:

• https://blog.travis-ci.com/2015-03-31-docker-default-on-the-way - "any Linux projects activated after February 14th that do not contain explicit sudo (or ping) usage will be routed to the container-based infrastructure."
• https://blog.travis-ci.com/2017-06-19-trusty-updates-2017-Q2 - mentions the use of sudo: false
• https://docs.travis-ci.com/user/reference/overview/ - fascinating details that are under-intuitive:
  • https://docs.travis-ci.com/user/reference/overview/#For-a-finished-build - both builds are still running in the GCE sudo-enabled environment
  • https://docs.travis-ci.com/user/reference/overview/#Virtualisation-Environment-vs-Operating-System - it appears that sudo: false must be accompanied by dist: trusty ?
  • https://docs.travis-ci.com/user/reference/overview/#For-a-particular-.travis.yml-configuration - it appears that including services: docker will force the job to run in sudo-enabled linux (Ubuntu Trusty) environment on Google Cloud Engine
  • https://docs.travis-ci.com/user/docker/ - it appears that using any docker commands in the build require a non-Docker environment - at minimum, by specifying the services: docker directive

Confirm that Docker requires non-containerized Travis build environment

For funsies I eliminated the services: docker directive from one of our repos' .travis.yml to see what happens - this is the tail end of the Travis build log from that commit:

$ bin/build.sh -p
Building [secure]-service
Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running?
If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
The command "bin/build.sh -p" exited with 1.
0.85s$ bin/test.sh -p
Couldn't connect to Docker daemon at http+docker://localunixsocket - is it running?
If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
The command "bin/test.sh -p" exited with 1.
Done. Your build exited with 1.

Conclusion

Looks like we're stuck in GCE non-containerized, slower build environment - at least, for any repo build that generates or uses Docker images.