terraform

Commit Graph

Author	SHA1	Message	Date
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
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
Martin Atkins	89b2405080	lang/funcs: "sensitive" and "nonsensitive" functions These aim to allow hinting to Terraform about situations where it's not able to automatically infer value sensitivity. "nonsensitive" is for situations where Terraform's behavior is too conservative, such as when a new value is derived from a sensitive value in such a way that all of the sensitive content is removed. "sensitive", on the other hand, is for situations where Terraform can't otherwise infer that a value is sensitive. These situations should be pretty rare in a module that's making effective use of sensitive input variables and output values, but the documentation shows one example of an uncommon situation where a more direct hint via this function would be needed. Both of these functions are aimed at only occasional use in unusual situations. They are here for reasons of pragmatism, not because we expect them to be used routinely or recommend their use.	5 years ago
Stephen	e39abbf6f0	fix regex logical or documentation (#27637 ) * fix regex logical or documentation Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>	5 years ago
Nick Fagerlund	d1e8537b33	website: CLI: Update links to moved docs pages	5 years ago
Nick Fagerlund	7a8dd326c6	website: Language: Update links to moved pages	5 years ago
Nick Fagerlund	78dcc8dc1b	website: Language: Move files to match new URL structure	5 years ago

7 Commits (res-add-learn-link-debug)