Commit Graph

49 Commits

Author SHA1 Message Date
James Bardin 65ee33a90d
Merge pull request #28748 from Bredoxon/patch-1
Fix typo in the docs
2021-05-19 12:18:21 -04:00
Bredoxon 06e756eb0c
Fix typo in the docs 2021-05-19 10:51:06 +10:00
James Bardin 760a59b3a7 negative substring 2021-05-18 16:04:47 -04:00
Kyle A. Matheny 3afa08b1bc
Remove duplicate word (#28716) 2021-05-18 11:04:54 -04:00
James Bardin 51a171c7f4 pg requires PostgreSQL 10 2021-05-18 09:39:05 -04:00
Alisdair McDiarmid 3e40a9a4eb
Merge pull request #28507 from stevematney/patch-1
Updating sensitive/nonsensitive docs with v0.14 specifics.
2021-05-14 13:46:12 -04:00
Steve Matney e27a927ba4 Updating sensitive and nonsensitive docs with correct v0.15 info. 2021-05-14 10:32:39 -06:00
Martin Atkins 0aa0e00fdc website: Backend docs link to new .gitignore anchor
The Git book seems to be using a different anchor format now, and so this
link was previously effectively linking to the page as a whole rather
than to the specific section we're trying to refer to.
2021-05-12 09:27:37 -07:00
Martin Atkins 874f1abb2b cli+website: -ignore-remote-version docs and other cleanup
We previously had only very short descriptions of what
-ignore-remote-version does due to having the documentation for it inline
on many different command pages and -help output.

Instead, we'll now centralize the documentation about this argument on
the remote backend page, and link to it or refer to it from all other
locations. This then allows us to spend more words on discussing what
Terraform normally does _without_ this option and warning about the
consequences of using it.

This continues earlier precedent for some local-backend-specific options
which we also don't recommend for typical use. While this does make these
options a little more "buried" than before, that feels justified given
that they are all "exceptional use only" sort of options where users ought
to learn about various caveats before using them.

While there I also took this opportunity to fix some earlier omissions
with the local-backend-specific options and a few other minor consistency
tweaks.
2021-05-12 09:27:37 -07:00
Roger Berlind b6885923d0
website: Add link to Modules in Package Sub-directories (#27980)
* Add link to Modules in Package Sub-directories

Add link to "Modules in Package Sub-directories" section at top of page

* Fix broken links

* Update aws link, fixes missing anchor linkcheck

Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
2021-05-11 12:15:09 -07:00
Martin Atkins 6f68065326 website: Explicit example of for_each chaining between resources
This pattern follows as a natural consequence of how for_each is defined,
but I've noticed from community forum Q&A that newcomers often don't
immediately notice the connection between what for_each expects as input
and what a for_each resource produces as a result, so my aim here is to
show a short example of that in the hope of helping folks see the link
here and get ideas on how to employ the technique in other situations.
2021-05-10 10:49:04 -07:00
Rachel Sharp c302fa507f
Add link to lifecycle tutorial 2021-05-04 14:20:22 -04:00
John Houston fabdf0bea1
Add config_paths and drop KUBECONFIG env variable in kubernetes backend (#26997) 2021-04-20 10:05:45 -04:00
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>
2021-04-14 09:04:40 -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
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
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
Matthew Frahry 15779013da
backend/azurerm: Bug fixes and updated dependencies #28181 2021-03-26 14:07:56 -07: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
Matthew Frahry 3546650ac6 backend/azurerm: adding the right role name 2021-03-22 10:51:01 -07:00
Matthew Frahry a978d4ee99 website: adding the new fields to azurerm 2021-03-22 09:53:52 -07:00
Tej-Singh-Rana 2a49d908b8
fix the typo (#28140) 2021-03-22 10:51:45 -04:00
Pam Selle 683422e54f
Merge pull request #28113 from hashicorp/pselle/provider_sensitive_attrs_docs
Update documentation for provider_sensitive_attrs experiment
2021-03-18 11:24:55 -04:00
James Bardin c6278bbe37
Merge pull request #28042 from jasons42/update-workspaces-docs
Indicate etcdv3 support for multiple workspaces in docs
2021-03-17 14:13:08 -04:00
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.
2021-03-16 16:26:22 -07:00
Pam Selle 81e8167a4c Update documentation for provider_sensitive_attrs experiment
Update documentation to reference that this experiment is now
default in 0.15+
2021-03-16 13:31:43 -04:00
Jason Smith 024035114a Fix broken link error
Link to https://consul.io/ is not actually broken but returns a 307
redirect to https://www.consul.io/ which the broken link test counts as a failure.
2021-03-10 15:38:22 -06:00
Jason Smith 8663b2100a Indicate etcdv3 support for multiple workspaces 2021-03-10 15:36:37 -06:00
Antoine Cotten 3442873cdb
docs: Update link to HCL native syntax spec 2021-03-10 17:47:21 +01:00
Aaron Lane f172585eaa Fix Kitchen-Terraform language in test experiment
This isn't incredibly important, but Kitchen-Terraform is written in and requires tests to be written in Ruby.
2021-02-25 14:12:00 -08:00
Kristin Laemmert 106bcd3bf0
update to match new default branch name (#27909) 2021-02-24 13:36:47 -05:00
Alisdair McDiarmid 79f855b83b
Merge pull request #27840 from OJFord/docs-27554
Document `inline` & `on_failure` behaviour
2021-02-23 13:15:56 -05:00
Martin Atkins 8d37a70987 website: Initial docs for the module integration testing experiment
Since this is still at an early phase and likely to change significantly
in future iterations, rather than attempting to guess on a suitable final
location for documenting the testing feature I've instead taken the
unusual approach of adding a new page that is explicitly about the
experiment. My expectation is that once we conclude the experiment we'll
replace this new page with a stub that just explains that there was once
an experiment and then links to whatever final feature unfolded from the
research.

The URL for this page is hard-coded into the warning message in the
"terraform test" command, so as we continue to evolve this feature in
future releases we'll need to update the callout note on the page about
which Terraform CLI version it's currently talking about, so users of
older versions can clearly see when they'd need to upgrade in order to
participate in a later incarnation of the experiment.
2021-02-22 14:21:45 -08:00
Oliver Ford 2f7c368d91
Document `inline` & `on_failure` behaviour
cf. #27554
2021-02-19 17:56:48 +00:00
Pam Selle 8d2fbd4cd8
Remove deprecation on undeclared variable, docs, and summary adjustment (#27795)
* Remove deprecation on undeclared variable

Remove deprecation and add docs specific to the behavior around
undeclared variable values

* Limit full warnings to 2 instances, then summary

This way, the third warning is a summary, rather than the fourth
warning being the summary
2021-02-18 11:11:52 -05:00
James Bardin d54a9b176b
Update website/docs/language/providers/configuration.html.md
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-02-12 14:57:51 -05:00
James Bardin e40727076f
Update website/docs/language/modules/develop/providers.html.md
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-02-12 14:57:26 -05:00
James Bardin 9859d4e70b
Update website/docs/language/modules/develop/providers.html.md
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-02-12 14:55:57 -05:00
James Bardin dfd8424392 link configuration aliases between pages 2021-02-12 14:54:55 -05:00
James Bardin 1bb602859a update docs for configuration_aliases
Remove references to the "proxy configuration block" concept, and add
examples showing the usage of `configuration_aliases`.
2021-02-12 11:45:41 -05:00
Stephen e39abbf6f0
fix regex logical or documentation (#27637)
* fix regex logical or documentation

Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-02-08 11:04:38 -05:00
Robin Norwood 181048b913 Add crosslink to new Learn tutorial 2021-02-04 13:43:03 -06:00
Nick Fagerlund 4e4f6b3f42 website: Restore note about standard vs. enhanced backends 2021-01-22 12:22:21 -08:00
Nick Fagerlund d1e8537b33 website: CLI: Update links to moved docs pages 2021-01-22 12:22:21 -08:00
Nick Fagerlund b909a4a3a1 website: Move hidden attr-as-blocks page into new URL structure
This is a "ghost page" that remains relevant and useful, under certain rare
circumstances.
2021-01-22 12:22:21 -08:00
Nick Fagerlund 8cfcd82be3 website: Language: Remove several ghost pages, update links
During the language/CLI docs reorg, we noticed several pages that were no longer
viable; some were redundant, some useless, and some just very obsolete.

Since we were trying to avoid breaking links at the time, we opted to remove
them from the navs and leave them as "ghost pages" — still accessible, but not
findable.

This commit finally cleans these ghosts up and updates any remaining links to
relevant modern pages. Bustin' makes me feel good. 👻🚫
2021-01-22 12:22:21 -08:00
Nick Fagerlund 7a8dd326c6 website: Language: Update links to moved pages 2021-01-22 12:22:21 -08:00
Nick Fagerlund 78dcc8dc1b website: Language: Move files to match new URL structure 2021-01-22 12:22:21 -08:00