There was an unintended regression in go-getter v1.5.9's GitGetter which
caused us to temporarily fork that particular getter into Terraform to
expedite a fix. However, upstream v1.5.10 now includes a
functionally-equivalent fix and so we can heal that fork by upgrading.
We'd also neglected to update the Module Sources docs when upgrading to
go-getter v1.5.9 originally and so we were missing documentation about the
new "depth" argument to enable shadow cloning, which I've added
retroactively here along with documenting its restriction of only
supporting named refs.
This new go-getter release also introduces a new credentials-passing
method for the Google Cloud Storage getter, and so we must incorporate
that into the Terraform-level documentation about module sources.
cty: The documented definition and comparison logic of cty.Number is now
refined to acknowledge that its true range is limited only to values
that have both a binary floating point and decimal representation,
because cty values are primarily designed to traverse JSON serialization
where numbers are always defined as decimal strings.
In particular, that means that two cty.Number values now always compare
as equal if their representation in JSON (under cty's own JSON encoder)
would be equal, even though the decimal approximation we use for that
conversion is slightly lossy. This pragmatic compromise avoids confusing
situations where a round-trip through JSON serialization (or other
serializations that use the same number format) may produce a value that
doesn't compare equal to the original.
This new definition of equals should not cause any significant behavior
change for any integer in our in-memory storage range, but may cause
some fractional values to compare equal where they didn't before if they
differ only by a small fraction.
* determining source or destination to cloud
* handling single to single state migrations to cloud,
using a name strategy or a tags strategy
* Add end-to-end tests for state migration.
These changes include additions to fulfill the interface for the client
mock, plus moving all that logic (which needn't be duplicated across
both the remote and cloud packages) over to the cloud package under a
dedicated mock client file.
We don't use this library anywhere else in Terraform, and this backend was
using it only for trivial helpers that are easy to express inline anyway.
The new direct code is also type-checkable, whereas these helper functions
seem to be written using reflection.
This gives us one fewer dependency to worry about and makes the test code
for this backend follow a similar assertions style as the rest of this
codebase.
This also transitively upgrades golang.org/x/sys and golang.org/x/net,
but there do not seem to be any significant changes compared to the
commits we were previously using.
CVE-2020-26160 is a high-severity advisory reported against this module.
The dgrijalva package is no longer maintained but our legacy etcv2 backend
depends on it indirectly, via go.etcd.io/etcd/client. The golang-jwt
package is the blessed successor of the original, and has a v3 line which
is compatible with the v3 line of dgrijalva, and so through this replace
we can get a fix for the advisory without other significant behavior
change.
We've preserved the etcdv2 backend as-is on a best-effort basis in order
to support anyone who is already using it, but recommend that users switch
to etcdv3 or to some other backend for ongoing use.
We also have future plans to make state storage be a matter for provider
plugins rather than built in to Terraform CLI, at which point this backend
will either become obsolete or be factored out into its own plugin, at
which point we can remove this "replace" directive and the associated
dependency altogether.
For now, only check the JSON views package, since this was the instance
that most recently tripped us up. There are a few dozen failures
elsewhere in Terraform which would need to be addressed before expanding
this to other packages.
We have a few different .proto files in this repository that all need to
get recompiled into .pb.go files each time we change them, but we were
previously handling that with some scripts that just assumed that protoc
and the relevant plugins were already installed on the system somewhere,
at the right versions.
In practice we've been constantly flopping between different versions of
these tools due to folks having different versions installed in their
development environments. In particular, the state of the .pb.go files
in the prior commit wasn't reproducible by any single version of the tools
because they've all slightly diverged from one another.
In the interests of being more consistent here and avoiding accidental
inconsistencies, we'll now centralize the protocol buffer compile steps
all into a single tool that knows how to fetch and install the expected
versions of the various tools we need and then run those tools with the
right options to get a stable result.
If we want to upgrade to either a newer protoc or a newer protoc-gen-go
in future then we'll do that in a central location and update all of the
.pb.go files at the same time, so that we're always consistently tracking
the same version of protocol buffers everywhere.
While doing this I attempted to keep as close as possible to the toolchain
we'd most recently used, but since they were not consistent with each
other they've now all changed which version numbers they record at minimum,
and the planproto stub in particular now also has a slightly different
descriptor serialization but is otherwise offering the same API.
TencentCloud deleted all their v3 tags, so any system that does not use
the global Go proxy will fail to find the
github.com/tencentcloud/tencentcloud-sdk-go module source.
Update go.mod to point to the specific commit rather than the
incompatible and missing version tag.
Go 1.17 has a new treatment of go.mod where it tracks more indirect
dependencies in return for needing to fetch and load fewer transitive
go.mod files.
This commit opts in to that new treatment and adds all of the additional
indirect dependencies which contain packages that Terraform directly or
indirectly makes use of.
There are more details on what's going on here in the "Lazy Module Loading"
design document:
http://golang.org/design/36460-lazy-module-loading
(the design document was written assuming this would land in Go 1.15, but
it actually landed in Go 1.17 and so it's "go 1.17" that selects the new
behavior in spite of the examples in that document.)
yuriy