We have a few dependencies that are such a significant part of Terraform's
behavior that they will often be the root cause of or the solution to a
bug reported against Terraform.
As a small quality-of-life improvement to help with diagnosing those,
we'll now report the selected versions for each of these so-called
"interesting" dependencies as part of our initial trace log output during
Terraform startup.
The goal here is that when someone opens a bug report, and includes the
trace log as our bug report template requests, we'll be able to see at a
glance which versions of these dependencies were involved, instead of
having to manually cross-reference in the go.mod file of the reported main
Terraform CLI version.
This does slightly grow the general overhead of the logs, but as long as
we keep this set of interesting dependencies relatively small it shouldn't
present any significant problem in typical usage.
For Terraform Cloud users using the 'remote' backend, the existing
'pattern' prompt should work just fine - but because their workspaces
are already present in TFC, the 'migration' here is really just
realigning their local workspaces with Terraform Cloud. Instead of
forcing users to do the mental gymnastics of what it means to migrate
from 'prefix' - and because their remote workspaces probably already exist and
already conform to Terraform Cloud's naming concerns - streamline the
process for them and calculate the necessary pattern to migrate as-is,
without any user intervention necessary.
After migrating to TFC with renamed workspaces, automatically select
what was the previous current workspace on behalf of the user. We don't
need to make the user reselect.
Note these change do break the internal/cloud/e2e tests; they are in a
sad state that needs adjusting anyway, so I'm not updating them for
these changes at this time.
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.
The Meta.backend_C_r_S_unchanged() method was sadly a bit of a mess.
It seems to have originally been used as a method to be called
when the backend is not changing, with an extra assumption that if the
configured backend's hash doesn't match the one in state, surely the
hash should just be updated as an option might have been moved to
command line flags.
However, this function was used throughout this file as 'the method to
load the initialized (but not necessarily configured) backend',
regardless of whether or not it is the same (unchanged). This is in
addition to Meta.backendFromState(), which is used to load the same
thing except in the main codepath of 'init -backend=false'.
These changes separate the concerns of backend_C_r_S_unchanged() by
1) Fetching the saved backend (savedBackend())
2) Updating the hash value in the backend cache when appropriate (either
by leaving it to the caller to do themselves or by calling
updateSavedupdateSavedBackendHash())
This allows migration codepaths to *not* update the hash value until
after a migration has successfully taken place.
Allow `GetResource` to return correct types values during validation,
rather than relying on `cty.DynamicVal` as a placeholder. This allows
other dependent expressions to be more correctly evaluated.
* command/format: fix list nested attr diff rendering
Previously, diffs only rendered correctly if all changed elements
appeared before all unchanged elements. Once an unchanged element was
found, all remaining elements were skipped. This usually led to the
output being an empty list with a weird amount of space between the
brackets.
* command/format: improve list nested attr rendering
This makes several changes that make diffs for lists clearer and more
consistent:
* Separate items with brackets instead of only new lines. This better
matches the input syntax and avoids confusion from the first and
last brackets implying there is a single item.
* Render an action symbol for each element of the list
* Use the correct action symbol for new and deleted items
* Fix the alignment of opening and closing brackets
I also refactored the structure so it is similar to the set and map
cases to minimize duplication of the new prints.
* Fix re-use of blockBodyDiffResult struct
Add the `-parallel N` switch to tell the tests to run in N processes:
```
TFE_TOKEN=$TFE_TOKEN TFE_HOSTNAME=$TFE_HOSTNAME TF_ACC=1 go test -v \
-tags=e2e ./internal/cloud/e2e/... -parallel 4
```
Previously, `terraform init` was throwing an error if you configured the cloud
block with `tags` and there weren't any tagged workspaces yet. Confusing and
alienating, since that that's a fairly normal situation! Basically TFC was
handling an empty list of workspaces worse than other backends, because it
doesn't support an unnamed default workspace.
This commit catches that condition during `Meta.selectBackend()` and asks the
user to pick a name for their first tagged workspace. If they cancel out, we
still error, but if we know what name they want, we can handle it the same way
as a nonexistent workspace specified in `name` -- just pass it to
`Meta.SetWorkspace()`, and let the workspace get implicitly created when
`InitCommand.Run()` eventually calls `StateMgr()`.
This is documentation for the first set of refactoring-related features,
all based on the new "moved" blocks in the Terraform language.
I've named the documentation section "refactoring" because in previous
discussions with users that seems to be the term they use to describe the
underlying need.
"moved" blocks are our first language feature intended to meet that need,
although it probably won't be the last as we consider other requirements
in later releases. My intent here is that once we've published this it
should eventually end up being the first result for a web search for the
topic of Terraform refactoring.
Based on feedback during earlier alpha releases, we've decided to move
forward with the current design for the first phase of config-driven
refactoring.
Therefore here we've marked the experiment as concluded with no changes
to the most recent incarnation of the functionality. The other changes
here are all just updating test fixtures to no longer declare that they
are using experimental features.
Martin Atkins