OSS no longer needs the multi-file config Makefile content, so it was
removed. However, enterprise does benefit from having that around. We
can allow enterprise to expand on OSS' CircleCI Makefile by adding an
include directive in OSS. This will allow the Makefile to be the same on
both OSS and Enterprise, so merge conflicts cannot occur.
Dockerhub is going to rate limit unauthenticated pulls.
Use our HashiCorp internal mirror for builds run through CircleCI.
Co-authored-by: Mahmood Ali <mahmood@hashicorp.com>
Currently we compile (but don't run) the e2e tests as part of `test-other`,
which is skipped for branches named `e2e-*`. Move this check into the
`test-e2e` job. Split out the vault compatibility integration check as its own
makefile target for clarity.
We currently have two jobs commented out in ENT because we don't have the test
target configured there. So having the filter attached to one of those jobs
means changes to filters always create a merge conflict.
Branches for the e2e code base can't have impact on the unit tests, so running
those tests just extends the time it takes to ship e2e updates. This changeset
updates the CircleCI config so that e2e branches run linting, build the
binary, and run the e2e unit tests (currently just vault compatibility).
Go 1.14.4 contains two CVEs which are fixed in 1.14.5:
- [CVE-2020-15586](https://golang.org/issue/34902)
- [CVE-2020-14039](https://golang.org/issue/39360)
Upon consideration with HashiCorp security these CVEs are considered low
severity for Nomad and no new security fix binary will be released.
This is extracted from #8094, where I have run into some snags. Since
these ESLint fixes aren’t actually connected to the Ember 3.16 update
but involve changes to many files, we might as well address them
separately. Where possible I fixed the problems but in cases where
a fix seemed too involved, I added per-line or -file exceptions.
This PR switches the Nomad repository from using govendor to Go modules
for managing dependencies. Aspects of the Nomad workflow remain pretty
much the same. The usual Makefile targets should continue to work as
they always did. The API submodule simply defers to the parent Nomad
version on the repository, keeping the semantics of API versioning that
currently exists.
Always install go and vault: the check may accidentally use the CircleCI
pre-installed go version instead of the cached version.
Also, always install from sources without caching. Go/vault
installation is basically a tarball download. That's equivalent to
CirleCI caching without the complexity. These steps don't add much time
either.
Lastly, infer the OS when downloading tarball to avoid managing them in
the job spec.
This surfaces test failures more clearly on CircleCI by adding
testem-multi-reporter to report both via the default TAP reporter
as well as an xUnit reporter whose output is stored as an artefact.
make test-nomad sets 15 minute time out for build. Increase the ci
timeout to 20m, so we can get meaningful output and goroutine stack
traces rather than have test be simply killed by CircleCI.
The extra 5 minutes is a buffer for generating-structs and some
unnecessary padding.
This adopts pattern used by Vault, where we split CircleCI yaml config
into multiple files that get packed and translated to 2.0.
This has two motivations: First, to ease translating config to CircleCI
2.0 so it can run on Enterprise private repository. Second and most
importantly, it also adding Enterprise specific jobs in separate files
with reduced config file merging conflict resolution.
This is a remenant of the time we used a custom hashicorp docker image for CI.
Currently, we use the official golang image, so no longer need the job
or manage the dockerhub credentials.
`stable-website` branch is only meant for updating the nomadproject.io
website, and the backend tests are irrelevant. Also, the ci workflow
uses up the plans containers and may delay website deployments by 20
minutes or more while we are cutting a release.
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.
Kris Hicks