Commit Graph

27338 Commits

Author SHA1 Message Date
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
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
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
James Bardin b06db967b7
Merge pull request #26944 from hashicorp/jbardin/module-output-plan
Don't render a plan for module outputs
2020-11-17 16:35:54 -05:00
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.
2020-11-17 16:11:57 -05:00
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,.
2020-11-17 09:41:54 -08:00
James Bardin 5f4ff0e8be don't render plan for module outputs
Module outputs should not trigger plan rendering.
2020-11-17 09:31:18 -05:00
Kristin Laemmert 79fd81775e
website/intro: remove outdated examples section (#26932) 2020-11-16 14:05:17 -05:00
Alisdair McDiarmid 7cfba365dc
Merge pull request #26936 from hashicorp/alisdair/unmark-provider-arguments
terraform: Unmark provider configuration arguments
2020-11-16 14:01:02 -05:00
Alisdair McDiarmid 1c7f412d13 terraform: Unmark provider configuration arguments
Before configuring a provider, we need to unmark the configuration
object, in case it includes any sensitive values. This is required
because configuration occurs over gRPC, which doesn't support sensitive
marks.
2020-11-16 13:13:20 -05:00
Martin Atkins a977d2e8d4
Merge #25964: Fix inconsistencies in the Module Registry Protocol docs 2020-11-16 10:12:46 -08:00
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.
2020-11-16 10:06:27 -08:00
Andrew Fitzgerald 8c82b3f6a0 Remove 'system' references from module registry protocol docs. 2020-11-16 10:01:03 -08:00
Kristin Laemmert c1d30401c5
Merge pull request #26931 from TEDmk/patch-1
website/docs: Add a missing new line
2020-11-16 10:35:36 -05:00
Alvin Huang 978a80a377
Merge pull request #26756 from hashicorp/docker-mirror
switch to hashicorp docker mirror
2020-11-16 10:19:37 -05:00
TEDmk 8195a99529
Add a missing new line
The missing new line doesn't permit the code block to show up.
2020-11-16 16:08:55 +01:00
Martin Atkins b7f020bba1
Update CHANGELOG.md 2020-11-13 17:43:48 -08:00
Martin Atkins ca4b860902
Merge pull request #26766 from hashicorp/f-experimental-funcs
lang/funcs: Experimental "defaults" function
2020-11-13 17:41:06 -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
Martin Atkins c8843642c8 lang: allow functions to be subject to experiments
So far all of our language experiments have been new constructs handled
statically up in the configs package, but functions are another common
extention point where experiments could be useful to gather feedback and
so this intends to pass the information down into the right place to allow
for that to happen, even though as of this commit there are no
experimental functions to use it.
2020-11-13 17:25:16 -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
Pam Selle 5cab46de29
Merge pull request #26914 from hashicorp/update-go-getter
Update go-getter to v1.5.1 with support for vhost style S3 paths
2020-11-13 11:38:07 -05:00
Kent 'picat' Gruber 63cc597bc3
Fix grammar
Co-authored-by: Pam Selle <pam@hashicorp.com>
2020-11-13 11:28:13 -05:00
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
2020-11-13 11:15:06 -05:00
Kent 'picat' Gruber 1a30ef103c Update go-getter to v1.5.1 with support for vhost style S3 paths 2020-11-13 11:03:32 -05:00