Commit Graph

330 Commits

Author SHA1 Message Date
Petros Kolyvas 5cb2d4894c
Anytrue alltrue docs clarification. (#27108)
* Anytrue alltrue docs clarification.

* Update alltrue.html.md

I can't spell.

* Update anytrue.html.md

Yes, I can't spell.
2020-12-03 10:13:20 -04:00
Nick Fagerlund cca1bc91c3 website: fix bad layout in defaults function page
This layout no longer exists.
2020-12-02 14:11:44 -08:00
Nick Fagerlund 5cff04b3ab website: fix malformed yaml in a few function pages 2020-12-02 14:11:32 -08:00
Martin Atkins 832bd5f41f website: Initial docs for the provider_sensitive_attrs experiment
This is under a heading "Sensitive Resource Attributes" on the assumption
that if we later stabilize this feature then this heading will live on
with some different content that describes the propagation of sensitive
values from resource attributes, rather than describing the experiment.
2020-12-02 08:06:08 -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 d5950b7fd2 website: link to dependency lock file tutorial 2020-12-01 15:20:14 -08:00
Nick Fagerlund 652b48bb49 website: link to sensitive variables tutorial 2020-12-01 15:16:16 -08:00
Nick Fagerlund a1e73ade61 website: link to expressions tutorial where applicable
This tutorial uses references to local values, conditional expressions,
and splat expressions, so I've added it to those pages as well as the
expressions overview.
2020-12-01 13:12:12 -08:00
Nick Fagerlund 5895472c93 website: link to functions tutorial where applicable 2020-12-01 13:10:05 -08:00
Martin Atkins df47da1f8e website: "coalesce" function unifies its argument types
In order to be able to predict a result type even if arguments are not yet
known, coalesce requires all of its arguments to be of the same type. Our
usual automatic conversion rules mean that in some cases the result is
a silent type conversion rather than an explicit error, so we'll at least
document that so that folks who encounter it can understand what is
causing the likely-surprising behavior.

If we were building this function over again today I expect we'd make it
always return an error under type mismatch, but to do so now would be a
breaking change and the potential cost of that seems too high for
something that doesn't seem to arise incredibly often in practice.
2020-11-18 08:03:37 -08:00
Nick Fagerlund 2bfec75bbf website: Update all links to {expressions,modules,resources}.html
...as well as to the standard module structure section in module development.
2020-11-17 16:30:51 -08:00
Nick Fagerlund 209541aaf0 website: Break up main Modules and Module Development pages
This one is a lot like the previous two commits, but slightly more complex:

- Only adding one new meta-argument page, for `providers`; otherwise, it just
  re-uses the dual-purpose pages I made in the resources commit.

- About that `providers` argument: The stuff that was relevant to consumers of a
  module went in that meta-argument page, but there was also a huge deep dive on
  how the _author_ of a re-usable module should handle provider configurations
  in cases where inheriting the default providers isn't sufficient. THAT, I
  moved into a new page in the module development section. (For the consumer of
  a module, this should all be an implementation detail; the module README
  should tell you which aliased providers you need to configure and pass, and
  then you just do it, without worrying about proxy configuration blocks etc.)

- The "standard module structure" recommendations in the main module development
  page gets a page of its own, to make it more prominent and discoverable.

- Same deal with using the old URL as a landing page, at least for the main
  module calls page. It didn't seem necessary for the module development page.
2020-11-17 16:30:51 -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 a446ecb7b7 website: Break up Expressions page into smaller chunks
This commit converts the previous URL for this content to a landing page, which
captures all of the previous in-page anchors and directs readers to the new home
for each section.
2020-11-17 16:30:51 -08:00
Martin Atkins cec4578005 lang/funcs: Experimental "defaults" function
This is a new part of the existing module_variable_optional_attrs
experiment, because it's intended to complement the ability to declare
an input variable whose type constraint is an object type with optional
attributes. Module authors can use this to replace null values (that were
either explicitly set or implied by attribute omission) with other
non-null values of the same type.

This function is a bit more type-fussy than our functions typically are
because it's intended for use primarily with input variables that have
fully-specified type constraints, and thus it uses that type information
to help inform how the defaults data structure should be interpreted.

Other uses of this function will probably be harder today because it takes
a lot of extra annotation to build a value of a specific type if it isn't
passing through a variable type constraint. Perhaps later language
features for more general type conversion will make this more applicable,
but for now the more general form of this problem is better solved other
ways.
2020-11-13 17:27:20 -08:00
Pam Selle 9f5f5adc0d
Merge pull request #26799 from flatiron32/patch-1
Remove redundant Local Named Values section
2020-11-13 11:39:33 -05:00
Nick Fagerlund 5e18e44037
Merge pull request #26723 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
Nick Fagerlund 2c02233a16 website: Add new "glue"/overview pages for CLI and language docs
The new nav structure demanded a few new pages that give context about a feature
or workflow. In a few cases, they take text from an existing page.

Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
Co-authored-by: Judith Malnick <judith.patudith@gmail.com>
2020-11-11 19:13:23 -08:00
Robin Norwood ec7d9c85ac Update link to new varibles tutorial 2020-11-09 11:52:28 -08:00
Joshua Mendoza 27e31e1160
Update lookup.html.md (#26835)
Typo in introductory paragraph.
2020-11-06 09:58:33 -04:00
Martin Atkins ae3c0c6a4a lang/funcs: Remove the deprecated "list" and "map" functions
Prior to Terraform 0.12 these two functions were the only way to construct
literal lists and maps (respectively) in HIL expressions. Terraform 0.12,
by switching to HCL 2, introduced first-class syntax for constructing
tuple and object values, which can then be converted into list and map
values using the tolist and tomap type conversion functions.

We marked both of these functions as deprecated in the Terraform v0.12
release and have since then mentioned in the docs that they will be
removed in a future Terraform version. The "terraform 0.12upgrade" tool
from Terraform v0.12 also included a rule to automatically rewrite uses
of these functions into equivalent new syntax.

The main motivation for removing these now is just to get this change made
prior to Terraform 1.0. as we'll be doing with various other deprecations.
However, a specific reason for these two functions in particular is that
their existence is what caused us to invent the idea of a "type expression"
as a distinct kind of expression in Terraform v0.12, and so removing them
now would allow potentially  unifying type expressions with value
expressions in a future release.

We do not have any current specific plans to make that change, but one
potential motivation for doing so would be to take another attempt at a
generalized "convert" function which takes a type as one of its arguments.
Our previous attempt to implement such a function was foiled by the fact
that Terraform's expression validator doesn't have any way to know to
treat one argument of a particular function as special, and so it was
generating incorrect error messages. We won't necessarily do that, but
having these "list" and "map" functions out of the way leaves the option
open.
2020-11-04 17:05:59 -08:00
Radek Simko eddcc4d80c
docs: Fix typo (provider arg in data source) (#26802) 2020-11-04 09:55:15 -04:00
Jacob Tomaw 3f9abbc30d
Remove redundant Local Named Values section
The second Local Named Values has a subset of the information the first one has and adds nothing to the documentation other than confusion.
2020-11-03 08:09:12 -05:00
timvandamme fbf267fbfd
website: for_each doesn't implicitly convert to set (#26450)
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
Radek Simko a413fa7425
Merge pull request #26763 from hashicorp/radeksimko-patch-1
docs: fix typo in provider local name
2020-10-31 08:37:33 +00:00
Repon Kumar Roy 34549b402b website: clarify version constraint syntax 2020-10-30 17:44:48 -07:00
Nick Fagerlund a058b64eb5
website: Index for `element` must be a non-negative integer (#26679)
* The index must be non-negative integer

and added instructions on how to get the last value in the list.

* Typo fix

Co-authored-by: Nick Fagerlund <nick@hashicorp.com>
2020-10-30 17:43:35 -07:00
Nick Fagerlund 5a4957f141
Typo fix 2020-10-30 17:42:40 -07:00
Nick Fagerlund a0fee4c380 website: one more provider name typo 2020-10-30 17:35:23 -07:00
Radek Simko 8476c3f13e
docs: fix typo in provider local name 2020-10-30 21:59:19 +00: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
Alex Litvinenko 1a371c3c49
Small spelling improvement
It seems that the word `with` is redundant in the following sentence:

> For a module with without count or for_each, the address will not...
2020-10-26 19:50:21 +01:00
Kristin Laemmert b8e3b8036a backend: remove deprecated atlas backend 2020-10-26 14:05:18 -04:00
Martin Atkins ddf9635af6 website: Don't claim that things are "very easy"
We typically try to avoid making subjective, boasty claims in our
documentation in recent times, but there remained both some older
documentation that we've not recently revised and also some newer examples
that are, in retrospect, also perhaps more "boasty" than they need to be.

We prefer not to use this sort of boasty language because not everyone
using Terraform has the same background and experience, and so what is
"easy" or "intuitive" to one person may not be so to another person, and
that should not suggest that the second person is in any way wrong or
inadequate.

In reviewing some of our use of the word "easy" here I tried as much as
possible to surgically revise the existing content without getting drawn
into a big rewrite, but in some cases the content was either pretty
unsalvageable (due to talking about obsolete features that were removed
long ago) or required some broader changes to make the result hopefully
still get the same facts across. In those cases I've both removed some
content entirely or adjusted larger paragraphs.

This was not an exhaustive review and so I'm sure there's still plenty of
room for similar improvements elsewhere. I also resisted the urge to
update some pages that contain outdated information about currently-active
features.
2020-10-26 10:02:38 -07:00
Arthur Burkart d4716a69e1
lang/funcs: "anytrue" function
This is an analog to the "alltrue" function, using OR as the reduce
operator rather than AND.

This also includes some simplification of the "alltrue" implementation
to implement it similarly as a sort of reduce operation with AND
as the reduce operator, but with the same effective behavior.
2020-10-23 13:52:48 -07:00
Petros Kolyvas b1671b2ce1
website: Fix for documentation around local-name conflicts (#26689)
* Fixes #26684

* Update provider-requirements.html.md

Removing additional/extra newlines

* Update provider-requirements.html.md

And now some trailing spaces. le sigh
2020-10-23 15:16:45 -03:00
craiggenner 6408533fca
The index must be non-negative integer
and added instructions on how to get the last value in the list.
2020-10-22 19:03:27 +01:00
Martin Atkins 1dc4950bfa lang/funcs: Rename the base64 character encoding functions
These were initially introduced as functions with "encode" and "decode"
prefixes, but that doesn't match with our existing convention of putting
the encoding format first so that the encode and decode functions will
group together in a alphabetically-ordered function list.

"text" is not really a defined serialization format, but it's a short word
that hopefully represents well enough what these functions are aiming to
encode and decode, while being consistent with existing functions like
jsonencode/jsondecode, yamlencode/yamldecode, etc.

The "base64" at the end here is less convincing because there is precedent
for that modifier to appear both at the beginning and the end in our
existing function names. I chose to put it at the end here because that
seems to be our emergent convention for situations where the base64
encoding is a sort of secondary modifier alongside the primary purpose
of the function, as we see with "filebase64". (base64gzip is an exception
here, but it seems outvoted by the others.)
2020-10-21 10:56:56 -07:00
r0bnet 877399c631 lang/funcs: Functions for encoding text in specific character encodings 2020-10-21 10:39:43 -07:00
Martin Atkins 0bbbb9c64b configs: Experimental support for optional object type attributes
This builds on an experimental feature in the underlying cty library which
allows marking specific attribtues of an object type constraint as
optional, which in turn modifies how the cty conversion package handles
missing attributes in a source value: it will silently substitute a null
value of the appropriate type rather than returning an error.

In order to implement the experiment this commit temporarily forks the
HCL typeexpr extension package into a local internal/typeexpr package,
where I've extended the type constraint syntax to allow annotating object
type attributes as being optional using the HCL function call syntax.
If the experiment is successful -- both at the Terraform layer and in
the underlying cty library -- we'll likely send these modifications to
upstream HCL so that other HCL-based languages can potentially benefit
from this new capability.

Because it's experimental, the optional attribute modifier is allowed only
with an explicit opt-in to the module_variable_optional_attrs experiment.
2020-10-12 10:12:28 -07:00
Martin Atkins 897cb72b36 website: Initial docs for the new dependency lock file behaviors
This includes both the main documentation about the lock file itself and
changes to related documentation about Terraform commands that interact
with the lock file.

We will likely continue to update this first pass of documentation as we
get feedback and questions during the prerelease period.
2020-10-09 09:26:23 -07:00
Pam Selle 9a9e61ef06 Update docs for output sensitivity change 2020-10-06 14:26:16 -04:00
Pam Selle cc007a27b7
Merge pull request #26482 from hashicorp/pselle/sensitive-var-nested-docs
Add sensitive variable docs for nested blocks
2020-10-06 10:16:26 -04:00
Pam Selle 4d01fc88fc Add sensitive variable docs for nested blocks
Add note to docs about nested block behavior for sensitive variables
2020-10-05 17:23:49 -04: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 #26421 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 (#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>
2020-10-02 11:02:59 -07:00
Pam Selle a7e43dfd46
Merge pull request #26431 from hashicorp/pselle/sensitive-vals-docs
docs: Docs for sensitive variables
2020-10-01 13:50:11 -04:00
Pam Selle 3ddbb4b009 Update provider caveat grammar 2020-10-01 13:19:14 -04:00
Pam Selle 93d38ff2d2 Update intro to code blocks 2020-10-01 13:16:15 -04:00