terraform

Commit Graph

Author	SHA1	Message	Date
James Bardin	ccf19fbf5e	regenerate plugin proto with correct tooling The proto file is structurally unchanged, though it now requires a go import path option.	5 years ago
James Bardin	b6980c2fad	update proto packages	5 years ago
James Bardin	8a261e2160	Merge pull request #27057 from hashicorp/jbardin/cli Redirect Warn to Output in the UI	5 years ago
James Bardin	a75dcd4be0	warning are now in stdout	5 years ago
James Bardin	0c3bb316ea	redirect warnigns to stdout The default cli Warn calls always write to the error writer (stderr by default), however the output is intended to be viewed in the UI by the user, rather than in a separate stream. Terraform also generally does not consider warnings to be errors from the cli point of view, and does not need to output the warning text to stderr. By redirecting Warn calls to Output calls at the lowest level in the main package, we can eliminate the chance that Warn and Output messages are interleaved, while still allowing the internal `cli.Ui` implementations to format `Warn` and `Output` calls separately.	5 years ago
James Bardin	8c1e448b6b	update mitchellh/cli	5 years ago
Alisdair McDiarmid	5c7b03f700	Merge pull request #27055 from hashicorp/alisdair/hcl-v2.7.2 Upgrade to hcl v2.7.2	5 years ago
Alisdair McDiarmid	7256738835	go get github.com/hashicorp/hcl/v2@v2.7.2	5 years ago
Alisdair McDiarmid	9d7d0b51ff	Merge pull request #27045 from hashicorp/alisdair/output-heredocs repl: Display multi-line strings as heredocs	5 years ago
Alisdair McDiarmid	4e7607deb5	repl: Display multi-line strings as heredocs The console and output formatter previously displayed multi-line strings with escaped newlines, e.g. `"hello\nworld\n"`. While this is a valid way to write the HCL string, it is not as common or as readable as using the heredoc syntax, e.g. <<EOF hello world EOF This commit adds heredoc detection and display to this formatter, including support for indented heredocs for nested multi-line strings. This change affects the apply, console, and output sub-commands.	5 years ago
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
James Bardin	f6d6446701	Merge pull request #27005 from hashicorp/jbardin/provider-cache-test Fix providercache tests on MacOS	5 years ago
James Bardin	7eb491719f	normalize temp dir paths in tests The temporary directory on some systems (most notably MacOS) contains symlinks, which would not be recorded by the installer. In order to make these paths comparable in the tests we need to eval the symlinks in the paths before giving them to the installer.	5 years ago
Pam Selle	a44a50a8b5	Merge pull request #26999 from hashicorp/pselle/diags Fix diags non-assignment bugs	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
Pam Selle	c55b69e30a	Fix diags non-assignment bugs Fix places where diags was not reassigned when diags were added.	5 years ago
Pam Selle	9ac9564207	Merge pull request #26986 from hashicorp/pselle/validate-sensitive Unmark values before provider validate call	5 years ago
Pam Selle	d626a7787d	Add integration test in context_validate	5 years ago
Pam Selle	b1e229ef6c	Give test types cty types	5 years ago
Pam Selle	578a3d89d1	Unmark values before provider validate call Unmark values before calling provider's validate function, this was not tested as the mock provider does not use Marshall. Update mock provider funcs to marshall and error if there was an error in marshalling	5 years ago
Nick Fagerlund	f488a75998	Merge pull request #26968 from hashicorp/nov20_remove_registry website: Remove registry docs (adopted into terraform-website)	5 years ago
Martin Atkins	0a596d2a12	command/version: Report the current platform Along with all of the other information we previously reported in the "terraform version" output, we'll now include the name of the current platform as our provider mechanisms represent it. This is addressing a long-standing minor annoyance where we often can't tell from an incomplete bug report which platform Terraform was running on, and incomplete bug reporters do tend to at least include the "terraform version" output even if they don't also include the requested full trace log. However, what motivated doing it _now_ is that anyone building a provider registry or mirror needs to have some awareness of these platform identifiers which have been, until v0.13, mostly an implementation detail. This additional information is a small thing we can do to help registry builders find out what the platform identifier ought to be for each of the platforms they aim to support, even if some of them are platforms which the Go compiler allows but which HashiCorp doesn't officially support. The new information is on a line of its own in the output as a pragmatic way to avoid breaking anyone who might be using something like $(terraform version \| head -n1) to print a brief Terraform version identifier into some logs. That's not an interface we officially support for machine consumption, but it's easy to avoid breaking it here and so we won't do so.	5 years ago
Martin Atkins	24d6c74e97	version: This tree is currently working towards the 0.15.0 release	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
Martin Atkins	b8d448de83	Update CHANGELOG.md	5 years ago
Alisdair McDiarmid	1f020a3aa7	Merge pull request #26971 from hashicorp/alisdair/faster-remote-backend-tests backend: Faster remote backend tests	5 years ago
Alisdair McDiarmid	eee57280f6	backend: Faster remote backend tests The remote backend tests spent most of their execution time sleeping in various polling and backoff waits. This is unnecessary when testing against a mock server, so reduce all of these delays when under test to much lower values. Only one remaining test has an artificial delay: verifying the discovery of services against an unknown hostname. This times out at DNS resolution, which is more difficult to fix than seems worth it at this time.	5 years ago
Alisdair McDiarmid	31b4e1ee40	Merge pull request #26964 from hashicorp/alisdair/fmt-blank-labels command: Fix fmt to preserve blank block labels	5 years ago
Martin Atkins	69c3500715	Update CHANGELOG.md	5 years ago
Martin Atkins	28d2cb55fd	main: Special error message for invalid top-level command Previously Terraform would react to an invalid top-level command the same way as for typing no command at all: just printing out the long top-level help directory. If someone's tried to type a command, it's more helpful to respond to that request by explaining directly that the command is invalid, rather than leaving the user to puzzle that out themselves by referring to the help text. As a bonus, this also allows us to use our "didyoumean" package to suggest possible alternatives if it seems like the user made a typo.	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
Alisdair McDiarmid	21d80a26ea	command: Fix fmt to preserve blank block labels	5 years ago
Martin Atkins	c71aa16d41	Update CHANGELOG.md	5 years ago
Martin Atkins	eed6b3c48b	configs: Emit a warning for backends in nested modules Terraform considers backend configurations only in the root module, so any declarations in child modules are entirely ignored. To avoid users mistakenly thinking that a root module backend configuration has taken effect, we'll now emit a warning about it. This is a warning rather than an error because it's reasonable to call a module that would normally be a root module instead as a child module when writing a wrapper module to handle integration testing.	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
Martin Atkins	eac85b506b	configs: Specialized warning for single-interpolation object keys We have an existing warning message to encourage moving away from the old 0.11-and-earlier style of redundantly wrapping standalone expressions in templates, but due to the special rules for object keys the warning message was giving misleading advice in that context: a user following the advice as given would then encounter an error about the object key being ambiguous. To account for that, this introduces a special alternative version of the warning just for that particular position, directing the user to replace the template interpolation markers with parenthesis instead. That will then get the same result as the former interpolation sequence, rather than producing the ambiguity error.	5 years ago
Nick Fagerlund	6a847df392	Merge pull request #26902 from hashicorp/nov20_breakup_exprs_resources_and_modules website: TF-153: Break up expressions, resources, and modules pages	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
James Bardin	b06db967b7	Merge pull request #26944 from hashicorp/jbardin/module-output-plan Don't render a plan for module outputs	5 years ago
James Bardin	8e7a9b6312	output test for plan with no root output changes Module outputs do not show up in the plan, and are not rendered in the UI.	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
James Bardin	5f4ff0e8be	don't render plan for module outputs Module outputs should not trigger plan rendering.	5 years ago
Kristin Laemmert	79fd81775e	website/intro: remove outdated examples section (#26932 )	5 years ago

1 2 3 4 5 ...

27355 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494) All Branches Search

27355 Commits (ccf19fbf5e2b61ba62efd1ac47a3a3fd3917d494)

All Branches