28128 Commits (c6a7d080d9e8b3cf04e32b8af758402185d293eb)

 

All Branches   

Search

Author	SHA1	Message	Date
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.	5 years ago
James Bardin	4997b9b5bb	Merge pull request #28424 from hashicorp/jbardin/dynamic ... Better planing of unknown dynamic blocks	5 years ago
James Bardin	0830e8be70	Merge pull request #28504 from hashicorp/pgp-pubkey-0.15 ... update HC Public Key	5 years ago
James Bardin	a4a6b40bee	update getproviders tests for new key	5 years ago
James Bardin	e1d790be61	update HC PublicKey	5 years ago
Kristin Laemmert	80f01e2cb7	Update CHANGELOG.md	5 years ago
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.	5 years ago
Chris Arcand	15b6a1614c	Merge pull request #28479 from hashicorp/motd-for-tfc ... New login success output for TFC/E	5 years ago
Chris Arcand	58ec68063b	Split off error MOTD error logging ... The error logging in outputDefaultTFCLoginSuccess() is an unrelated side effect.	5 years ago
Rachel Sharp	98ce186be9	Merge pull request #28443 from hashicorp/res-add-learn-link-debug-1 ... Add Learn link to Debugging	5 years ago
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.	5 years ago
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.	5 years ago
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.	5 years ago
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).	5 years ago
Alisdair McDiarmid	389415ab18	Merge pull request #28472 from hashicorp/alisdair/submodule-outputs-inferred-sensitive ... core: Loosen output value sensitivity requirement	5 years ago
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>	5 years ago
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.	5 years ago
Kristin Laemmert	b649a8ddd1	deps: update go-plugin to v1.4.1 (#28465) ... + go mod tidy	5 years ago
James Bardin	f8493bf5cd	update hcl ... update to v2.10.0	5 years ago
James Bardin	d15f7394a1	Merge pull request #28457 from hashicorp/jbardin/provisioner-null-checks ... additional null checks in provisioners	5 years ago
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.	5 years ago
John Houston	fabdf0bea1	Add config_paths and drop KUBECONFIG env variable in kubernetes backend (#26997)	5 years ago
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).	5 years ago
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.)	5 years ago
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.	5 years ago
James Bardin	a0f221d04b	Merge pull request #28444 from hashicorp/jbardin/destroy-plan-provider ... wrong operation during destroy plan walk	5 years ago
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.	5 years ago
Rachel Sharp	56483d10d2	Update debugging.html.md	5 years ago
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	5 years ago
James Bardin	6839170274	Merge pull request #28414 from hashicorp/jbardin/config-provider-fqns ... resolve provider types when building the config	5 years ago
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	5 years ago
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.	5 years ago
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).	5 years ago
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.	5 years ago
Alisdair McDiarmid	23800438ab	Merge pull request #28409 from hashicorp/alisdair/fix-remote-backend-ui-issues ... cli: Fix remote backend UI issues	5 years ago
Alisdair McDiarmid	fad305f884	cli: Fix remote backend UI issues ... Fix two bugs which surface when using the remote backend: - When migrating to views, we removed the call to `(*Meta).process` which initialized the color boolean. This resulted in the legacy UI calls in the remote backend stripping color codes. To fix this, we populate this boolean from the common arguments. - Remote apply will output the resource summary and output changes, and these are rendered via the remote backend streaming. We need to special case this in the apply command and prevent displaying a zero-change summary line. Neither of these are coverable by automated tests, as we don't have any command-package level testing for the remote backend. Manually verified.	5 years ago
James Bardin	d351d712c4	dynamic block MinItems MaxItems validation test	5 years ago
James Bardin	3e49c4b388	MinItems and MaxItems can be validated once again ... The new hcldec dynamic block behavior no longer tried to validate MinItems and MaxItems when the number of values is unknown.	5 years ago
Martin Atkins	dedac2cdd6	website: v0.15 Upgrade Guide entry for Azure Backend arguments ... Terraform v0.15 includes the conclusion of the deprecation cycle for some renamed arguments in the "azure" backend. We missed this on the first draft of the upgrade guide because this change arrived along with various other more innocuous updates and so we didn't spot it during our change review.	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
Alisdair McDiarmid	ec001d3e18	Merge pull request #28381 from hashicorp/alisdair/fix-double-mark-sensitive-attrs ... core: Fix double-marked sensitive attributes	5 years ago
Alisdair McDiarmid	2390a11d60	core: Fix double-marked sensitive attributes ... We need to unmark the decoded state and merge the marks with those from the resource schema. Co-authored-by: James Bardin <j.bardin@gmail.com>	5 years ago
James Bardin	2cd1619c40	Merge pull request #28329 from serejkus/dag/set-tiny-optimisations ... tiny optimisations of dag.Set	5 years ago
James Bardin	59c8281378	use new dynamic decoding behavior ... Dynamic blocks with unknown for_each expressions are now decoded into an unknown value rather than using a sentinel object with unknown and null attributes. This will allow providers to precisely plan the block values, rather than trying to heuristically paper over the incorrect plans when dynamic is in use.	5 years ago
Alisdair McDiarmid	2c8c387540	Merge pull request #28363 from hashicorp/alisdair/here-is-a-newline ... command: Add a newline before confirming apply	5 years ago
Alisdair McDiarmid	e4031eaccf	command: Add a newline before confirming apply ... This blank line delineating the plan and the query was accidentally dropped as part of the views migration.	5 years ago
Martin Atkins	5f5432e8ea	website: v0.15 upgrade guide for sensitive resource attributes (#28355) ... * website: v0.15 upgrade guide for sensitive resource attributes Our earlier draft of this guide didn't include a section about the stabilization of the "provider_sensitive_attrs" language experiment. This new section aims to address the situation where a module might previously have been returning a sensitive value without having marked it as such, and thus that module will begin returning an error after upgrading to Terraform v0.15. As part of that, I also reviewed the existing documentation about these features and made some edits aiming to make these four different sections work well together if users refer to them all at once, as they are likely to do if they follow the new links from the upgrade guide. I aimed to retain all of the content we had before, but some of it is now in a new location. In particular, I moved the discussion about the v0.14 language experiment into the upgrade guide, because it seems like a topic only really relevant to those upgrading from an earlier version and not something folks need to know about if they are using Terraform for the first time in v0.15 or later. * minor fixups Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>	5 years ago
James Bardin	b515ab583a	make blocktoattr an hcldec.UnknownBody ... This will allow any dynamic blocks that are fixed up as a blocktoattr still decode into an unknown value.	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
Alisdair McDiarmid	33e5d111fe	Merge pull request #28326 from hashicorp/alisdair/allow-nonsensitive-on-non-sensitive-values ... lang/funcs: Make nonsensitive more permissive	5 years ago