6196 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

Author	SHA1	Message	Date
Martin Atkins	111825da45	website: More words about "terraform fmt" ... We've historically made statements like this in response to requests for more customization to the "terraform fmt" behavior, but the documentation itself was somewhat vague about the intended goals of this command. This is an attempt to be more explicit that consistency between codebases is the primary goal of this command, and that the examples in the Terraform documentation are our main guide for what is "idiomatic style" when adding additional rules over time. Nothing here is intended to be new policy, but instead as codifying positions we've taken elsewhere in the past in the hope of allowing users to decide how (and whether) they wish to make use of this tool.	5 years ago
Alisdair McDiarmid	42437482e5	Merge pull request #26947 from hashicorp/alisdair/backend-validate-remote-backend-terraform-version ... backend: Validate remote backend Terraform version	5 years ago
Alisdair McDiarmid	c5c1f31db3	backend: Validate remote backend Terraform version ... When using the enhanced remote backend, a subset of all Terraform operations are supported. Of these, only plan and apply can be executed on the remote infrastructure (e.g. Terraform Cloud). Other operations run locally and use the remote backend for state storage. This causes problems when the local version of Terraform does not match the configured version from the remote workspace. If the two versions are incompatible, an `import` or `state mv` operation can cause the remote workspace to be unusable until a manual fix is applied. To prevent this from happening accidentally, this commit introduces a check that the local Terraform version and the configured remote workspace Terraform version are compatible. This check is skipped for commands which do not write state, and can also be disabled by the use of a new command-line flag, `-ignore-remote-version`. Terraform version compatibility is defined as: - For all releases before 0.14.0, local must exactly equal remote, as two different versions cannot share state; - 0.14.0 to 1.0.x are compatible, as we will not change the state version number until at least Terraform 1.1.0; - Versions after 1.1.0 must have the same major and minor versions, as we will not change the state version number in a patch release. If the two versions are incompatible, a diagnostic is displayed, advising that the error can be suppressed with `-ignore-remote-version`. When this flag is used, the diagnostic is still displayed, but as a warning instead of an error. Commands which will not write state can assert this fact by calling the helper `meta.ignoreRemoteBackendVersionConflict`, which will disable the checks. Those which can write state should instead call the helper `meta.remoteBackendVersionCheck`, which will return diagnostics for display. In addition to these explicit paths for managing the version check, we have an implicit check in the remote backend's state manager initialization method. Both of the above helpers will disable this check. This fallback is in place to ensure that future code paths which access state cannot accidentally skip the remote version check.	5 years ago
Nick Fagerlund	2014e8ef64	website: Remove registry docs (adopted into terraform-website) ... The Registry is a web service whose behavior isn't directly tied to Terraform core's release cycle; therefore, its docs should be decoupled from that release cycle as well. https://github.com/hashicorp/terraform-website/pull/1517 adopts the registry docs into hashicorp/terraform-website, which already hosts several other corpuses of documentation that aren't tied to Terraform core's version (like Terraform Cloud, Terraform Enterprise, and Extending Terraform). Once that PR is merged, we should remove the registry docs from this repository to avoid confusing anyone.	5 years ago
Nick Fagerlund	db82b80c9d	website: Fix a random typo in azurerm backend	5 years ago
Nick Fagerlund	f2f47c3c9f	website: Fix title of `terraform providers lock` page (#26956) ... Probably a copy/paste error. Co-authored-by: Petros Kolyvas <petros@hashicorp.com>	5 years ago
Martin Atkins	af3f78975e	website: Fix confusing example for local-exec provisioner ... The local-exec provisioner documentation includes an example which refers to an attribute of the current resource using its full traversal path, rather than using "self" as we typically expect. Due to some coincidences in how Terraform builds the dependency graph, referring to the resource in this way happens to work when the resource has only a single instance (the graph builder just skips that self-referential dependency edge), but it fails if the user later tries to add "count" or "for_each" to the resource, because at that point all of the instances become dependent on one another, which creates a dependency cycle. Using "self" to access the current instance attributes is the usual approach, so I've updated the documentation to show that.	5 years ago
Martin Atkins	9f45a73581	website: Reword confusing statement about module sources in TFE ... As written previously this seemed to suggest using "app.terraform.io" (the "hostname you use to access the Terraform Cloud application) to access a private registry in Terraform Enterprise, but that isn't true and I assume isn't what was intended. Instead, the hostname for a Terraform Enterprise instance is the hostname where the Terraform Enterprise application is running, which is both the hostname where users would find its web UI and the hostname they'd use to configure the "remote" backend for remote operations and state storage.	5 years ago
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.	5 years ago
Nick Fagerlund	2bfec75bbf	website: Update all links to {expressions,modules,resources}.html ... ...as well as to the standard module structure section in module development.	5 years ago
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.	5 years ago
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.	5 years ago
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.	5 years ago
Martin Atkins	6bb9fa7341	website: Document alternatives to terraform_remote_state ... For some time now we've been recommending explicitly passing data between configurations using separate resource types and data sources, rather than always using terraform_remote_state, for reasons including reducing coupling between subsystems and allowing a configuration's state snapshots to be under restrictive access controls. However, those recommendations have so far not appeared directly in the documentation for terraform_remote_state, and have instead just been alluded to elsewhere in the documentation when discussing ways to pass data between configurations. This change, then, is an attempt to be clear and explicit about the recommendation and to give a variety of specific examples of how to implement it. The terraform_remote_state data source page is admittedly not the most obvious place in the information architecture to put a set of alternatives to it, but it does appear that this documentation page is where people most commonly end up when researching options in this area and so I've put this here in an attempt to "meet people where they are". Possibly in a future documentation reorganization we might have an separate page specifically about sharing data between configurations, but we don't currently have time to do that bigger reorganization. If we do so later, the content on this page could potentially be replaced with a summary of the recommendation and a link to another place for the details, but the goal here is to make this information visible in the existing location people look for it, rather than blocking until there's a better place for it to live. This also includes a small amount of editing of some existing content on the page to use terminology and style more similar to how our main configuration language documentation is written,.	5 years ago
Kristin Laemmert	79fd81775e	website/intro: remove outdated examples section (#26932)	5 years ago
Martin Atkins	7ccaee1018	website: Fix inconsistencies in the registry protocol page ... Some hasty, incorrect merge conflict fixing caused this page to have a strange mix of terminology between "system" and "provider". Along with that, there were also several editorial errors caused by text on this page having originally been derived from the provider registry documentation. This documentation will now consistently talk about being a module registry protocol rather than a provider registry protocol, and it will consistently use the term "system" as a generic term for the final part of the module source address, aside from noting that there is an optional convention to name it after the "type" part of an official provider when possible.	5 years ago
Andrew Fitzgerald	8c82b3f6a0	Remove 'system' references from module registry protocol docs.	5 years ago
TEDmk	8195a99529	Add a missing new line ... The missing new line doesn't permit the code block to show up.	5 years ago
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.	5 years ago
Pam Selle	9f5f5adc0d	Merge pull request #26799 from flatiron32/patch-1 ... Remove redundant Local Named Values section	5 years ago
Kent 'picat' Gruber	63cc597bc3	Fix grammar ... Co-authored-by: Pam Selle <pam@hashicorp.com>	5 years ago
Kent 'picat' Gruber	20026819dd	Remove path-style specific wording in module sources doc ... Follow up on wording added in https://github.com/hashicorp/terraform/pull/20377	5 years ago
hhofs	5b99a56fde	communicator/ssh: Add support for Windows targets (#26865)	5 years ago
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"	5 years ago
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>	5 years ago
Nick Fagerlund	d01faf1cb2	website: Remove unused "island" nav sidebars ... The pages that used to use these isolated navs have been adopted into the new unified nav sidebars.	5 years ago
Nick Fagerlund	8b87318b35	website: Add new Language sidebar, repurpose docs.erb as CLI sidebar ... We're splitting the current Terraform CLI docs into two top-level categories, and these are the new nav sidebars for those sections. As of this commit, they refer to some new "glue" pages that don't exist yet.	5 years ago
Martin Atkins	80b13307e8	website: Initial docs about the APT/Yum repositories ... The HashiCorp engineering services team has set up APT and Yum repositories as alternative installation methods for various HashiCorp products, now including Terraform. We don't really have a great place to talk about these in our current website structure. There is a longer-term plan to revamp the downloads page to include other options, but we are already getting lots of questions about how to use these repositories and so my goal here is to publish at least a first pass of documentation, linked from the Downloads page sidebar as a placeholder for now, so we'll have somewhere to refer to when answering such questions. My intent is that even once we have a revamped Downloads page that mentions these options more clearly, we'll still need to link out to another page to talk about various details, and so the two new URLs this creates would be the home of that content, even if we rewrite the specific prose here to work better in the context of the new Downloads page.	5 years ago
Andor Markus	9d3143381b	Update delete.html.md (#26874)	5 years ago
Justin Campbell	7c98be92c2	website: Add Registry docs for webhooks (#26870)	5 years ago
Robin Norwood	ec7d9c85ac	Update link to new varibles tutorial	5 years ago
Upo	3b9c5e5bbb	backend/gcs: remove deprecated "path" config argument (#26841)	6 years ago
Alisdair McDiarmid	3680bc521a	website: Update output command docs ... The example configuration now uses Terraform 0.12+ syntax, and the output examples are up to date with the current text UI. We also add an explicit recommendation to use the `-json` option for a consistent and stable output format, for use in automation.	6 years ago
Upo	4ccc63d79d	backend: Add service account impersonation to GCS Backend and update the docs (#26700)	6 years ago
Joshua Mendoza	27e31e1160	Update lookup.html.md (#26835) ... Typo in introductory paragraph.	6 years ago
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.	6 years ago
Radek Simko	eddcc4d80c	docs: Fix typo (provider arg in data source) (#26802)	6 years ago
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.	6 years ago
Tej-Singh-Rana	832918c65b	website: fixed spelling error (#26758)	6 years ago
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>	6 years ago
Radek Simko	a413fa7425	Merge pull request #26763 from hashicorp/radeksimko-patch-1 ... docs: fix typo in provider local name	6 years ago
tuathail	33ee8a410c	website: Add note re: private_key configuration to intro (#24463)	6 years ago
Repon Kumar Roy	34549b402b	website: clarify version constraint syntax	6 years ago
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>	6 years ago
Nick Fagerlund	5a4957f141	Typo fix	6 years ago
Nick Fagerlund	a0fee4c380	website: one more provider name typo	6 years ago
Radek Simko	8476c3f13e	docs: fix typo in provider local name	6 years ago
alevinetx	66393bb62e	website: Update module-registry-protocol.html.md (#26639) ... * Update module-registry-protocol.html.md 1: There is a mismatch in the segment labels for the version query URL (system vs provider) 2: There is a discrepancy between the documentation and the actual generated request for retrieving module source code (URL segments 4 vs 3) - There is no segment for "provider" * Update module-registry-protocol.html.md Changed ```:system``` to ```:provider``` for versions and source API URLs	6 years ago
Nick Fagerlund	f9b8f6f21f	website: Add wandering Plugin Signing page to publishing sidebar ... This page file was already marked as belonging to the registry publishing docs, but was unreachable because it wasn't included in the nav.	6 years ago
Nick Fagerlund	4cc9585fee	website: Rename registry docs to "Publishing Providers & Modules" ... Also, remove redundant sidebar_current noise from sidebar nav source.	6 years ago