Commit Graph

28131 Commits

Author SHA1 Message Date
James Bardin b515ab583a make blocktoattr an hcldec.UnknownBody
This will allow any dynamic blocks that are fixed up as a blocktoattr
still decode into an unknown value.
2021-04-13 18:42:15 -04:00
Martin Atkins 140c613ae8 lang/funcs: "one" function
In the Terraform language we typically use lists of zero or one values in
some sense interchangably with single values that might be null, because
various Terraform language constructs are designed to work with
collections rather than with nullable values.

In Terraform v0.12 we made the splat operator [*] have a "special power"
of concisely converting from a possibly-null single value into a
zero-or-one list as a way to make that common operation more concise.

In a sense this "one" function is the opposite operation to that special
power: it goes from a zero-or-one collection (list, set, or tuple) to a
possibly-null single value.

This is a concise alternative to the following clunky conditional
expression, with the additional benefit that the following expression is
also not viable for set values, and it also properly handles the case
where there's unexpectedly more than one value:

    length(var.foo) != 0 ? var.foo[0] : null

Instead, we can write:

    one(var.foo)

As with the splat operator, this is a tricky tradeoff because it could be
argued that it's not something that'd be immediately intuitive to someone
unfamiliar with Terraform. However, I think that's justified given how
often zero-or-one collections arise in typical Terraform configurations.
Unlike the splat operator, it should at least be easier to search for its
name and find its documentation the first time you see it in a
configuration.

My expectation that this will become a common pattern is also my
justification for giving it a short, concise name. Arguably it could be
better named something like "oneornull", but that's a pretty clunky name
and I'm not convinced it really adds any clarity for someone who isn't
already familiar with it.
2021-04-12 15:32:03 -07:00
Alisdair McDiarmid 33e5d111fe
Merge pull request #28326 from hashicorp/alisdair/allow-nonsensitive-on-non-sensitive-values
lang/funcs: Make nonsensitive more permissive
2021-04-12 14:00:41 -04:00
Alisdair McDiarmid c1f7193454 lang/funcs: Make nonsensitive more permissive
Calling the nonsensitive function with values which are not sensitive
will result in an error. This restriction was added with the goal of
preventing confusingly redundant use of this function.

Unfortunately, this breaks when using nonsensitive to reveal the value of
sensitive resource attributes. This is because the validate walk does
not (and cannot) mark attributes as sensitive based on the schema,
because the resource value itself is unknown.

This commit therefore alters this restriction such that it permits
nonsensitive unknown values, and adds a test case to cover this specific
scenario.
2021-04-12 12:31:59 -04:00
Sergey Elantsev 1ad01debf3 tiny optimisations of dag.Set
1. Use hint for map size in Set.Copy().
2. Use Set.Copy() if Set.Difference() argument is empty.
2021-04-09 22:59:30 +03:00
James Bardin 1212bbec9f
Merge pull request #28317 from hashicorp/jbardin/delete-error-dependencies
restore saved dependencies on delete error
2021-04-08 11:38:57 -04:00
James Bardin 4bfabbaee4 restore saved dependencies on delete error
Is a resource delete action fails and the provider returned a new state,
we need to ensure the stored dependencies are retained.
2021-04-08 09:57:14 -04:00
James Bardin b7fb533bd2
Merge pull request #28275 from hashicorp/jbardin/diagnostic-addresses
Add addresses to diagnostics
2021-04-06 16:09:39 -04:00
James Bardin d04999863c "with" formatting 2021-04-06 15:50:30 -04:00
James Bardin 9e5baf4662 use WholeContainingBody instead of Sourceless
When returning generic grpc errors from a provider, use
WholeContainingBody so that callers can annotate the error with all the
available contextual information. This can help troubleshoot problems by
narrowing down problems to a particular configuration or specific
resource instance.
2021-04-06 15:15:52 -04:00
James Bardin 265b5106ca call the InConfigBody with addresses 2021-04-06 15:15:52 -04:00
James Bardin 406ac97965 add the address field to the view diagnostics 2021-04-06 15:15:52 -04:00
James Bardin 503c413de2 add addresses to diagnostics
Add an address argument to tfdiags.InConfigBody, and store the address
string the diagnostics details. Since nearly every place where we want
to annotate the diagnostics with the config context we also have some
sort of address, we can use the same call to insert them both into the
diagnostic.

