Commit Graph

28128 Commits

Author SHA1 Message Date
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
James Bardin 0346effec7
Merge pull request #27064 from hashicorp/jbardin/protobuf
Regenerate protobuf files using the correct version of protoc-gen-go
2020-12-01 15:31:26 -05:00
James Bardin 15dad81e2b udpate some tests with unexported gocmp options 2020-12-01 14:07:36 -05:00
James Bardin 913f6c2091 regenerate the plans proto with current tooling 2020-12-01 14:07:15 -05:00
James Bardin ccf19fbf5e regenerate plugin proto with correct tooling
The proto file is structurally unchanged, though it now requires a go
import path option.
2020-12-01 14:06:49 -05:00
James Bardin b6980c2fad update proto packages 2020-12-01 14:04:24 -05:00
Paul Tyng c4b46a5c98
Update signing.html.md 2020-11-30 16:13:49 -05:00
James Bardin 8a261e2160
Merge pull request #27057 from hashicorp/jbardin/cli
Redirect Warn to Output in the UI
2020-11-30 15:06:22 -05:00
James Bardin a75dcd4be0 warning are now in stdout 2020-11-30 12:38:11 -05:00
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.
2020-11-30 12:29:44 -05:00
James Bardin 8c1e448b6b update mitchellh/cli 2020-11-30 12:13:49 -05:00
Alisdair McDiarmid 5c7b03f700
Merge pull request #27055 from hashicorp/alisdair/hcl-v2.7.2
Upgrade to hcl v2.7.2
2020-11-30 12:10:58 -05:00
Alisdair McDiarmid 7256738835 go get github.com/hashicorp/hcl/v2@v2.7.2 2020-11-30 11:24:54 -05:00
Alisdair McDiarmid 9d7d0b51ff
Merge pull request #27045 from hashicorp/alisdair/output-heredocs
repl: Display multi-line strings as heredocs
2020-11-30 11:24:41 -05:00
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.
2020-11-26 11:42:31 -05:00
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.
2020-11-25 08:03:37 -08:00
James Bardin f6d6446701
Merge pull request #27005 from hashicorp/jbardin/provider-cache-test
Fix providercache tests on MacOS
2020-11-23 15:58:11 -05:00
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.
2020-11-20 16:35:31 -05:00
Pam Selle a44a50a8b5
Merge pull request #26999 from hashicorp/pselle/diags
Fix diags non-assignment bugs
2020-11-20 15:55:05 -05:00
Alisdair McDiarmid 42437482e5
Merge pull request #26947 from hashicorp/alisdair/backend-validate-remote-backend-terraform-version
backend: Validate remote backend Terraform version
2020-11-20 13:50:05 -05:00
Pam Selle c55b69e30a Fix diags non-assignment bugs
Fix places where diags was not reassigned when diags were added.
2020-11-20 13:37:23 -05:00
Pam Selle 9ac9564207
Merge pull request #26986 from hashicorp/pselle/validate-sensitive
Unmark values before provider validate call
2020-11-20 11:25:27 -05:00
Pam Selle d626a7787d Add integration test in context_validate 2020-11-20 11:16:07 -05:00
Pam Selle b1e229ef6c Give test types cty types 2020-11-20 10:44:37 -05:00
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
2020-11-19 18:04:33 -05:00
Nick Fagerlund f488a75998
Merge pull request #26968 from hashicorp/nov20_remove_registry
website: Remove registry docs (adopted into terraform-website)
2020-11-19 14:43:41 -08:00
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.
2020-11-19 14:15:30 -08:00
Martin Atkins 24d6c74e97 version: This tree is currently working towards the 0.15.0 release 2020-11-19 14:15:30 -08:00
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.
2020-11-19 13:19:40 -05:00
Martin Atkins b8d448de83
Update CHANGELOG.md 2020-11-18 15:17:40 -08:00
Alisdair McDiarmid 1f020a3aa7
Merge pull request #26971 from hashicorp/alisdair/faster-remote-backend-tests
backend: Faster remote backend tests
2020-11-18 16:30:30 -05:00
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.
2020-11-18 16:00:05 -05:00
Alisdair McDiarmid 31b4e1ee40
Merge pull request #26964 from hashicorp/alisdair/fmt-blank-labels
command: Fix fmt to preserve blank block labels
2020-11-18 15:04:17 -05:00
Martin Atkins 69c3500715
Update CHANGELOG.md 2020-11-18 11:28:43 -08:00
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.
2020-11-18 11:26:42 -08:00
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.
2020-11-18 11:12:35 -08:00
Nick Fagerlund db82b80c9d website: Fix a random typo in azurerm backend 2020-11-18 10:47:52 -08:00
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>
2020-11-18 10:45:27 -08:00
Alisdair McDiarmid 21d80a26ea command: Fix fmt to preserve blank block labels 2020-11-18 11:59:10 -05:00
Martin Atkins c71aa16d41
Update CHANGELOG.md 2020-11-18 08:24:07 -08:00
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.
2020-11-18 08:20:25 -08:00
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.
2020-11-18 08:04:41 -08:00
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.
2020-11-18 08:04:10 -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
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.
2020-11-18 08:01:05 -08:00
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
2020-11-17 16:36:19 -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