Since protoc is not go-gettable, and most development tasks in Terraform
won't involve recompiling protoc files anyway, we'll use a separate
mechanism for these.
This way "go generate" only depends on things we can "go get" in the
"make tools" target.
In a later commit we should also in some way specify a particular version
of protoc to use so that we don't get "flapping" regenerations as
developers work with different versions, but the priority here is just to
make "make generate" minimally usable again to restore the dev workflow
documented in the README.
This also includes some updates that resulted from running "make generate"
and "make protobuf" after those Makefile changes were in place.
Change ValidateProviderConfig to PrepareProviderConfig.
Providers have a concept of "required fields with defaults" that that
was handled previously by helper/schema doing input and validation.
Because Input and Validation is mostly now handled by core, the provider
had no way of setting default values for missing required attributes.
To achieve the same behavior with new providers, there will be a
PrepareProviderConfig, which allow for manual validation, as well as
alteration of the config. The provider is free to set whatever
attributes necessary to create a valid config and return it to the
caller. If a new config is returned, it will be used instead of the
original in the subsequent Configure call, however core may still add
missing required values during an optional Input phase.
This contains a fix for a panic in Value.HasElement when used on a set
value whose element type is an object or tuple.
A few other minor dependency upgrades came long for the ride.
ProposedNewObject intentionally replaces a null prior with an unknown
prior in order to easily fill in unknown values where they "show through"
under values not set explicitly in config, but it was failing to handle
that situation when dealing with nested blocks that are backed by sets.
Due to the unusual way v0.12 was developed (because of the large amount
of cross-cutting refactoring) we have not built out an incremental
changelog along the way as we normally would.
This is an initial catchup of the changelog for the current tree at the
time of writing, with the intent that we will maintain this in the usual
way moving forward as we head towards the v0.12-alpha1 release.
`All()` combines the outputs of multiple `SchemaValidateFunc`, to reduce the usage of custom validation functions that implement standard validation functions.
Example provider usage:
```go
ValidateFunc: validation.All(
StringLenBetween(5, 42),
StringMatch(regexp.MustCompile(`[a-zA-Z0-9]+`), "value must be alphanumeric"),
),
```
`IntInSlice()` is the `int` equivalent of `StringInSlice()`
Example provider usage:
```go
ValidateFunc: validation.IntInSlice([]int{30, 60, 120})
```
Output from unit testing:
```
$ make test TEST=./helper/validation
==> Checking that code complies with gofmt requirements...
go generate ./...
2018/10/17 14:16:03 Generated command/internal_plugin_list.go
go list ./helper/validation | xargs -t -n4 go test -timeout=2m -parallel=4
go test -timeout=2m -parallel=4 github.com/hashicorp/terraform/helper/validation
ok github.com/hashicorp/terraform/helper/validation 1.106s
```
The helper/resource unit tests will panic, because they were using the
legacy terraform.MockResourceProvider, which doesn't have the same
internals required by the new GRPC shims.
Fail these tests for now, and a new test provider will need to be made
out of a schema.Provider instance.
This work was done against APIs that were already changed in the branch
before work began, and so it doesn't apply to the v0.12 development work.
To allow v0.12 to merge down to master, we'll revert this work out for now
and then re-introduce equivalent functionality in later commits that works
against the new APIs.
After a bunch of recent changes/rebasing our vendored dependencies got a
little out of sync w.r.t transitive dependencies through codebases that
are not themselves Go Modules yet.
Even if a provider doesn't indicate a specific attribute as the cause of
a resource operation error, we know the error relates to some aspect of
the resource, so we'll include that approximate information in the result
so that we don't produce user-hostile error messages with no context
whatsoever.
Later we can hopefully refine this to place the source range on the header
of the configuration block rather than on an empty part of the body, but
that'll require some more complex rework here and so for now we'll just
accept this as an interim state so that the user can at least figure out
which resource block the error is coming from.
This ensures more HCL1/HIL-like behaviors when dealing with nested blocks
that are not set in the configuration, which is important for
compatibility with helper/schema's validation logic.
James Bardin