Commit Graph

39 Commits

Author SHA1 Message Date
Nick Fagerlund 7a8dd326c6 website: Language: Update links to moved pages 2021-01-22 12:22:21 -08:00
Nick Fagerlund 85d477aee9 website: Fix numerous links with redirects or broken anchors
These links largely still go somewhere useful, but they have some kind of issue
revealed by our new link checker:

- Some of them point to a stale URL that redirects, and can be updated to the
  new destination.
- Some of them point to anchors that don't exist (anymore?) in the destination.
- Some of them end up redirecting unnecessarily due to how the server handles
  directory URLs without trailing slashes. Sorry, I know that's pointless, just,
  humor me for the time being so we can get our CI green. 😭

In a couple cases, I've added invisible anchors to destination pages, either to
preserve an old habit or because the current anchors kind of suck due to being
particularly long or meandering.
2020-12-17 12:23:50 -08:00
Nick Fagerlund 83ebb9b178 website: Add big whitespace separators to recovery landing pages
The resources, expressions, and modules pages were all split into smaller, more
navigable pages, but the old URLs had accumulated a large number of deep links
to their section headers. To help people recover when they click an old link, we
converted those old URLs to landing pages, which preserve all of the old in-page
anchors and point readers to the appropriate new destinations.

However, because the new link-to-new-page sections are so small, it was kind of
hard to tell which section you had clicked into! Especially if you were near the
bottom of the page and the browser wasn't able to position the desired section
at the very top of the window.

This commit aims to improve that by putting one full screen of whitespace in
between every linkable section on these landing pages. Yes, it's a hack, but
you're meant to only view these pages for three seconds or so before moving on
to the place you wanted to be, and this should help dispel any confusion about
which place that is.
2020-12-01 15:38:25 -08:00
Nick Fagerlund 6e2f5eb0be website: Break up Resources page into smaller chunks
- Resource behavior gets its own page.
- Meta-arguments all get their own pages.
- Stuff about resource syntax itself gets a page.

In the process of breaking the meta-arguments out into their own pages, I
revised them (with the exception of `provider`) so that they apply to both
resources and modules.

Like with Expressions, this commit repurposes the old resources.html URL as a
landing page for old links.
2020-11-17 16:30:51 -08:00
Nick Fagerlund 5e18e44037
Merge pull request from hashicorp/oct20_language_and_cli_docs
website: TF-153: Split core Terraform docs into "Language" and "CLI"
2020-11-11 19:31:05 -08:00
timvandamme fbf267fbfd
website: for_each doesn't implicitly convert to set ()
The documentation states that an explicit type conversion to set is needed, but it does not say why implicit type conversion does not work. 

Co-authored-by: Nick Fagerlund <nick@hashicorp.com>
2020-11-02 11:13:51 -08:00
Nick Fagerlund 596e529602 website: Adopt a ton of pages into the "language" layout
As of this commit, that layout doesn't exist yet, but I'm isolating the one-line
changes to their own commit to try and keep your eyes from glazing over.
2020-10-26 18:19:26 -07:00
JT Smith 6ac8bfb86d
[Documentation] Typo fixes
Just re-read the docs the ignore_changes update and saw a few typos
2020-10-05 10:10:38 -06:00
James Bardin ee564a5ceb
Merge pull request from hashicorp/jbardin/ignore-changes-map
allow ignore_changes to reference any map key
2020-10-05 12:06:05 -04:00
Nick Fagerlund 26f786959b
website: Update all Learn crosslinks ()
* 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>
2020-10-02 11:02:59 -07:00
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.
2020-10-01 09:36:36 -04:00
Nick Fagerlund 0ab7c1b90e
website: Add links to relevant Learn guides in several docs pages ()
Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
2020-07-31 13:16:35 -07:00
Nick Fagerlund 0e5651560b
Website: 0.13 docs edits, mostly around provider requirements ()
* 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>
2020-07-30 21:07:36 -07:00
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.
2020-06-01 14:17:47 -07:00
Paul Leddy 3d17c87698 Example of for_each with list -> set using toset 2020-05-19 16:03:21 -07:00
Pam Selle 4e0879c486 Document for_each key requirements 2020-01-30 17:18:16 -05:00
charlottemach e3d38046dc website/docs: replace outdated tag syntax ()
Fixes 
2019-10-24 11:23:17 -04:00
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.
2019-10-11 13:41:58 -07:00
Nick Fagerlund f6e648cc8b website: Document behavior of `self` object for provisioners 2019-10-03 15:12:18 -07:00
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.
2019-08-08 14:13:10 -07:00
Pam Selle 7d905f6777 Resource for_each 2019-07-22 10:51:16 -04:00
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.
2019-06-18 17:37:24 -07:00
Justin Weissig 3d80aed6fe website/docs: Fixed Typo ()
Fixed typo: separtely/separately.
2019-04-29 09:19:10 -04:00
Jeff 3110dde1d1 Fix docs typo ()
* fix docs typo

* restore trailing newline
2019-04-04 11:21:36 -04:00
Nick Fagerlund 428a2c05e7
website: Expand output values docs ()
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`.
2019-03-22 15:08:55 -07:00
Tomas Chmelevskij 036a1e259e website: Typo fix () 2019-03-19 11:26:25 -07:00
Kristin Laemmert 21f6e3dffd
Mildwonkey/012 docs updated ()
* docs: update plan command documentation. Fixes 

* docs: added a missing reserved variable name. Fixes .

* website: add note that resource names cannot start with a number

* website: add some notes to the 0.12 upgrade guide
2019-03-01 12:30:51 -08:00
Nick Fagerlund 4a190127b9 website: Version notes: Add new -> old links to 0.12 language docs (except function pages) 2019-02-01 17:20:54 -08:00
Nick Fagerlund 9f85e6d5cc website: Update configuration language section page titles 2018-12-20 14:20:42 -08:00
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.
2018-12-20 14:20:42 -08:00
Michael Irwin 47047aa637
Small grammar fix for lifecycle docs 2018-10-22 22:34:11 -04:00
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.
2018-10-16 18:47:33 -07:00
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.
2018-10-16 18:46:46 -07:00
Quinn Diggity c943caf1a5 website: fix for typo in resources.html.md ()
should be provides, not provies
2018-06-18 08:37:57 -07:00
Dominik-K 9da5f5a9f0 docs: no interpolations in `lifecycle` attribute () ()
* docs: interpolations in `lifecycle` unsupported currently
2018-04-05 15:06:22 -04:00
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.
2018-04-03 17:37:36 -04:00
Cameron Childress ae33b68e68 website: An example of referencing resources with "count" 2017-12-04 09:43:40 -08:00
Alexandru Ungur 9f1a773655 website: fix broken link from resources to multiple provider instances 2017-11-20 17:05:35 -08:00
Martin Atkins 7ed70bb00e website: new filesystem layout for core/provider split
This repo now contains only the core docs, with other content moving elsewhere.
2017-06-13 11:25:32 -07:00