We don't usually run "acceptance tests" during a Travis run, but this
particular suite doesn't require any special credentials since it just
accesses releases.hashicorp.com to download plugins, so therefore it's
safe to run in Travis at the expense of adding a few more seconds to
the runtime.
Running it in Travis can therefore give us some extra confidence for
pull requests that may inadvertently break certain details of the
workflow, as well as ensuring that these tests are kept up-to-date as
the system changes.
As of Go 1.9, ./... excludes the vendor directory by default and so we
no longer need to jump through hoops to exclude vendored packages from
testing, vetting, etc.
As a simplification this also re-introduces builtin/bins to the set of
packages we run tests on. With the providers now split into their own
repositories there's far fewer of these and so including them doesn't
really hurt anything, and makes our invocations here simpler.
Since there is little left that isn't core, remove the distinction for
now to reduce confusion, since a "core" binary will mostly work except
for provisioners.
* Use latest in go 1.8 branch for travis
* Fix ongoing vet issues
Move vet step after the testing step in travis
Correct Makefile vet step to check correct files
Running `go test -i` installs the requirements for a package's tests.
This way when running the tests in batches of 4, we can cut the runtime
in half be only compiling the dependencies once.
* provider/aws: Add errcheck to Makefile, error on unchecked errors
* more exceptions
* updates for errcheck to pass
* reformat and spilt out the ignore statements
* narrow down ignores
* fix typo, only ignore Close and Write, instead of close or write
Allows specifying `LD_FLAGS` during development builds.
```
$ LD_FLAGS="-linkmode=external" make dev
```
Since the version of DTrace on macOS Sierra (On the public beta's at least) has been updated, this allows DTrace to run on Terraform during development/debugging.
```
$ sudo dtrace -n 'pid$target::main.main:entry' -c "terraform apply"
dtrace: description 'pid$target::main.main:entry' matched 1 probe
Apply complete! Resources: 0 added, 0 changed, 0 destroyed.
Outputs:
foo = bar
dtrace: pid 23096 has exited
CPU ID FUNCTION:NAME
2 265673 main.main:entry
```
Also redirects the `@which stringer` command inside the `generate` Makefile target to `/dev/null` so we stop echoing the path to the `stringer` binary on every call to `generate`.
Several of our vendered dependencies are not gofmt-compliant, but we don't
want to fix that since the vendored code is supposed to exactly match
upstream.
* Remove `make updatedeps` from Travis build. We'll follow up with more
specific plans around dependency updating in subsequent PRs.
* Update all `make` targets to set `GO15VENDOREXPERIMENT=1` and to
filter out `/vendor/` from `./...` where appropriate.
* Temporarily remove `vet` from the `make test` target until we can
figure out how to get it to not vet `vendor/`. (Initial
experimentation failed to yield the proper incantation.)
Everything is pinned to current master, with the exception of:
* Azure/azure-sdk-for-go which is pinned before the breaking change today
* aws/aws-sdk-go which is pinned to the most recent tag
The documentation still needs to be updated, which we can do in a follow
up PR. The goal here is to unblock release.
Often when developing a plugin it's only necessary to rebuild that plugin.
Here we add a simple Makefile target that makes that easy:
make plugin-dev PLUGIN=provider-aws
Since it's only building one package and it's only building for the
host architecture, this just uses "go install" directly, rather than using
gox as we do when installing multiple packages, possibly for multiple
architectures.
* update Vagrantfile to modern Consul-style version
* add `make release` for a one-shot command to get from fresh vagrant
machine to a built release
* add RELEASING.md to document details about the release process
James Bardin