Commit Graph

28397 Commits

Author SHA1 Message Date
James Bardin 2c4bd08fd9
Merge pull request #28553 from hashicorp/jbardin/un-code-cov
remove codedov
2021-04-29 13:18:54 -04:00
James Bardin 43af00262e remove codedov 2021-04-29 13:12:58 -04:00
James Bardin 479a091324
Merge pull request #28543 from hashicorp/jbardin/provider-diagnostics
Add more diagnostic configuration context to provider methods
2021-04-29 10:28:58 -04:00
James Bardin 7eade2cb52 add more diagnostics context
There were some remaining calls to provider where configuration could be
added to diagnostics, where warnings would not get config annotations,
or the diagnostics were skipped entirely.
2021-04-28 18:01:50 -04:00
Alisdair McDiarmid 4b1ff4eda7
Merge pull request #28523 from hashicorp/alisdair/json-plan-sensitive-provider-attrs
core: Add sensitive provider attrs to JSON plan
2021-04-28 15:49:47 -04:00
James Bardin 7f05d5d438
Merge pull request #28539 from hashicorp/jbardin/marked-data-plan
Unmark config values when planning a data source read
2021-04-28 14:19:25 -04:00
James Bardin 1db29d775e unmark planned data source values 2021-04-28 14:09:28 -04:00
James Bardin 0c8b4ce755 add context to UgpradeResourceState diags
This path was not yet using diagnostics, and returned simple errors.
2021-04-28 14:09:28 -04:00
Martin Atkins 89f986ded6 command+backend: generalized "plan mode"
So far we've only had "normal mode" and "destroy mode", where the latter
is activated either by "terraform plan -destroy" or "terraform destroy".

In preparation for introducing a third mode "refresh only" this
generalizes how we handle modes so we can potentially deal with an
arbitrary number of modes, although for now we only intend to have three.

Mostly this is just a different implementation of the same old behavior,
but there is one small user-visible difference here: the "terraform apply"
command now accepts a -destroy option, mirroring the option of the same
name on "terraform plan", which in turn makes "terraform destroy"
effectively a shorthand for "terraform apply -destroy".

This is intended to make us consistent that "terraform apply" without a
plan file argument accepts all of the same plan-customization options that
"terraform plan" does, which will in turn avoid us having to add a new
alias of "terraform plan" for each new plan mode we might add. The -help
output is changed in that vein here, although we'll wait for subsequent
commit to make a similar change to the website documentation just so we
can deal with the "refresh only mode" docs at the same time.
2021-04-27 08:23:54 -07:00
Martin Atkins c6a7d080d9 core: Generalize the idea of a "plan mode", vs just destroy flag
Previously there were only two planning modes: normal mode and destroy
mode. In that context it made sense for these to be distinguished only by
a boolean flag.

We're now getting ready to add our third mode, "refresh only". This
establishes the idea that planning can be done in one of a number of
mutually-exclusive "modes", which are related to but separate from the
various other options that serve as modifiers for the plan operation.

This commit only introduces the new plans.Mode type and replaces the
existing "destroy" flag with a variable of that type. This doesn't cause
any change in effective behavior because Terraform Core still supports
only NormalMode and DestroyMode, with NewContext rejecting an attempt to
create a RefreshMode context for now.

It is in retrospect a little odd that the "destroy" flag was part of
ContextOpts rather than just an argument to the Plan method, but
refactoring that would be too invasive a change for right now so we'll
leave this as a field of the context for now and save revisiting that for
another day.
2021-04-27 08:23:54 -07:00
Alisdair McDiarmid c89004d223 core: Add sensitive provider attrs to JSON plan
When rendering a stored plan file as JSON, we include a data structure
representing the sensitivity of the changed resource values. Prior to
this commit, this was a direct representation of the sensitivity marks
applied to values via mechanisms such as sensitive variables, sensitive
outputs, and the `sensitive` function.

