167 Commits (adf4dbdf84df2da976c0f2166e1897faec2fa948)

Author	SHA1	Message	Date
Laura Pacilio	a8d949a590	Add compatibility promises to sidebar toc	5 years ago
Kristin Laemmert	583859e510	commands: `terraform add` (#28874) ... * command: new command, terraform add, generates resource templates terraform add ADDRESS generates a resource configuration template with all required (and optionally optional) attributes set to null. This can optionally also pre-populate nonsesitive attributes with values from an existing resource of the same type in state (sensitive vals will be populated with null and a comment indicating sensitivity) * website: terraform add documentation	5 years ago
Kristin Laemmert	9ca3cb4233	website/docs: move type func docs to a useful location (#28940) ... * website/docs: move type func docs to a useful location * docs don't exist if you don't put them in the index (again)	5 years ago
Martin Atkins	07aa07f5b9	website: First Draft of Upgrade Guide	5 years ago
Martin Atkins	035d1648e4	website: Link to the v0.15 upgrade guide ... Unfortunately it seems that this link got lost in a merge conflict when we did the big nav refactor earlier in the v0.15 cycle, so here we'll retoractively add it to the new location for upgrade guide nav, in the language layout rather than the downloads layout.	5 years ago
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.	5 years ago
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.	5 years ago
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.	5 years ago
Nick Fagerlund	01a449e335	website: CLI: Update sidebar nav with new URLs	5 years ago
Nick Fagerlund	7a8dd326c6	website: Language: Update links to moved pages	5 years ago
Nick Fagerlund	b71786d9de	website: Language: Update sidebar nav with new URLs ... The files aren't moved as of this commit, but this serves as a map for the subsequent changes.	5 years ago
Nick Fagerlund	66f2c82d33	website: Add version command to sidebar nav and to plugins overview page	5 years ago
Nick Fagerlund	ccb205896d	website: Fix alphabetical ordering of commands	5 years ago
Nick Fagerlund	5ceb8b2b98	website: Adopt `terraform_remote_state` into language docs ... ...and also shrink the explanation for alternate sharing approaches, a bit. Actually, it looks like I already half-adopted it by accident. 😬 But this commit adds it to the sidebar under "State", so users can browse to it. I'm leaving the URL alone, because it's not urgent and we'll need to adjust a large swath of URLs at some point anyway. This change effectively stops presenting `terraform` as a provider in the normal sense, and reduces /docs/providers/terraform/index.html to a ghost page in the language section (to avoid breaking links for the time being). The message a reader should get is that Terraform has one special built-in data source where you don't need to think about the provider or its version.	5 years ago
Nick Fagerlund	cc6a226bcf	website: Remove provider category indexes, reduce main list ... As of December 18, 2020, we've redirected nearly all of the provider documentation that used to live on terraform.io: - For providers that got published on the Registry, we redirected each docs page to the corresponding Registry docs page. - For providers that never got adopted by a new publisher, we archived the GitHub repository and redirected each docs page to the corresponding Markdown source file on github.com. (For an example of these redirects, see https://www.terraform.io/docs/providers/telefonicaopencloud/r/s3_bucket.html) There are ten providers left that we haven't redirected. These ones got adopted by new publishers and _will_ end up on the Registry, but they aren't quite ready to ship and get their permanent redirects, and we don't want to sabotage their SEO by 301ing to a temporary destination.	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.	6 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.	6 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.	6 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.	6 years ago
Kristin Laemmert	79fd81775e	website/intro: remove outdated examples section (#26932)	6 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.	6 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"	6 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.	6 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.	6 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.	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
Nick Fagerlund	b98525ecc0	website: Decommission derelict "guides" section, move some content to "intro" ... Guides was already mostly gone. The two major remaining bits (the "core workflow" guide and the "recommended practices" guide, which deserves a rename) make much more sense as highly technical marketing material, and thus have a natural home in the intro section.	6 years ago
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.	6 years ago
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.	6 years ago
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.)	6 years ago
Martin Atkins	e1aff2bab0	website: First draft of v0.14 upgrade guide ... The upgrade requirements for this release are considerably more modest than for Terraform v0.13, so this time we just have some notes about a few changes in behavior that may be impactful to some users. This first pass is intended to be included as part of a forthcoming beta testers' guide as we begin the v0.14 beta testing period. We will make further changes to this upgrade guide based on feedback from those who participate in the beta process. Note that this upgrade guide is not intended as release marketing material and so its presentation is focused on addressing concerns users might encounter while upgrading. We'll share highlights from the release in other contexts, such as the changelog and in the product blog.	6 years ago
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.	6 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>	6 years ago
Arthur Burkart	6ed47c7241	lang/funcs: Add "alltrue" function (#25656) ... This commit adds an `alltrue` function to Terraform configuration. A reason we might want this function is because it will enable more powerful custom variable validations. For example: ```hcl variable "amis" { type = list(object({ id = string })) validation { condition = (alltrue([ for a in var.amis : length(a.id) > 4 && substr(a.id, 0, 4) == "ami-" ])) error_message = "The ID of at least one AMI was invalid." } } ```	6 years ago
Pam Selle	7032e651a8	Merge pull request #25927 from hashicorp/aug20_mirror_sidebar ... website: fix nav link text for 'providers mirror'	6 years ago
Martin Atkins	2bd2a9a923	internal/getproviders: HTTPMirrorSource implementation ... We previously had this just stubbed out because it was a stretch goal for the v0.13.0 release and it ultimately didn't make it in. Here we fill out the existing stub -- with a minor change to its interface so it can access credentials -- with a client implementation that is compatible with the directory structure produced by the "terraform providers mirror" subcommand, were the result to be published on a static file server.	6 years ago
Nick Fagerlund	ff9218c105	website: fix nav link text for 'providers mirror'	6 years ago
Kristin Laemmert	470298006f	website: add providers mirror command to providers sidebar	6 years ago
Pam Selle	f63b261fca	Merge pull request #25791 from hashicorp/aug20_provisioners_nav ... website: Move provisioners into language section of nav sidebar	6 years ago
Petros Kolyvas	50b2f0f9b2	Fix sidebar link for Terraform standard backends to include link to Kubernetes backend docs (#25792) ... * website/layouts/backend-types.erb * Update backend-types.erb	6 years ago
Nick Fagerlund	30b983e1e8	website: Move provisioners into language section of nav sidebar	6 years ago
Nick Fagerlund	7bc75a1804	website: Edits to updated Registry documentation ... - Edits to registry overview - Add index link as 'overview' (header links are semi-invisible) - move providers/overview.html to providers/index.html - Edits to providers overview - fix filename of os-arch - edits to provider publishing	6 years ago
Tony Carmichael	cde98a3172	website: Update Registry documentation for Terraform 0.13 release ... Co-authored-by: Tom Bamford <tbamford@hashicorp.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
Paul Tyng	19265fe4b0	Add recommend os/arch page	6 years ago
Sune Keller	4438df6131	website: Add cidrsubnets to IP Network Functions index (#25185) ... Signed-off-by: Sune Keller <absukl@almbrand.dk>	6 years ago
Justin Campbell	e85376990d	website: Terraform Registry Provider Publishing docs (#25378) ... * website: Terraform Registry Provider Publishing * website: (Registry) remove OS/arch recommendation Until we have a canonical list to point to Co-authored-by: Paul Tyng <ptyng@hashicorp.com> Co-authored-by: Paul Tyng <ptyng@hashicorp.com>	6 years ago
Martin Atkins	02b130cd59	website: Terraform v0.13 upgrade guide	6 years ago
Martin Atkins	f1ea705dbe	website: Restore the docs for "terraform 0.12upgrade" ... Although this command is removed in Terraform 0.13, our documentation is for all versions of Terraform that remain in common use and keeping this documented will be helpful for folks who are still using Terraform 0.11 and planning their upgrades to Terraform 0.12. Both of the upgrade commands now include notes that they are only available in their specific major version, along with a link to the relevant upgrade guide for other background information about the upgrade, in case the user finds the command documentation first. (The command docs are, I think, a little more discoverable than the upgrade guides.)	6 years ago