* Fail global required_version check if it contains any prerelease fields
* go mod tidy
* Improve required_version prerelease not supported error string
* Add prerelease version constraint unit tests
* Fix side-effects by populating global diags too soon
This allows us to remove the manual replace directives
github.com/dgrijalva/jwt-go and google.golang.org/grpc, so that we can
remove the CVE warnings and update the grpc packages.
While the etcdv3 backend is also marked as deprecated, the changes here
are done in a manner to keep that backend working for the time being.
This means we can now use type parameter syntax where appropriate.
This commit also includes an upgrade to the golang.org/x/tools module,
in order to get a newer version of "stringer" that supports the type
parameters syntax.
The version that was in use previously broke my runs with a nice `ssh:
handshake failed: agent unsupported algorithm "ssh-ed25519"` error. I
took a further look into this, and saw that the change that broke ssh
for me was fixed in https://github.com/golang/crypto/commit/46612604a.
Yay!
This tagged release is a superset of the specific commit we had previously
selected, adding in just an improved error message for inconsistent result
types in a conditional expression.
This is intended to eventually replace the CircleCI-based checks we use
as part of the PR process in this repository. We're already using GitHub
Actions for various other processes in this repository, so this change is
motivated by consistency of having all of our automation running in the
same system and written in the same language.
This is not a complete replacement for our CircleCI workflow yet, and
probably won't ever be because the CircleCI workflow contains some steps
that are arguably redundant with other processes we follow elsewhere.
However, the CircleCI workflow remains for now and won't be removed until
we're satisfied that enough of it is replicated by this GitHub Actions
workflow.
`go-slug` has been updated to not upload `terraform.tfstate` to the slug
so that a user will no longer receive the error message about the
leftover state file after migrating from the local backend to TFC.
This change will await the completion of pre-apply run tasks if they
exist on a run and then report the results.
It also adds an abstraction when interacting with cloud integrations such
as policy checking and cost estimation that simplify and unify output,
although I did not go so far as to refactor those callers to use it yet.
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.
This is a pragmatic temporary solution to allow us to more quickly resolve
an upstream regression in go-getter locally within Terraform, so that the
work to upstream it for other callers can happen asynchronously and with
less time pressure.
This commit doesn't yet include any changes to address the bug, and
instead aims to be functionally equivalent to getter.GitGetter. A
subsequent commit will then address the regression, so that the diff of
that commit will be easier to apply later to the upstream to get the same
effect there.
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.
