28155 Commits (3679de0630ffbe67fa8d2ff299891dfdcb01cd6a)

 

All Branches   

Search

Author	SHA1	Message	Date
Kristin Laemmert	3679de0630	command/format: fix repetitive "unchanged attribute hidden" message (#28589) ... writeNestedAttrDiff and writeAttrDiff were both printing the "unchanged attribute" message. This removes one of the redundant prints. Fixing this led me (in a very roundabout way) to realize that NestedType attributes were printing a sum total of unchanged attributes, including those in entirely unchanged elements, while *not* printing the total of unchanged elements. I added the necessary logic to count and print the number of unchanged elements for maps and lists.	5 years ago
Chris Arcand	5813620412	Merge pull request #28594 from hashicorp/go-tfe-update ... Update go-tfe client to v0.14.0	5 years ago
Chris Arcand	2756f5ed08	Update Terraform Cloud/Enterprise client to v0.14.0	5 years ago
Martin Atkins	c63c06d3c4	core: -replace to emit only one warning for incomplete address ... If the user gives an index-less address for a resource that expects instance keys then previously we would've emitted one error per declared instance of the resource, which is overwhelming and not especially helpful. Instead, we'll deal with that check prior to expanding resources into resource instances, and thus we can report a single error which talks about all of the instances at once. This does unfortunately come at the expense of splitting the logic for dealing with the "force replace" addresses into two places, which will likely make later maintenance harder. In an attempt to mitigate that, I've included a comment in each place that mentions the other place, which hopefully future maintainers will keep up-to-date if that situation changes.	5 years ago
Martin Atkins	1d3e34e35e	command: New -replace=... planning option ... This allows a similar effect to pre-tainting an object but does the action within the context of a normal plan and apply, avoiding the need for an intermediate state where the old object still exists but is marked as tainted. The core functionality for this was already present, so this commit is just the UI-level changes to make that option available for use and to explain how it contributed to the resulting plan in Terraform's output.	5 years ago
Alisdair McDiarmid	7f39f19ec7	Merge pull request #28584 from hashicorp/alisdair/add-reason-to-json-planned-change ... command/views: Add reason to JSON planned change	5 years ago
Alisdair McDiarmid	48b9055e42	Merge pull request #28583 from hashicorp/alisdair/sensitive-attribute-forces-replacement ... cli: Show forces replacement for sensitive attrs	5 years ago
Alisdair McDiarmid	7b23fa7877	command/views: Add reason to JSON planned change ... Now that we have extra information about the reason for a given resource action, include that in the JSON log output for planned changes.	5 years ago
Alisdair McDiarmid	c95e9ada6b	cli: Show forces replacement for sensitive attrs ... When rendering a plan diff, sensitive resource attributes would previously omit the "forces replacement" comment, which can lead to confusion when the only reason for a resource being replaced is a sensitive attribute.	5 years ago
Martin Atkins	6bed3008a5	website: Reworking of the "terraform plan" docs, and related pages ... It's been a long time since we gave this page an overhaul, and with our ongoing efforts to make plan and apply incorporate all of the side-effects that might need to be done against a configuration it seems like a good time for some restructuring in that vein. The starting idea here is to formally split the many "terraform plan" options into a few different categories: - Planning modes - Planning options - Other options The planning modes and options are the subset that are also accepted by "terraform apply" when it's running in its default mode of generating a plan and then prompting for interactive approval of it. This then allows us to avoid duplicating all of that information on the "terraform apply" page, and thus allows us to spend more words discussing each of them. This set of docs is intended as a fresh start into which we'll be able to more surgically add in the information about -refresh-only and -replace=... once we have those implemented. Consequently there are some parts of this which may seem a little overwraught for what it's currently describing; that's a result of my having prepared this by just deleting the -refresh-only and -replace=... content from our initial docs draft and submitted the result, in anticipation of re-adding the parts I've deleted here in the very near future in other commits.	5 years ago
Alisdair McDiarmid	95b86bf7ad	Merge pull request #28566 from hashicorp/alisdair/json-logs-operations-commands ... cli: Add JSON logs for operations commands	5 years ago
Martin Atkins	06adc69e2c	plans: Plan.Mode is now Plan.UIMode ... This is to make it more obvious at all uses of this field that it's not something to be used for anything other than UI decisions, hopefully prompting a reader of code elsewhere to refer to the comments to understand why it has this unusual prefix and thus see what its intended purpose is.	5 years ago
Martin Atkins	b37b1beddd	core: Minimal initial implementation of -replace=... option ... This only includes the internal mechanisms to make it work, and not any of the necessary UI changes to "terraform plan" and "terraform apply" to activate it yet. The force-replace options are ultimately handled inside the NodeAbstractResourceInstance.plan method, at the same place we handle the similar situation of the provider indicating that replacement is needed, and so the rest of the changes here are just to propagate the settings through all of the layers in order to reach that point.	5 years ago
Martin Atkins	1b464e1e9a	core: Minimal initial implementation of "refresh only" planning mode ... This only includes the core mechanisms to make it work. There's not yet any way to turn this mode on as an end-user, because we have to do some more work at the UI layer to present this well before we could include it as an end-user-visible feature in a release. At the lowest level of abstraction inside the graph nodes themselves, this effectively mirrors the existing option to disable refreshing with a new option to disable change-planning, so that either "half" of the process can be disabled. As far as the nodes are concerned it would be possible in principle to disable _both_, but the higher-level representation of these modes prevents that combination from reaching Terraform Core in practice, because we block using -refresh-only and -refresh=false at the same time.	5 years ago
Sam Velie	5d04c4ea27	docs: correct spelling of normally (#28508)	5 years ago
Alisdair McDiarmid	f72730a02b	cli: Add JSON logs for operations commands	5 years ago
Martin Atkins	b802237e03	plans: Track an optional extra "reason" for some planned actions ... Previously we were repeating some logic in the UI layer in order to recover relevant additional context about a change to report to a user. In order to help keep things consistent, and to have a clearer path for adding more such things in the future, here we capture this user-facing idea of an "action reason" within the plan model, and then use that directly in order to decide how to describe the change to the user. For the moment the "tainted" situation is the only one that gets a special message, matching what we had before, but we can expand on this in future in order to give better feedback about the other replace situations too. This also preemptively includes the "replacing by request" reason, which is currently not reachable but will be used in the near future as part of implementing the -replace=... plan command line option to allow forcing a particular object to be replaced. So far we don't have any special reasons for anything other than replacing, which makes sense because replacing is the only one that is in a sense a special case of another action (Update), but this could expand to other kinds of reasons in the future, such as explaining which of the few different reasons a data source read might be deferred until the apply step.	5 years ago
James Bardin	2c4bd08fd9	Merge pull request #28553 from hashicorp/jbardin/un-code-cov ... remove codedov	5 years ago
James Bardin	43af00262e	remove codedov	5 years ago
James Bardin	479a091324	Merge pull request #28543 from hashicorp/jbardin/provider-diagnostics ... Add more diagnostic configuration context to provider methods	5 years ago
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.	5 years ago
Alisdair McDiarmid	4b1ff4eda7	Merge pull request #28523 from hashicorp/alisdair/json-plan-sensitive-provider-attrs ... core: Add sensitive provider attrs to JSON plan	5 years ago
James Bardin	7f05d5d438	Merge pull request #28539 from hashicorp/jbardin/marked-data-plan ... Unmark config values when planning a data source read	5 years ago
James Bardin	1db29d775e	unmark planned data source values	5 years ago
James Bardin	0c8b4ce755	add context to UgpradeResourceState diags ... This path was not yet using diagnostics, and returned simple errors.	5 years ago
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.	5 years ago
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
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>	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