terraform

Commit Graph

Author	SHA1	Message	Date
James Bardin	ee564a5ceb	Merge pull request #26421 from hashicorp/jbardin/ignore-changes-map allow ignore_changes to reference any map key	5 years ago
Nick Fagerlund	26f786959b	website: Update all Learn crosslinks (#26442 ) * website: Update all Learn crosslinks The URL structure on Learn recently changed, so it's time to update some URLs. Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>	5 years ago
James Bardin	82793f8158	update ignore_changes doc We can remove the caveat about changing map elements. Add a little more text about the intended use case for ignore_changes, as the common case of fixing erroneous provider behavior should not be the primary motivation for the maintenance of this feature.	5 years ago
Nick Fagerlund	0ab7c1b90e	website: Add links to relevant Learn guides in several docs pages (#25718 ) Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>	6 years ago
Nick Fagerlund	0e5651560b	Website: 0.13 docs edits, mostly around provider requirements (#25686 ) * Make sidebar nav in language docs more intuitive * Minor display fixes for registry docs * Explain providers in the registry in the providers index * Revise a bunch of language docs around provider reqs This is mostly an effort to smooth out some of the explanations, make sure things are presented in a helpful order, make sure terminology lines up, draw connections between related concepts, make default behavior more apparent, and the like. It shouldn't include very much new information, but there might be one or two things that came out of a conversation somewhere. Co-authored-by: Judith Malnick <judith@hashicorp.com>	6 years ago
Martin Atkins	67311f73fd	website: Draw better attention to for and for_each patterns When helping folks in the community forum, I commonly see questions around more complex patterns in transforming deep data structures into different shapes to work with for_each. We have examples of these patterns in the docs for the functions that they rely on, but they were not previously very discoverable in the main configuration language documentation sections. Here I've moved the "Using Expressions in for_each" subsection on the Resources page above some of the other sub-sections to hopefully make it easier to see, and written out in more detail the two specific patterns that answer a significant number of for_each-related user questions in the hope that readers will be more likely to realize that the links are relevant to what their goals. I also added some more elaboration about the behavior of converting from list to set in the "Using Sets" subsection, because this feature is often a user's first encounter with the set data type and I've inferred from some of the questions I've answered that a number of Terraform users don't have prior experience with set data types in other languages to draw assumptions from. Finally, I added some similar links to the for_each patterns within the for expression documentation itself, to try to make those examples more visible to those who might be discovering the documentation in a different sequence, e.g. by following a deep link shared in an answer to a question in the community forum.	6 years ago
Paul Leddy	3d17c87698	Example of for_each with list -> set using toset	6 years ago
Pam Selle	4e0879c486	Document for_each key requirements	6 years ago
charlottemach	e3d38046dc	website/docs: replace outdated tag syntax (#23111 ) Fixes #21614	6 years ago
Martin Atkins	047733d20c	website: Full examples for for_each with flatten and setproduct A very common question since we launched the two repetition constructs is how to deal with situations where the input data structure doesn't match one-to-one with the desired configuration. This adds some full worked examples of two common situations that have come up in questions. To avoid adding a lot of extra content to the already-large "expressions" and "resources" pages, the main bulk of this new content lives with the relevant functions themselves as a full example of one thing they are good for, and then we'll link to them from the two general documentation sections where folks are likely to be reading when they encounter the problem.	6 years ago
Nick Fagerlund	f6e648cc8b	website: Document behavior of `self` object for provisioners	7 years ago
Nick Fagerlund	979a2fa6d1	website: Align `count` and `for_each` sections - Make these descriptions more similar, since they do basically the same thing. - Add some subheaders to break up the wall of text and make it more skimmable. - Nudge people more firmly toward `for_each` if they need to actually incorporate data from a variable into their instances. - Add version note so you know whether you can use this yet.	7 years ago
Pam Selle	7d905f6777	Resource for_each	7 years ago
Martin Atkins	1bba574fe9	website: Document ignore_changes for individual map elements This also includes a previously-missing test that verifies the behavior described here, implemented as a planning context test for consistency with how the other ignore_changes tests are handled.	7 years ago
Justin Weissig	3d80aed6fe	website/docs: Fixed Typo (#21137 ) Fixed typo: separtely/separately.	7 years ago
Jeff	3110dde1d1	Fix docs typo (#20924 ) * fix docs typo * restore trailing newline	7 years ago
Nick Fagerlund	428a2c05e7	website: Expand output values docs (#20790 ) For 0.11 I just specified the naming rules; for 0.12, I added some info about referencing values and tightened up the layout of the optional arguments. This commit also syncs up descriptions of `depends_on`.	7 years ago
Tomas Chmelevskij	036a1e259e	website: Typo fix (#20629 )	7 years ago
Kristin Laemmert	21f6e3dffd	Mildwonkey/012 docs updated (#20542 ) * docs: update plan command documentation. Fixes #19235 * docs: added a missing reserved variable name. Fixes #19159. * website: add note that resource names cannot start with a number * website: add some notes to the 0.12 upgrade guide	7 years ago
Nick Fagerlund	4a190127b9	website: Version notes: Add new -> old links to 0.12 language docs (except function pages)	7 years ago
Nick Fagerlund	9f85e6d5cc	website: Update configuration language section page titles	7 years ago
Nick Fagerlund	d2abdc23ac	website: Structural edit of configuration language docs This commit is a wide-ranging set of edits to the pages under /docs/configuration. Among other things, it - Separates style conventions out into their own page. - Separates type constraints and conversion info into their own page. - Conflates similar complex types a little more freely, since the distinction is only relevant when restricting inputs for a reusable module or resource. - Clarifies several concepts that confused me during edits.	7 years ago
Michael Irwin	47047aa637	Small grammar fix for lifecycle docs	7 years ago
Martin Atkins	e41883d972	website: Revise the "Output Values" configuration docs section This adopts a more guide-like writing style, similar to what prior commits have done to some other subsections of this section. In the process of writing this, I identified some unclear statements in the "Resources" subsection, and so these are also revised here for consistency with the output values documentation.	7 years ago
Martin Atkins	6fa6a0d110	website: revise the "Resources" configuration docs section This is now the leading subsection of the Configuration section of the docs, and so this rewrite intends to make it more "guide-like" and as accessible as possible to those who are not yet familiar with other Terraform concepts. This rewrite also attempts to introduce some consistency into our vocabulary, which should eventually be reflected throughout our documentation. In particular: - "Resource" refers to the block the user writes in configuration, while "Resource _Type_" refers to what the provider defines. We previously used "resource" for both of these interchangeably. - "Resource" is no longer used to refer to what gets created and managed in remote APIs as a result of a resource block in configuration. Lacking a good distinct name for these, this guide uses the word "object", qualifying it as "infrastructure object" or "remote object" where necessary to retain clarity. This distinction is important to enable a clear description of resource lifecycle. - "Argument" refers to an element (attribute or block) within a resource block. This terminology was already being used in some places, so we embrace it here as a way to distinguish from "attribute", which is what a resource _exports_ for use in expressions. - Since interpolation is no longer needed to use expressions in the language, the word "expression" is used to describe the definition of a value that might involve some computation. Where necessary, this is used with a modifier "arbitrary expression" to contrast with situations where the set of allowed expression constructs is constrained.	7 years ago
Quinn Diggity	c943caf1a5	website: fix for typo in resources.html.md (#18266 ) should be provides, not provies	8 years ago
Dominik-K	9da5f5a9f0	docs: no interpolations in `lifecycle` attribute (#3116 ) (#17695 ) * docs: interpolations in `lifecycle` unsupported currently	8 years ago
James Bardin	ff8d02cd25	remove old warning care create_before_destroy Create-before-destroy dependencies are automatically ordered correctly by terraform. Remove the old notice about requiring all dependencies to have the same setting for create_before_destroy.	8 years ago
Cameron Childress	ae33b68e68	website: An example of referencing resources with "count"	8 years ago
Alexandru Ungur	9f1a773655	website: fix broken link from resources to multiple provider instances	8 years ago
Martin Atkins	7ed70bb00e	website: new filesystem layout for core/provider split This repo now contains only the core docs, with other content moving elsewhere.	9 years ago

31 Commits (6440c839474f052d8997bb5cec19c2743e5108e6)