Use use base official golang image in CircleCI, as it gets refreshed
more quickly compared to circleci/golang, and we don't benefit from
circleci image customizations much.
We currently use an container image for `test-devices` job only; while
all other jobs use machine executor.
This allows us to switch golang and protoc verions easily without
manually managing Docker images (which requires building them manually
on a dev machines, etc). All that while, we install dependencies on
every build in all other jobs..
`test-devices` now is one of the fastest jobs and isn't a constraint or
a bottleneck, so increasing its overhead by few seconds doesn't hurt the
overall developer iteration.
If we split tests effectively later, we can revisit.
This fixes a frequent failure in `test-rkt` jobs where dpkg installation
fails.
The image used currently, circleci/classic:201808-01, has unattended
upgrades enabled accidentally, which runs on every build. This means
that tools get modified unexpectedly during builds, and apt-get commands
may fail as the unattended upgrade is holding package database lock.
This updates `test-rkt` job only because the new image breaks
`test-docker` job (e.g. https://circleci.com/gh/hashicorp/nomad/2641 ),
and I punted on investigating test-docker for another day.
This adds a job to test the UI on CircleCI, including the sort of branch
pattern-matching from #5839, so .-ui/ branches only have that job
and not the non-UI ones.
I considered having an entire workflow for UI, which could have separate
jobs for linting vs Ember tests, but the lint commands take so little time
that it didn’t seem worth it.
There’s no use of nvm to change the Node version as the Docker image
is what controls that. It’s annoying to have to update the version in multiple
places, but probably infrequent.
This commit provides an initial migration of general testing CI
infrastructure to CircleCI.
It uses CircleCI 2.1 paramereterised jobs to provide two base
configurations: a vm based `test-machine`, and docker based
`test-container`.
Jobs that require root, docker, or other similar features require the
machine based jobs, but others should be ran using the `test-container` package
as they are both cheaper and faster to run.
