624 Commits (148b19b0d7e36b6f2b8a169d2cb7b6069ab5d00a)

Author	SHA1	Message	Date
Liam Cervante	b718c55b13	deferred actions: include deferred resources within JSON plan output (#35065) ... * deferred actions: include deferred resources within JSON plan output * address comments	2 years ago
Liam Cervante	14418bd198	terraform test: move override evaluation into expander (#35030) ... * terraform test: move override evaluation into expander * clarify comment	2 years ago
Nick Fagerlund	40b6f21b3d	Merge pull request #35050 from hashicorp/rebrand-hcp-terraform ... Rebrand Terraform Cloud to HCP Terraform	2 years ago
Sebastian Rivera	c04d32dc26	Inject appname to backend migration prompts	2 years ago
Sebastian Rivera	015f795ff0	Rebrand Terraform Cloud to HCP Terraform	2 years ago
Liam Cervante	448775102c	terraform test: Push evaluation of variables to as late as possible (#35014) ... * terraform test: Push evaluation of variables to as late as possible * Update internal/moduletest/hcl/variable_cache.go Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * address comments --------- Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>	2 years ago
Liam Cervante	6963c54bec	terraform test: don't remove sensitive marks from inputs (#35021)	2 years ago
Martin Atkins	30e2fd6525	Handle marks a little more consistently ... In the very first implementation of "sensitive values" we were unfortunately not disciplined about separating the idea of "marked value" from the idea of "sensitive value" (where the latter is a subset of the former). The first implementation just assumed that any marking whatsoever meant "sensitive". We later improved that by adding the marks package and the marks.Sensitive value to standardize on the representation of "sensitive value" as being a value marked with _that specific mark_. However, we did not perform a thorough review of all of the mark-handling codepaths to make sure they all agreed on that definition. In particular, the state and plan models were both designed as if they supported arbitrary marks but then in practice marks other than marks.Sensitive would be handled in various inconsistent ways: dropped entirely, or interpreted as if marks.Sensitive, and possibly do so inconsistently when a value is used only in memory vs. round-tripped through a wire/file format. The goal of this commit is to resolve those oddities so that there are now two possible situations: - General mark handling: some codepaths genuinely handle marks generically, by transporting them from input value to output value in a way consistent with how cty itself deals with marks. This is the ideal case because it means we can add new marks in future and assume these codepaths will handle them correctly without any further modifications. - Sensitive-only mark preservation: the codepaths that interact with our wire protocols and file formats typically have only specialized support for sensitive values in particular, and lack support for any other marks. Those codepaths are now subject to a new rule where they must return an error if asked to deal with any other mark, so that if we introduce new marks in future we'll be forced either to define how we'll avoid those markings reaching the file/wire formats or extend the file/wire formats to support the new marks. Some new helper functions in package marks are intended to standardize how we deal with the "sensitive values only" situations, in the hope that this will make it easier to keep things consistent as the codebase evolves in future. In practice the modules runtime only ever uses marks.Sensitive as a mark today, so all of these checks are effectively covering "should never happen" cases. The only other mark Terraform uses is an implementation detail of "terraform console" and does not interact with any of the codepaths that only support sensitive values in particular.	2 years ago
Martin Atkins	5a944133e6	command/jsonstate: Reject unsupported marks ... Our JSON state format has support for sensitive marks in particular but lacks generalized support and so cannot deal with any other marks. Previously it just assumed that any mark must be the sensitive mark, but now we'll reject other marks to ensure that if any new marks are added we must consider whether and how the JSON state format should handle them.	2 years ago
UKEME BASSEY	a4415c030a	making json data more useful for client consumption	2 years ago
UKEME BASSEY	7fb13b8868	fixing tests	2 years ago
UKEME BASSEY	c7bbc09631	move all command args from command/init to args/init	2 years ago
UKEME BASSEY	ce7824f905	add interrupt error to the diags so each component becomes responsible for rendering the errors	2 years ago
UKEME BASSEY	0ea25e3b40	fixing tests internal/command/init, view and argumento	2 years ago
UKEME BASSEY	ba8386b8a2	json does not support interactive prompt so dont allow setting of both -migrate-state and -json options	2 years ago
UKEME BASSEY	ea8d0869d8	convert all logs to be view type exclusive for human or json format	2 years ago
UKEME BASSEY	370a471ecb	fix json -help display and failing tests	2 years ago
UKEME BASSEY	26f01d699a	add test for -json support	2 years ago
UKEME BASSEY	a3f3b64e4c	add -json to tf init	2 years ago
UKEME BASSEY	7709db45dc	add init view test	2 years ago
UKEME BASSEY	14c53f74f2	add init view for json and human type view	2 years ago
Liam Cervante	924958bce0	plan renderer: ensure JSON strings are completely JSON (#34959)	2 years ago
Martin Atkins	c1342f4f6a	terraform test: Include test case execution time in JUnit XML ... Our currently-experimental JUnit XML output didn't previously include the "time" attribute for test runs at all, but from testing with common JUnit XML consumers we've learned that populating this is effectively mandatory because otherwise software just assumes that it's zero, producing a misleading result. We'll now populate it based on the test runner's measure of the execution time, assuming that the test runner actually measured it. If not, we'll leave it omitted and thus get the same behavior as before, which in practice means that most software will treat it as zero anyway. Because JUnit XML output is still experimental with the goal of getting feedback on exactly how we map the Terraform testing model onto that Java-oriented format, this is intentionally not supported for remote test runs in Terraform Cloud yet. It isn't really practical for Terraform Cloud to participate in short-lived Terraform CLI experiments, because Terraform Cloud has a different release schedule than Terraform CLI does. However, if this experiment is successful then we will eventually need to find a way to plumb this additional information through the JSON logs and ensure that it arrives in the locally-generated JUnit XML output.	2 years ago
Martin Atkins	c8611b51d7	terraform test: JUnit XML output sets testcase classname ... JUnit XML output from "terraform test" is currently experimental, because we're still trying to decide how best to map Terraform's testing concepts onto the Java-oriented JUnit XML format. The first round of feedback showed that some JUnit consumers completely ignore test suite names, and instead expect each test case to specify which "class" it belongs to. Those tools then might allow grouping or filtering the tests by "class". Despite the Java-oriented terminology, it seems that "classname" is really just interpreted something like "test group name", where the classname and the name together represent the full test case identifier. With that in mind then, we'll now duplicate the test suite name (which in our case is the filename of the test scenario file) into the classname attribute of each testcase element. For now we'll retain the per-suite names, always containing the same value, because we also have evidence of some consumers preferring to find this information in that location.	2 years ago
Martin Atkins	14b08c3745	terraform: Move variable validation into its separate node type ... The parent commit added a new node to the graph for each existing input variable node, but that node didn't do anything yet. Now those new nodes are actually responsible for checking the variable's validation rules, instead of that being included in the same graph node that decides the variable's final value. This also refines the validation node graph transformer to only insert a validation node if there's at least one rule to check, which should avoid bloating the graph for anyone who isn't actually using input variable validation. Therefore the plan graph builder tests revert back to their old expected result because that input configuration does not include any validation rules. For the moment this just moves around functionality that already existed and doesn't add anything new, but having the validation handled in a separate graph node means that we can evaluate the validation rules in the EvalContext of the module where the variable was declared instead of where it was defined, and so a future commit will allow -- initially just as an experiment -- validation rules that can refer to other objects in the module where the variable is declared, including the values of other input variables. As a nice bonus, this fixed a small bug in "terraform test" where problems with variable values defined in the test run were reported as problems with the variable declaration, rather than with the expression assigning the value to it. Since it's now NodeRootVariable that decides the definition source range, rather than the validation-rule-checking helper, it has access to the source range provided in a terraform.InputValue object, which was already populated correctly for per-test-run definitions.	2 years ago
Nick Fagerlund	dc9a13a975	Catch a missing err check in apply command ... Plan and refresh already had this, but apply would deref a nil opReq and panic.	2 years ago
Nick Fagerlund	1781c8e8e9	Experimental `-allow-deferral` flag for enabling deferred actions on CLI ... Now that deferred actions is a top-level per-plan option, here's a lil command-line option for turning it on! - It's called `-allow-deferral`. - It is ONLY legal to use if this is an experimental build, i.e. compiled with `go build -ldflags "-w -s -X 'main.experimentsAllowed=yes'"` or the like. Implementation notes: The design constraint here was, "please avoid having to change the build infrastructure or alter the function of every args parsing function". So, since `extendedFlagSet()` doesn't have access to the var that says we're in an experimental build, I had to move the validation for that particular flag to later in the process, when we're building the operation request.	2 years ago
Craig Sloggett	f20b055618	Prevent duplicate error messages for unset environment variables ... Track and report each unset environment variable only once, even if it's referenced multiple times in the Terraform configuration.	2 years ago
Craig Sloggett	b53db4ef14	Ensure environment variables are set when interpolating rawPath	2 years ago
Craig Sloggett	302c6deddc	Interpolate environment variables when configuring dev_overrides	2 years ago
Martin Atkins	58b48f4bab	provider/terraform: Use new convention for function names ... When we added these functions we hadn't yet settled on a single convention for how provider-contributed functions ought to be named, and so these followed the convention previously used for Terraform's own built-in functions. We've now decided to use the new provider namespace as an opportunity to partially fix the historical design error of naming functions as all lowercase without any separation between words. This makes the provider functions inconsistent with the built-in functions, but should at least hopefully encourage the provider functions to be consistent with one another, so that the rule for which to use is relatively easy to remember. This also switches the word order because the provider functions convention prefers the verb to come first: encode_tfvars instead of tfvarsencode.	2 years ago
Martin Atkins	dbde17b535	terraform console: Multi-line entry support ... The console command, when running in interactive mode, will now detect if the input seems to be an incomplete (but valid enough so far) expression, and if so will produce another prompt to accept another line of expression input. This is primarily to make it easier to paste in multi-line expressions taken from elsewhere, but it could also be used for manual input. The support for multi-line _editing_ is limited by the fact that the readline dependency we use doesn't support multiline input and so we're currently doing this in spite of that library. Hopefully we'll be able to improve on that in future either by contributing multi-line editing support upstream or by switching to a different readline dependency. The delimiter-counting heuristic employed here is similar to the one used by HCL itself to decide whether a newline should end the definition of an attribute, but this implementation is simpler because it doesn't need to produce error messages or perform any recovery. Instead, it just bails out if it encounters something strange so that the console session can return a parse error. Because some invalid input may cause a user to become "stuck" in a multi- line sequence, we consider a blank line as intent to immediately try to evaluate what was entered, and also interpret SIGINT (e.g. Ctrl+C) as cancellation of multi-line input, assuming that at least one line was already entered, extending the previous precedent that SIGINT cancels when at least one character was already entered at the prompt.	2 years ago
Liam Cervante	c6ff573180	Include provider functions in scope used to evaluate test assertions (#34825)	2 years ago
Martin Atkins	88cb4aeea3	backendrun: Separate the types/etc for backends that support operations ... We previously had all of the types and helpers for all kinds of backends together in package backend. That kept things relatively simple, but it also meant that the majority of backends that only deal with remote state storage ended up still indirectly depending on the entire Terraform modules runtime, configuration loader, etc, etc, which brings into scope a bunch of external dependencies that the remote state backends don't really need. Since backends that support operations are a rare exception, we'll move the types and helpers for those into a separate package "backendrun", and then the main package backend can have a much more modest set of types and, more importantly, a modest set of dependencies on other packages in this codebase. This is part of an ongoing effort to reduce the exposure of Terraform Core and CLI code to the remote backends and vice-versa, so that in the long run we can more often treat them as separate for dependency maintenance purposes.	2 years ago
Martin Atkins	545980d664	langrefs: Separate package for expression reference analysis ... Finding references in an expression is a static analysis operation, but we previously had it grouped in with "package lang" that primarily deals with dynamic evaluation of expressions. We need to do static analysis in far more locations than we do full expression evaluation, the static-analysis-only callers don't need anything else from package lang, and the reference-analysis functions are self-contained little wrappers around the address parsing logic in package addrs anyway. Splitting these into a separate package therefore minimizes which packages depend indirectly on package lang, and thus which packages depend indirectly on the implementations of the built-in functions. Some of the built-in functions rely on dependencies we don't use anywhere else, so cutting these out shrinks how many packages indirectly depend on those external dependencies. In particular, they are no longer in the indirect import chain for the "legacy" module.	2 years ago
Martin Atkins	5f2eab6944	providerreqs: Provider requirement/version types in their own package ... As we previously found with "package addrs", any package that contains types used as identifiers or addresses tends to get imported from all over, which means that if we mix real logic with those types in the same package then a lot more packages end up depending indirectly on our external dependencies. In this case, the getproviders package depends on various things we need only during provider installation, such as the library we use for GPG signature verification. Lots of different packages in Terraform need to talk about provider requirements, but only the CLI layer actually needs to do provider installation, and so this commit splits the types we use to talk about requirements into a new package "providerreqs", which package getproviders then depends on. To keep the size of this diff relatively small to start I've left forwarding aliases in package getproviders, which means that not all of the callers needed to be updated all at once. This commit does update all of the packages that the remote state backends depend on though, because that then allows us to reduce the set of indirect dependencies for each of those backends. The nested module go.mod files show that this has disconnected the indirect dependencies on github.com/ProtonMail/go-crypto and on github.com/cloudflare/circl , both of which Terraform CLI uses only for provider installation.	2 years ago
Martin Atkins	66bec6c3c7	command: TestWorkspace_deleteWithState uses modern state format ... This test is intending to test behavior in the presence of a state snapshot but was achieving that using the legacy state snapshot format that we preserved only for its previous (now eliminated, in an earlier commit) purpose of implementing the CLI backend state format. Instead, we'll construct a state snapshot format using the modern API for doing that, which therefore constructs a modern state snapshot file as would be created by today's Terraform. This eliminates the last use of the "legacy/terraform" package aside from the calls from other packages under "legacy".	2 years ago
Martin Atkins	06f51dbe04	command/workdir: Model the "backend state" file format ... Historically (before there were "backends") Terraform had a single state file format used both for real state snapshots and for tracking where remote state was stored. Terraform v0.12 caused these two to be split because we adopted state snapshot version 4 for real snapshots but retained a subset of version 3 for tracking the remote backend configuration in the local working directory. Unfortunately we previously kept that working by retaining a snapshot of the entire Terraform v0.11 "terraform" package as legacy/terraform, which happened to still be around because we also needed to retain a copy of the entire legacy SDK to keep the remote state backends working. This now hoists just the tiny slice of legacy terraform package functionality needed to implement the "backend state" file format into package workdir. This package is a good home for it because it's part of the working directory state. Ideally it would be accessed through methods of the workdir.Dir type, but that's too disruptive a refactor to combine into this and so that'll need to wait for another day; for now we'll keep the existing callers doing their access through our "clistate" package that is itself a forked snapshot of what statemgr.Filesystem used to be in Terraform v0.11. This removes all but one of the uses of "legacy/terraform" aside from calls in the other packages under "legacy". We'll clean up the last one in a later commit, because it's not related to the backend state file format.	2 years ago
Martin Atkins	1358245617	dependencies: Remove all non-legacy uses of hashicorp/go-multierror ... This functionality is now provided by the "errors" package in the standard library, so the HashiCorp-specific library is obsolete. This also removed our one direct use of github.com/pkg/errors, which we were using in a way that was totally redundant with the stdlib package errors. However, it lives on as an indirect dependency through the Consul backend's dependency on the Consul SDK, which uses that library.	2 years ago
thirdkeyword	8284cde302	remove repetitive words ... Signed-off-by: thirdkeyword <fliterdashen@gmail.com>	2 years ago
Mark DeCrane	57d2802053	Merge pull request #34746 from hashicorp/modify-dev-override-warn-with-backend ... Modify provider dev override warning to include a remote backend specific line	2 years ago
Mark DeCrane	b83275f05d	chore: remove extra newline char	2 years ago
Mark DeCrane	51ae7d32a7	fix: check for local operations, separate warning for remote execution	2 years ago
Mark DeCrane	9580ee27f9	chore: add remote backend specfic warnings to dev override warning	2 years ago
Nick Fagerlund	c9c24706aa	Merge pull request #34741 from hashicorp/nf/feb24-provider-addrs-in-statuses ... Stacks, Hooks: Include full provider addresses	2 years ago
James Bardin	dada9d683e	Merge pull request #34740 from hashicorp/jbardin/render-string-null-changes ... try to render some changes between `""` and `null`	2 years ago
Nick Fagerlund	ccab5f1e55	Rename some UiHook tests for easier ad-hoc runs	2 years ago
Nick Fagerlund	94ea534e40	Refactor terraform.Hook to use a resource-identifying wrapper struct ... The terraform.Hook interface lets other areas of code perform streaming reactions to various events, generally in the service of some UI somewhere. Nearly all of the methods on this interface take an `addrs.AbsResourceInstance` as their first argument, to identify the resource that's being operated on. However, that addrs struct doesn't necessarily contain everything you might want in order to uniquely and usefully identify a resource. It has the module instance and resource instance addresses, but it lacks the provider source address, which can affect how the consuming UI should display the resource's events. (For example, Terraform Cloud wants reliable info about who maintains a given provider, what cloud provider it operates on, and where to find its documentation.) Instead of polluting `addrs.AbsResourceInstance` with extra information that isn't relevant to other call sites, let's change the first argument of each Hook method to be a wrapper struct defined in the package that owns the Hook interface, and add the provider address to that wrapper as a sibling of the resource address. This causes a big noisy commit today, but should streamline future updates to the UI-facing "identity" of a resource; existing callers can ignore any new fields they're uninterested in, or exploit new info as needed. Other than making new information available for future edits to Hook implementing types, this commit should have no effect on existing behavior.	2 years ago
Nick Fagerlund	d81a546e55	Lints: hook_count_test, "redundant type from slice composite literal" ... I was in the file for other reasons, and wanted to reduce noise in my editor.	2 years ago
Martin Atkins	573c2db658	provider/terraform: Terraform-specific encoding functions ... Using the new possibility of provider-contributed functions, this introduces three new functions which live in the terraform.io/builtin/terraform provider, rather than being language builtins, due to their Terraform-domain-specific nature. The three new functions are: - tfvarsencode: takes a mapping value and tries to transform it into Terraform CLI's "tfvars" syntax, which is a small subset of HCL that only supports key/value pairs with constant values. - tfvarsdecode: takes a string containing content that could potentially appear in a "tfvars" file and returns an object representing the raw variable values defined inside. - exprencode: takes an arbitrary Terraform value and produces a string that would yield a similar value if parsed as a Terraform expression. All three of these are very specialized, of use only in unusual situations where someone is "gluing together" different Terraform configurations etc when the usual strategies such as data sources are not suitable. There's more information on the motivations for (and limitations of) each function in the included documentation.	2 years ago