This includes a change to accept and ignore a UTF-8 BOM at the start of
any given native syntax configuration.
Although a BOM is redundant in UTF-8, we learned in #18618 that several
software products on Windows will produce a BOM whenever they save as
UTF-8, so accepting it avoids friction when using those tools to author
or generate Terraform configuration files.
This fixes#18618.
This includes:
- An additional check in the format stdlib function to fail if there are
too many arguments given, rather than silently ignoring.
- Refinements for the type unification behavior to allow unification of
object/tuple types into weaker map/list types when no other unification
is possible.
- Improvements to the error messages for failed type conversions on
collection and structural types to talk about mismatching element types
where possible, rather than the outer value.
This includes a fix to hcl.RelTraversalForExpr where it would
inadvertantly modify the internals of a traversal AST node as part of
relativizing the traversal in order to return it.
This includes a number of upstream bug fixes, which in turn fix a number
of issues here in Terraform:
- New-style "full splat" operator now working correctly (#19181)
- The weird HCL1-ish single-line block syntax is now supported (#19153)
- Formatting of single-line blocks adds spaces around the braces (#19154)
This also includes a number of other upstream fixes that were not tracked
as issues in the Terraform repository. The highlights of those are:
- A for expression with the "for" keyword wrapped onto a newline after its
opening bracket now parses correctly.
- In JSON syntax, interpolation sequences in properties of objects that
are representing expressions now have their variables properly detected.
- The "flush" heredoc variant is now functional again after being broken
in some (much-)earlier rework of the template parser.
Notable changes:
* backend/s3: Automatic validation of `eu-north-1` region
* backend/s3: Support for `credential_process` handling in AWS configuration file
Updated via:
```
go get github.com/aws/aws-sdk-go@v1.16.4
go get github.com/terraform-providers/terraform-provider-aws@v1.52.0
go mod tidy
go mod vendor
```
* Upgrading to 2.0.0 of github.com/hashicorp/go-azure-helpers
* Support for authenticating using Azure CLI
* backend/azurerm: support for authenticating using the Azure CLI
In 98c8ac0862 I merged a change to the vendored code for this module but
didn't spot that it didn't also update the dependency metadata to match.
Here we just catch up the metadata to match the vendored version, with
no change to the vendored code itself.
* adding acceptance tests for msi auth
* including the resource group name in the tests
* backend/azurerm: support for authenticating using a SAS Token
* resolving merge conflicts
* moving the defer to prior to the error
* vendor updates
- updating to v21.3.0 of github.com/Azure/azure-sdk-for-go
- updating to v10.15.4 of github.com/Azure/go-autorest
- vendoring github.com/hashicorp/go-azure-helpers @ 0.1.1
* backend/azurerm: refactoring to use the new auth package
- refactoring the backend to use a shared client via the new auth package
- adding tests covering both Service Principal and Access Key auth
- support for authenticating using a proxy
- rewriting the backend documentation to include examples of both authentication types
* switching to use the build-in logging function
* documenting it's also possible to retrieve the access key from an env var
Newer versions of the retryablehttp package use a context, so we need to
add that in our custom `CheckRetry` function.
In addition I removed the `return true, nil` to continue retrying in
case of an error, and instead directly call the `DefaultRetryPolicy`.
This is because the `DefaultRetryPolicy` will now also take the context
into consideration.
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.
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.
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.
This brings in a bugfix for analyzing variables inside relative traversal
expressions in HCL, and a cosmetic bugfix in cty for GoString of
cty.NullVal(cty.DynamicPseudoType).
This also updates some other packages, as a result of running "go get -u".
This includes the new PathSet type, which we'll use to represent the
"requires replacement" set of attribute paths coming back from providers
during planning.
This includes a bugfix to the cty/msgpack package to ensure correct
decoding of unknown and null values.
This also includes updates to cty's dependencies.
govendor's lack of understanding of transitive versions was making it hell
to figure out some dependency hell between etcd, grpc, and protobuf. After
fighting with it for a few hours, I decided to give Go 1.11rc2 a try since
previous experiments had been promising on the 1.11 tree in master.
The dependencies all worked out first time when managed using the Go
Modules code, and so we'll run with this now to continue to make progress
though we may wish to back out of this nearer to release and return to
govendor for a while until other projects have caught up.
However, since this commit includes a vendor directory produced using Go
Modules it doesn't actually _require_ Go 1.11 to build, and instead
requires it only to make further changes to the selected versions in the
vendor dir. Go 1.10's vendoring support will still find the modules in
their expected locations within the vendor dir.
Martin Atkins