32642 Commits (3d211eb42ffcdc9d33d56bc2785d64b22f158c39)

 

All Branches   

Search

Author	SHA1	Message	Date
Liam Cervante	3d211eb42f	Fix crash when importing a resource with complex sensitive attributes (#34996)	2 years ago
Daniel Schmidt	f76a621de2	Merge pull request #34967 from hashicorp/TF-13960 ... stacks: add deferrals to PlanResourceChange	2 years ago
Daniel Schmidt	18c465d139	stacks: document planned object in test	2 years ago
Daniel Schmidt	ea9162235d	stacks: remove extra checks from mock provider	2 years ago
Daniel Schmidt	2c94390434	stacks: refactor to use fully computed change instead of minimal one for deferring in plan	2 years ago
Daniel Schmidt	eaf7eb0771	stacks: use already computed change	2 years ago
Daniel Schmidt	53cee3b2d5	stacks: use marked values for change	2 years ago
Daniel Schmidt	0289806f40	stacks: use existing unmarked values	2 years ago
Daniel Schmidt	c2fe241570	stacks: move destroy deferred handling outside of destroy method	2 years ago
Daniel Schmidt	a26fd2e81f	stacks: add deferrals to PlanResourceChange ... Co-authored-by: Mutahhir Hayat <mutahhir.hayat@hashicorp.com>	2 years ago
Daniel Schmidt	32bf1fed39	stacks: test deferred changeset action	2 years ago
Daniel Schmidt	ddabb6a2ee	refactor replace path logic out of plan method	2 years ago
Daniel Schmidt	b307adfe1f	refactor action selection logic out of plan method	2 years ago
Craig Wright	c1d608e996	Merge pull request #34958 from Skywalker427/patch-2	2 years ago
Craig Wright	1846941721	Merge pull request #34957 from Skywalker427/patch-1	2 years ago
Daniel Schmidt	5c3ce04262	Merge pull request #34961 from hashicorp/TF-13959	2 years ago
James Bardin	8f7744da09	Merge pull request #34986 from hashicorp/jbardin/moved-to-nowhere ... Move target may be in a module which does not exist	2 years ago
Daniel Schmidt	c5291de979	stacks: clarify comment	2 years ago
Daniel Schmidt	fe1a02430f	stacks: don't return planned value for data source if read was deferred	2 years ago
Liam Cervante	ee42dbf5d7	Fix panics due to missing graph edges on empty modules or invalid refs (#34985)	2 years ago
James Bardin	a90f7d254e	check plan to move into missing module	2 years ago
James Bardin	4f1ba8f235	check move target module exists ... We already check if a move target resource still exists, but it's possible the entire module no longer exists.	2 years ago
Daniel Schmidt	a5efe8440d	stacks: return deferral	2 years ago
Daniel Schmidt	57018c8d57	stacks: add test case for ReportDataSourceInstanceDeferred	2 years ago
Craig Wright	d1761f436b	Merge pull request #34918 from hashicorp/deprecated-terraform-config	2 years ago
Craig Wright	2680f6bff9	Update website/docs/cli/config/environment-variables.mdx ... Co-authored-by: Rose M Koron <32436232+rkoron007@users.noreply.github.com>	2 years ago
Craig Wright	a621497f27	Merge pull request #34896 from ChihweiLHBird/zhiwei/filemd5-filesha1-md5-security-notice	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	397ea6d05c	moduletest: Capture optional "execution meta" for test runs ... For now this is only to have a place to save the execution duration, but wrapped in a separate struct so that we can distinguish between cases when it is set and when it isn't, because not all test runners will necessarily populate this and even those that do might not populate it in situations where, for example, a test run gets skipped due to an upstream failure. As of this commit, nothing makes use of this new information. A future commit will use it as part of the experimental JUnit XML output from "terraform test", since the JUnit XML format de-facto _requires_ an execution duration for every test case.	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
Daniel Schmidt	7e3fb0850c	stacks: add ReportDataSourceInstanceDeferred method	2 years ago
Daniel Schmidt	c2ec87c822	Merge pull request #34972 from hashicorp/throw-on-terraform-import-deferred-read	2 years ago
Mark DeCrane	e6f4ffa8a3	stacks: adding deferred action to datasource reads	2 years ago
Liam Cervante	765ec6e923	Complete implementation of targeting with deferred resources (#34971)	2 years ago
Mrinali Rao	b1a40a1a65	Update the Terraform CLI output to show logical separation between OPA and Sentinel policy evaluations (#34963) ... * add sentinel policy evaluation title in the CLI results * Add Sentinel policy evaluations to the CLI * add changelog * minor design fixes	2 years ago
Daniel Schmidt	e9a52e37ac	stacks: return diagnostics if read during terraform import is deferred	2 years ago
Daniel Schmidt	3fdfbd6944	Merge pull request #34887 from hashicorp/TF-13958 ... stacks: handle deferred actions in refresh	2 years ago
Daniel Schmidt	4db9ab8536	stacks: check if resource instance is deferred ... before marking it as deferred	2 years ago
Daniel Schmidt	301061047a	stacks: add read resource test case without refresh opts	2 years ago
Daniel Schmidt	3d80ec4aa2	stacks: return deferral instead of recording it	2 years ago
Daniel Schmidt	b59edb4463	stacks: handle deferred actions in refresh ... Co-authored-by: Matej Risek <matej.risek@hashicorp.com>	2 years ago
Daniel Schmidt	5b8f77d2a4	stacks: add deferred actions to plugin protocol ... We are moving the deferred reason from plans/deferring to providers to have a single representation of deferred reason to be used from providers to the plan. Using the plan's representation causes circular dependencies. Co-authored-by: Matej Risek <matej.risek@hashicorp.com>	2 years ago
Liam Cervante	cbee7469b0	Complete functionality for the unknown instances processing path for resources (#34945) ... * Expand functionality of the unknown count/for_each path when processing resources * remove reference to experiment in tests * fix race tests * update tests * address comments	2 years ago
Hamzah Junaid Bawah	b520e52d8b	docs: fix typo in spelling of 'Sentinel' ... Correct spelling from 'Sential' to 'Sentinel'	2 years ago
Hamzah Junaid Bawah	b21d232081	docs: fix typo in spelling of 'flag' ... Change spelling from 'flat' to 'flag' to fix typo	2 years ago
Martin Atkins	d8f22d3c54	Update CHANGELOG.md	2 years ago
Martin Atkins	79479f52c9	terraform: Experimental support for variable validation cross-references ... When a module opts in to the variable_validation_crossref experiment, Terraform will treat variable validation rules in a similar way as any other dynamic expression, allowing it to refer to other objects that are declared in the same module as the variable. Because the check for a validation rule referring only to itself is now experiments-sensitive we need to do it only once the full module has been assembled, rather than during assembly of individual files, and so the "badref" test in package configs is now classified under "invalid-modules" rather than "invalid-files". It's otherwise unchanged, and the existing test that a validation rule must refer to at least _something_ is still present because that remains true even when opted in to the experiment. This is experimental for now because although it seems pretty plausible that it should be okay, this is allowing full evaluation in a new place where it wasn't allowed before and so we'd like to ask those interested in this feature to try it out with some of their realistic use-cases and make sure this solution is a good fit before we lock it in as a compatibility constraint.	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
Martin Atkins	9b8d25b9e9	terraform: new nodes for variable validation (not yet implemented) ... So far we've handled custom validation rules as a part of the same graph node that is responsible for deciding the final value for an input variable, but that's bothersome for two reasons: - There are two different pieces of code both trying to implement the same rules: the root variable node and the module variable node. Those have accidentally diverged in the past. - Each graph node can evaluate expressions only in one module's scope, and so the module variable node is set up to evaluate in the parent module's scope because its purpose is to explicitly pass parent module data into the child module. That is why we haven't yet allowed input variable validation rules to refer to objects declared in the module where the variable is declared. This commit does not actually yet change any real behavior, because this new graph node has no "Execute" implementation. The focus here is just to make sure the graph nodes are inserted into the graph with the needed edges so that a future commit can move the validation logic into here, and hopefully eventually also allow the validation rules to refer to objects declared in the child module.	2 years ago