Perhaps we should rename InConfigBody and ElaborateFromConfigBody to
reflect the additional address parameter, but for now we can verify this
is a pattern that suits us.
2021-04-06 15:15:52 -04:00
Víctor Felipe Godoy Hernández a9487c7674
Fix yamldecode example from json to yaml (#28220)
* Fix yamldecode example from json to yaml

* inline yaml example
2021-04-05 13:41:07 -04:00
Matthew Hooker 49c984ff77
bump go-getter to 1.5.2 (#28189) 2021-04-05 09:01:47 -04:00
Dennis Gursky 4e42d21837
Improve ModuleInstance String() performance (#28246)
* Optimize (m ModuleInstance) String()

Optimize (m ModuleInstance) String() to preallocate the buffer and use strings.Builder instead of bytes.Buffer

This leads to a common case only doing a single allocation as opposed to a few allocations which the bytes.Buffer is doing.

* adding a benchmark test

Result:

```
$ go test -bench=String ./addrs -benchmem 
BenchmarkStringShort-12         18271692                56.52 ns/op           16 B/op          1 allocs/op
BenchmarkStringLong-12           8057071               158.5 ns/op            96 B/op          1 allocs/op
PASS
$ git checkout main addrs/module_instance.go
$ go test -bench=String ./addrs -benchmem 
BenchmarkStringShort-12          7690818               162.0 ns/op            80 B/op          2 allocs/op
BenchmarkStringLong-12           2922117               414.1 ns/op           288 B/op          3 allocs/op
```

* Update module_instance_test.go

switch spaces to tabs
2021-04-05 08:44:27 -04:00
James Bardin 973ed6eae6
Merge pull request #28272 from hashicorp/jbardin/plan-destroy-skip-refesh
ensure plans always have a stored state
2021-04-01 16:49:09 -04:00
James Bardin b6b7f78b49 ensure plans always have a stored state
When refresh was skipped for a destroy plan, there was no state stored
in the plan.
2021-04-01 16:44:32 -04:00
James Bardin 1e1bb00e5b
Merge pull request #28267 from hashicorp/jbardin/data-depends_on-refs
Don't force data reads from dependency changes in sibling modules
2021-04-01 13:39:05 -04:00
James Bardin 349e99bb0c don't force data reads from sibling module changes
Dependencies are tracked via configuration addresses, but when dealing
with depends_on references they can only apply to resources within the
same module instance. When determining if a data source can be read
during planning, verify that the dependency change is coming from the
same module instance.
2021-04-01 12:03:34 -04:00
James Bardin 8871eff495 remove debug Println 2021-04-01 12:03:34 -04:00
Alisdair McDiarmid e4be99b233
Merge pull request #28253 from hashicorp/alisdair/fix-jsonplan-sensitive-unknown
command/jsonplan: Fix sensitive/unknown crash
2021-03-31 16:56:03 -04:00
James Bardin 51c7aff475
Merge pull request #28251 from hashicorp/jbardin/auto-complete
don't error when given autocomplete commands
2021-03-31 14:58:32 -04:00
Alisdair McDiarmid ff32fab41a command/jsonplan: Fix sensitive/unknown crash
When rendering the JSON plan sensitivity output, if the plan contained
unknown collection or structural types, Terraform would crash. We need
to detect unknown values before attempting to iterate them.

Unknown collection or structural values cannot have sensitive contents
accidentally displayed, as those values are not known until after apply.
As a result we return an empty value of the appropriate type for the
sensitivity mapping.
2021-03-31 14:29:15 -04:00
James Bardin 270ab97418 don't error when processing autocomplete commands
The shell autocomplete command will use the binary name as the first
argument which does not show up under the list of subcommands.
2021-03-31 13:28:08 -04:00
Alisdair McDiarmid 788c57a7c3
Merge pull request #28243 from hashicorp/doc-dynamic-blocks-foreach
website: Dynamic blocks can for_each any collection type
2021-03-31 09:48:59 -04:00
Alisdair McDiarmid d37c3c597a
Merge pull request #28245 from hashicorp/alisdair/fix-sensitive-value-sensitive-attribute-conflict
core: Fix sensitive value/attribute conflict
2021-03-31 09:29:53 -04:00
Alisdair McDiarmid c54c18680e core: Fix sensitive value/attribute conflict
When applying sensitivity marks to resources, we previously would first
mark any provider-denoted sensitive attributes, then apply the set of
planned-change sensitive value marks. This would cause a panic if a
provider marked an iterable value as sensitive, because it is invalid to
call `MarkWithPaths` against a marked iterable value.

Instead, we now merge the marks from the provider schema and the planned
change into a single set, and apply them with one call. The included
test panics without this change.
2021-03-30 15:51:09 -04:00
Martin Atkins f47c4efb1b website: Dynamic blocks can for_each any collection type
We previously added a hint to both resource for_each and dynamic blocks
about using the "flatten" and "setproduct" situations to construct
suitable collections to repeat over.

However, we used the same text in both places which ended up stating that
dynamic blocks can only accept map or set values, which is a constraint
that applies to resource for_each (because we need to assign a unique
identifier to each instance) and not to dynamic blocks (which don't have
any uniqueness enforced by Terraform Core itself).

To remove that contradiction with the text above which talks about what
is valid here, I've just generalized this to say "collection", because
the primary point of this paragraph is the "one element per desired nested
block" part, not specifically what sort of collections are permitted in
this location. (Text further up describes the supported types.)
2021-03-30 09:43:33 -07:00
James Bardin 7ab4f1fb7d
Merge pull request #28240 from hashicorp/jbardin/test-builds
remove unsupported platforms from CI test builds
2021-03-30 11:22:09 -04:00
James Bardin 23e08cd064 remove unsupported platforms from tests
Rather than increase resources for more cross-platform builds, opt to
remove platforms that are not officially supported.
2021-03-30 11:10:03 -04:00
James Bardin 1f53cfcd43
Merge pull request #28238 from hashicorp/jbardin/circle-resource-class
provide more memory for builds
2021-03-30 10:48:24 -04:00
James Bardin 6ef5ed1060 provide more memory for builds
Cross-platform builds are running out of resources. Try using a little
more memory.
2021-03-30 10:36:16 -04:00
James Bardin 1a158743b3
Merge pull request #28228 from hashicorp/jbardin/destroy-deps
Stored dependency handling during plan
2021-03-30 09:19:14 -04:00
Alisdair McDiarmid 4fb505631c
Merge pull request #28230 from hashicorp/alisdair/only-rewrite-provider-locks-file-if-changed
cli: Only rewrite provider locks file if changed
2021-03-30 09:12:45 -04:00
Alisdair McDiarmid 786d99207e cli: Only rewrite provider locks file if changed
If the provider locks have not changed, there is no need to rewrite the
locks file. Preventing this needless rewrite should allow Terraform to
operate in a read-only directory, so long as the provider requirements
don't change.
2021-03-29 16:09:07 -04:00
Alisdair McDiarmid 340543d122
Merge pull request #28201 from hashicorp/alisdair/planfile-sensitive-required-replace
Add sensitivity and required-replace fields to plan file, and expose sensitivity to JSON plan
2021-03-29 15:08:36 -04:00
James Bardin 7964328f34 merge dependencies when refreshing
The resource configuration was always being used to determine
dependencies during refresh, because if there were no changes to a
resource, there was no chance to replace any incorrect stored
dependencies. Now that we are refreshing during plan, we can determine
that a resource has no changes and opt to store the new dependencies
immediately.

Here we clean up the writeResourceInstanceState calls to no longer
modify the resource instance state, removing the `dependencies`
argument. Callers are now expected to set the Dependencies field as
needed.
2021-03-29 14:34:01 -04:00
Robin Norwood e3bd661470
Merge pull request #28164 from hashicorp/rln-add-resource-targeting-tutorial-callout
Add callout to resource targeting tutorial
2021-03-29 09:12:30 -05:00
Alisdair McDiarmid 5e30d58dc2 command/jsonplan: Add output change sensitivity
When an output value changes, we have a small amount of information we
can convey about its sensitivity. If either the output was previously
marked sensitive, or is currently marked sensitive in the config, this
is tracked in the output change data.

This commit encodes this boolean in the change struct's
`before_sensitive` and `after_sensitive` fields, in the a way which
matches resource value sensitivity. Since we have so little information
to work with, these two values will always be booleans, and always equal
each.

This is logically consistent with how else we want to obscure sensitive
data: a changing output which was or is marked sensitive should not have
the value shown in human-readable output.
2021-03-26 19:26:11 -04:00
Alisdair McDiarmid 63613ca1b0 command/jsonconfig: Add variable sensitive flag 2021-03-26 19:26:11 -04:00
Alisdair McDiarmid e27aacebf9 command/jsonplan: Add sensitive value mapping data
Similar to `after_unknown`, `before_sensitive` and `after_sensitive` are
values with similar structure to `before` and `after` which encode the
presence of sensitive values in a planned change. These should be used
to obscure sensitive values from human-readable output.

These values follow the same structure as the `before` and `after`
values, replacing sensitive values with `true`, and non-sensitive values
with `false`. Following the `after_unknown` precedent, we omit
non-sensitive `false` values for object attributes/map values, to make
serialization more compact.

One difference from `after_unknown` is that a sensitive complex value
(collection or structural type) is replaced with `true`. If the complex
value itself is sensitive, all of its contents should be obscured.
2021-03-26 19:26:10 -04:00
Matthew Frahry 15779013da
backend/azurerm: Bug fixes and updated dependencies #28181 2021-03-26 14:07:56 -07:00
Judith Malnick 75fbbe8065
clarify version that pull upgrades local state to (#28204) 2021-03-26 13:57:44 -07:00
Alisdair McDiarmid fd7c4105f2
Merge pull request #28202 from hashicorp/alisdair/fmt-multiline-value-expr-unwrap
cli: Fix fmt output for multi-line value exprs
2021-03-26 11:33:14 -04:00
James Bardin 985124bfa8 failing test for removed cbd reference
A stored dependency is documented as being honored even after it is
removed from the configuration, until the referenced resource is
destroyed.
2021-03-25 17:39:53 -04:00
James Bardin bac4e0a3de fix ResourceInstanceObject.DeepCopy
missing CreateBeforeDestroy
2021-03-25 17:39:53 -04:00
Martin Atkins 6f35c2847b command: Reorganize docs of the local backend's legacy CLI options
We have these funny extra options that date back to before Terraform even
had remote state, which we've preserved along the way by most recently
incorporating them as special-case overrides for the local backend.

The documentation we had for these has grown less accurate over time as
the details have shifted, and was in many cases missing the requisite
caveats that they are only for the local backend and that backend
configuration is the modern, preferred way to deal with the use-cases they
were intended for.

We always have a bit of a tension with this sort of legacy option because
we want to keep them documented just enough to be useful to someone who
finds an existing script/etc using them and wants to know what they do,
but not to take up so much space that they might distract users from
finding the modern alternative they should consider instead.

As a compromise in that vein here I've created a new section about these
options under the local backend documentation, which then gives us the
space to go into some detail about the various behaviors and interactions
and also to discuss their history and our recommended alternatives. I then
simplified all of the other mentions of these in command documentation
to just link to or refer to the local backend documentation. My hope then
is that folks who need to know what these do can still find the docs, but
that information can be kept out of the direct path of new users so they
can focus on learning about remote backends instead.

This is certainly not the most ideal thing ever, but it seemed like the
best compromise between the competing priorities I described above.
2021-03-25 13:56:48 -07:00
Matthew Frahry 13b41d59f5 Website Test Fix 2021-03-25 13:47:12 -07:00
Alisdair McDiarmid d71f0c6149 cli: Fix fmt output for multi-line value exprs
The formatter for value expressions which use legacy interpolation
syntax was previously behaving incorrectly with some multi-line
expressions. Any HCL expression which requires parenthesis to be allowed
to span multiple lines could be skip those parens if already inside
string interpolation (`"${}"`).

When removing string interpolation, we now check for a resulting
multi-line expression, and conservatively ensure that it starts and ends
with parenthesis. These may be redundant, as not all expressions require
parens to permit spanning multiple lines, but at least it will be valid
output.
2021-03-25 15:40:54 -04:00