This commit extends this to include sensitivity based on the provider
schema. This is in line with the UI rendering of the plan, which
considers these two different types of sensitivity to be equivalent.

Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
2021-04-27 10:29:34 -04:00
upodroid 5a60db0974 replace gomod 2021-04-26 14:34:11 +01:00
upodroid 958eb20559 remove json key content 2021-04-26 14:27:33 +01:00
upodroid b243dbd93d Merge branch 'main' of github.com:hashicorp/terraform into gcs-imp-v2 2021-04-26 14:20:28 +01:00
James Bardin 4997b9b5bb
Merge pull request #28424 from hashicorp/jbardin/dynamic
Better planing of unknown dynamic blocks
2021-04-23 18:26:21 -04:00
James Bardin 0830e8be70
Merge pull request #28504 from hashicorp/pgp-pubkey-0.15
update HC Public Key
2021-04-23 12:21:47 -04:00
James Bardin a4a6b40bee update getproviders tests for new key 2021-04-23 11:18:58 -04:00
James Bardin e1d790be61 update HC PublicKey 2021-04-23 11:18:58 -04:00
Kristin Laemmert 80f01e2cb7
Update CHANGELOG.md 2021-04-23 10:39:24 -04:00
Kristin Laemmert f6af7b4f7a
lang/funcs: add (console-only) TypeFunction (#28501)
* lang/funcs: add (console-only) TypeFunction

The type() function, which is only available for terraform console,
prints out the type of a given value. This is mainly intended for
debugging - it's nice to be able to print out terraform's understanding
of a complex variable.

This introduces a new field for Scope: ConsoleMode. When ConsoleMode is true, any additional functions intended for use in the console (only) may be added.
2021-04-23 10:29:50 -04:00
Chris Arcand 15b6a1614c
Merge pull request #28479 from hashicorp/motd-for-tfc
New login success output for TFC/E
2021-04-22 09:13:56 -05:00
Chris Arcand 58ec68063b Split off error MOTD error logging
The error logging in outputDefaultTFCLoginSuccess() is an unrelated side
effect.
2021-04-22 09:05:57 -05:00
Rachel Sharp 98ce186be9
Merge pull request #28443 from hashicorp/res-add-learn-link-debug-1
Add Learn link to Debugging
2021-04-21 22:59:19 -04:00
Chris Arcand 4b97411890 Add purple to the list of colorstring codes
This is the first color code introduced for 256 color terminals, and
should be a safe addition when considering the oldest supported
platform.
2021-04-21 21:35:45 -05:00
Chris Arcand 58cba1dea3 Add customized login success output for TFC/E
When logging in to Terraform Cloud or Terraform Enterprise, change the
success output to be a bit more customized for the platform. For
Terraform Cloud, fetch a dynamic welcome banner that intentionally fails
open and defaults to a hardcoded message if its not available for any
reason.
2021-04-21 21:23:42 -05:00
Kristin Laemmert 5ae4c2f92b lang/funcs: Defaults handling of marked arguments
Defaults will now preserve marks from non-null inputs and apply marks from any default values used. I've added tests for various structural types with marks, as well as some basic unknown cases.
2021-04-21 16:09:09 -04:00
Kristin Laemmert b34588ffca lang/funcs: TransposeFunc Tests
This commit adds test cases to TestTranspose to document how this function handles marks.

The short version is that any marks anywhere will be applied to the return value, be they marks on the input map or marks on elements (either the entire list of strings, or individual elemnets of those lists).
2021-04-21 16:09:09 -04:00
Alisdair McDiarmid 389415ab18
Merge pull request #28472 from hashicorp/alisdair/submodule-outputs-inferred-sensitive
core: Loosen output value sensitivity requirement
2021-04-21 14:40:52 -04:00
Alisdair McDiarmid 43bf3832d5 core: Loosen output value sensitivity requirement
Non-root module outputs no longer strip sensitivity marks from their
values, allowing dynamically sensitive values to propagate through the
configuration. We also remove the requirement for non-root module
outputs to be defined as sensitive if the value is marked as sensitive.

This avoids a static/dynamic clash when using shared modules that might
unknowingly receive sensitive values via input variables.

Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
2021-04-21 14:27:03 -04:00
Martin Atkins bfd4c964ee dependencies: update cty from v1.8.1 to v1.8.2
This includes the improvements to various collection-related functions to
make them handle marks more precisely. For Terraform in particular that
translates into handling sensitivity more precisely, so that non-sensitive
collections that happen to contain sensitive elements won't get simplified
into wholly-sensitive collections when using these functions.
2021-04-21 09:49:56 -07:00
Kristin Laemmert b649a8ddd1
deps: update go-plugin to v1.4.1 (#28465)
+ go mod tidy
2021-04-21 11:41:22 -04:00
James Bardin f8493bf5cd update hcl
update to v2.10.0
2021-04-20 17:04:56 -04:00
James Bardin d15f7394a1
Merge pull request #28457 from hashicorp/jbardin/provisioner-null-checks
additional null checks in provisioners
2021-04-20 16:25:34 -04:00
James Bardin 7f571b5ebb additional null checks in provisioners
Now that provisioners for directly with the plugin API and cty data
types, we need to add a few null checks to catch invalid input that
would have otherwise been masked by the legacy SDK.
2021-04-20 12:31:32 -04:00
John Houston fabdf0bea1
Add config_paths and drop KUBECONFIG env variable in kubernetes backend (#26997) 2021-04-20 10:05:45 -04:00
Martin Atkins 14336ae6f8 lang/funcs: Conversion functions can handle sensitive values
In order to avoid updating every one of our existing functions with
explicit support for sensitive values, there's a default rule in the
functions system which makes the result of a function sensitive if any
of its arguments contain sensitive values.

We were applying that default to the various type conversion functions,
like tomap and tolist, which meant that converting a complex-typed value
with a sensitive value anywhere inside it would result in a
wholly-sensitive result.

That's unnecessarily conservative because the cty conversion layer (which
these functions are wrapping) already knows how to handle sensitivity
in a more precise way. Therefore we can opt in to handling marked values
(which Terraform uses for sensitivity) here and the only special thing
we need to do is handle errors related to sensitive values differently,
so we won't print their values out literally in case of an error (and so
that the attempt to print them out literally won't panic trying to
extract the marked values).
2021-04-19 12:10:50 -07:00
Martin Atkins 8f233cde4c cli: Diagnostics can include collections with sensitive elements
We previously had a shallow IsMarked call in compactValueStr's caller but
then a more-conservative deep ContainsMarked call inside compactValueStr
with a different resulting message. As well as causing an inconsistency
in messages, this was also a bit confusing because it made it seem like
a non-sensitive collection containing a sensitive element value was wholly
sensitive, making the debug information in the diagnostic messages not
trustworthy for debugging certain varieties of problem.

I originally considered just removing the redundant check in
compactValueStr here, but ultimately I decided to keep it as a sort of
defense in depth in case a future refactoring disconnects these two
checks. This should also serve as a prompt to someone making later changes
to compactValueStr to think about the implications of sensitive values
in there, which otherwise wouldn't be mentioned at all.

Disclosing information about a collection containing sensitive values is
safe here because compactValueStr only discloses information about the
value's type and element keys, and neither of those can be sensitive in
isolation. (Constructing a map with sensitive keys reduces to a sensitive
overall map.)
2021-04-19 11:58:49 -07:00
sanflores 751fba49a7
website: v0.15 upgrade guide had invalid example for tomap(...)
tomap expects an object value with braces, not a tuple value with brackets.
2021-04-19 10:20:03 -07:00
James Bardin a0f221d04b
Merge pull request #28444 from hashicorp/jbardin/destroy-plan-provider
wrong operation during destroy plan walk
2021-04-19 13:15:42 -04:00
James Bardin 877348c031 wrong operation during destroy plan walk
The destroy plan walk was identifying itself as a normal plan, and
causing providers to be configured when they were not needed. Since the
provider configuration may not be complete during the minimal destroy
plan walk, validation or configuration may fail.
2021-04-19 12:35:10 -04:00
Rachel Sharp 56483d10d2
Update debugging.html.md 2021-04-19 12:18:02 -04:00
Kristin Laemmert 85adad0ec7
docs: small update for provider binary locations (#28413)
* docs: add note that provider binaries need to be placed in appropriate subdirectories under the default locations
2021-04-19 09:04:46 -04:00
James Bardin 6839170274
Merge pull request #28414 from hashicorp/jbardin/config-provider-fqns
resolve provider types when building the config
2021-04-16 13:20:57 -04:00
Alisdair McDiarmid 7b2c7dddf3
Merge pull request #28412 from hashicorp/alisdair/fix-missing-apply-output-for-remote-operations
cli: Fix missing apply summary for remote runs
2021-04-16 12:51:07 -04:00
James Bardin d0cc7f1d5e resolve provider types when building the config
All the information is available to resolve provider types when building
the configuration, but some provider references still had no FQN. This
caused validation to assume a default type, and incorrectly reject valid
module calls with non-default namespaced providers.

Resolve as much provider type information as possible when loading the
config. Only use this internally for now, but this should be useful
outside of the package to avoid re-resolving the providers later on. We
can come back and find where this might be useful elsewhere, but for now
keep the change as small as possible to avoid any changes in behavior.
2021-04-16 12:37:50 -04:00
Alisdair McDiarmid 8dcf768f4e backend/remote: Add IsLocalOperations
To ensure that the apply command can determine whether an operation is
executed locally or remotely, we add an IsLocalOperations method on the
remote backend. This returns the internal forceLocal boolean.

We also update this flag after checking if the corresponding remote
workspace is in local operations mode or not. This ensures that we know
if an operation is running locally (entirely on the practitioner's
machine), pseudo-locally (on a Terraform Cloud worker), or remotely
(executing on a worker, rendering locally).
2021-04-16 11:43:57 -04:00
upodroid 39bfa6fa5f fmtcheck 2021-04-16 16:15:15 +01:00
upodroid 1280b86d92 tweak go.mod replaces 2021-04-16 16:12:04 +01:00
Alisdair McDiarmid 69e7922a33 cli: Fix missing apply summary for remote runs
Disabling the resource count and outputs rendering when the remote
backend is in use causes them to be omitted from Terraform Cloud runs.
This commit changes the condition to render these values if either the
remote backend is not in use, or the command is running in automation
via the TF_IN_AUTOMATION flag. As this is intended to be set by
Terraform Cloud and other remote backend implementations, this addresses
the problem.
2021-04-16 10:03:22 -04:00
Alisdair McDiarmid 23800438ab
Merge pull request #28409 from hashicorp/alisdair/fix-remote-backend-ui-issues
cli: Fix remote backend UI issues
2021-04-16 09:03:34 -04:00