terraform

Commit Graph

Author	SHA1	Message	Date
Martin Atkins	dedac2cdd6	website: v0.15 Upgrade Guide entry for Azure Backend arguments Terraform v0.15 includes the conclusion of the deprecation cycle for some renamed arguments in the "azure" backend. We missed this on the first draft of the upgrade guide because this change arrived along with various other more innocuous updates and so we didn't spot it during our change review.	5 years ago
Martin Atkins	035d1648e4	website: Link to the v0.15 upgrade guide Unfortunately it seems that this link got lost in a merge conflict when we did the big nav refactor earlier in the v0.15 cycle, so here we'll retoractively add it to the new location for upgrade guide nav, in the language layout rather than the downloads layout.	5 years ago
Alisdair McDiarmid	ec001d3e18	Merge pull request #28381 from hashicorp/alisdair/fix-double-mark-sensitive-attrs core: Fix double-marked sensitive attributes	5 years ago
Alisdair McDiarmid	2390a11d60	core: Fix double-marked sensitive attributes We need to unmark the decoded state and merge the marks with those from the resource schema. Co-authored-by: James Bardin <j.bardin@gmail.com>	5 years ago
James Bardin	2cd1619c40	Merge pull request #28329 from serejkus/dag/set-tiny-optimisations tiny optimisations of dag.Set	5 years ago
James Bardin	59c8281378	use new dynamic decoding behavior Dynamic blocks with unknown for_each expressions are now decoded into an unknown value rather than using a sentinel object with unknown and null attributes. This will allow providers to precisely plan the block values, rather than trying to heuristically paper over the incorrect plans when dynamic is in use.	5 years ago
Alisdair McDiarmid	2c8c387540	Merge pull request #28363 from hashicorp/alisdair/here-is-a-newline command: Add a newline before confirming apply	5 years ago
Alisdair McDiarmid	e4031eaccf	command: Add a newline before confirming apply This blank line delineating the plan and the query was accidentally dropped as part of the views migration.	5 years ago
Martin Atkins	5f5432e8ea	website: v0.15 upgrade guide for sensitive resource attributes (#28355 ) * website: v0.15 upgrade guide for sensitive resource attributes Our earlier draft of this guide didn't include a section about the stabilization of the "provider_sensitive_attrs" language experiment. This new section aims to address the situation where a module might previously have been returning a sensitive value without having marked it as such, and thus that module will begin returning an error after upgrading to Terraform v0.15. As part of that, I also reviewed the existing documentation about these features and made some edits aiming to make these four different sections work well together if users refer to them all at once, as they are likely to do if they follow the new links from the upgrade guide. I aimed to retain all of the content we had before, but some of it is now in a new location. In particular, I moved the discussion about the v0.14 language experiment into the upgrade guide, because it seems like a topic only really relevant to those upgrading from an earlier version and not something folks need to know about if they are using Terraform for the first time in v0.15 or later. * minor fixups Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>	5 years ago
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.	5 years ago
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.	5 years ago
Alisdair McDiarmid	33e5d111fe	Merge pull request #28326 from hashicorp/alisdair/allow-nonsensitive-on-non-sensitive-values lang/funcs: Make nonsensitive more permissive	5 years ago
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.	5 years ago
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.	5 years ago
James Bardin	1212bbec9f	Merge pull request #28317 from hashicorp/jbardin/delete-error-dependencies restore saved dependencies on delete error	5 years ago
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.	5 years ago
James Bardin	b7fb533bd2	Merge pull request #28275 from hashicorp/jbardin/diagnostic-addresses Add addresses to diagnostics	5 years ago
James Bardin	d04999863c	"with" formatting	5 years ago
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.	5 years ago
James Bardin	265b5106ca	call the InConfigBody with addresses	5 years ago
James Bardin	406ac97965	add the address field to the view diagnostics	5 years ago
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.	5 years ago
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	5 years ago
Matthew Hooker	49c984ff77	bump go-getter to 1.5.2 (#28189 )	5 years ago
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	5 years ago
James Bardin	973ed6eae6	Merge pull request #28272 from hashicorp/jbardin/plan-destroy-skip-refesh ensure plans always have a stored state	5 years ago
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.	5 years ago
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	5 years ago
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.	5 years ago
James Bardin	8871eff495	remove debug Println	5 years ago
Alisdair McDiarmid	e4be99b233	Merge pull request #28253 from hashicorp/alisdair/fix-jsonplan-sensitive-unknown command/jsonplan: Fix sensitive/unknown crash	5 years ago
James Bardin	51c7aff475	Merge pull request #28251 from hashicorp/jbardin/auto-complete don't error when given autocomplete commands	5 years ago
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.	5 years ago
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.	5 years ago
Alisdair McDiarmid	788c57a7c3	Merge pull request #28243 from hashicorp/doc-dynamic-blocks-foreach website: Dynamic blocks can for_each any collection type	5 years ago
Alisdair McDiarmid	d37c3c597a	Merge pull request #28245 from hashicorp/alisdair/fix-sensitive-value-sensitive-attribute-conflict core: Fix sensitive value/attribute conflict	5 years ago
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.	5 years ago
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.)	5 years ago
James Bardin	7ab4f1fb7d	Merge pull request #28240 from hashicorp/jbardin/test-builds remove unsupported platforms from CI test builds	5 years ago
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.	5 years ago
James Bardin	1f53cfcd43	Merge pull request #28238 from hashicorp/jbardin/circle-resource-class provide more memory for builds	5 years ago
James Bardin	6ef5ed1060	provide more memory for builds Cross-platform builds are running out of resources. Try using a little more memory.	5 years ago
James Bardin	1a158743b3	Merge pull request #28228 from hashicorp/jbardin/destroy-deps Stored dependency handling during plan	5 years ago
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	5 years ago
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.	5 years ago
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	5 years ago
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.	5 years ago
Robin Norwood	e3bd661470	Merge pull request #28164 from hashicorp/rln-add-resource-targeting-tutorial-callout Add callout to resource targeting tutorial	5 years ago
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.	5 years ago
Alisdair McDiarmid	63613ca1b0	command/jsonconfig: Add variable sensitive flag	5 years ago

1 2 3 4 5 ...

28190 Commits (e29eb78cfddfb1cd7f477457d6aedbcb8286fc4c) All Branches Search

28190 Commits (e29eb78cfddfb1cd7f477457d6aedbcb8286fc4c)

All Branches