19 Commits (add-missing-variable-loading)

Author	SHA1	Message	Date
Daniel Schmidt	accaa8d027	also check against action references in depends_on during config parsing	6 months ago
Sarah French	61a7914dd9	Add test helper to create mock provider that contains a state store (#37556) ... * Add a helper for mocking a provider with a state store * Update tests to use the new helper * Update other test fixtures for consistency The related tests pass before and after this change * Update testing helper to return the underlying type, not the interface	7 months ago
Sarah French	b3d7dae793	Add config parsing and validation for PSS (#37178) ... * Enable parsing of blocks in individual files Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com> * Enable handling of state stores when parsing a module from its constituent files. This includes: validations of duplicates and clashes, supporting override files. Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com> * Add tests for validation that detects conflicts between state_store blocks and others * Add tests for state_store override behavior * Add tests for validation that detects when conflicting state-related blocks are used, either in the same file or across separate files * Update error message summaries to explicitly say blocks conflict * Add small changes to assertions in state_store override tests * Update state_store block parsing to expect scoped provider block * Update tests following syntax change * Make config parsing experimental * Remove testModuleFromDirWithExperiment, as testModuleFromDirWithExperiments exists! * Update code comment --------- Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com> Co-authored-by: Radek Simko <radek.simko@gmail.com>	10 months ago
Sarah French	6f07b460a7	Update and add new tests for module-parsing logic (#37176) ... * Add comments, rename tests, reorder tests This commit doesn't change or add any logic * Add test for overriding a cloud block with a backend block * Add tests showing multiple instances of cloud or backend blocks cause an error * Add test showing that backend and cloud blocks cannot be in the same terraform block * Add test case asserting it's not valid to have both cloud and backend blocks across files in a module * Clarify comments and replace some comments with test names * Replace comments with test names	11 months ago
Martin Atkins	3b620bfe69	terraform: Stabilize the variable_validation_crossref experiment ... Previously we introduced a language experiment that would permit variable validation rules to refer to other objects declared in the same module as the variable. Now that experiment is concluded and its behavior is available for all modules. This final version deviates slightly from the experiment: we learned from the experimental implementation that we accidentally made the "validate" command able to validate constant-valued input variables in child modules despite the usual rule that input variables are unknown during validation, because the previous compromise bypassed the main expression evaluator and built its own evaluation context directly. Even though that behavior was not intended, it's a useful behavior that is protected by our compatibility promises and so this commit includes a slightly hacky emulation of that behavior, in eval_variable.go, that fetches the variable value in the same way the old implementation would have and then modifies the hcl evaluation context to include that value, while preserving anything else that our standard evaluation context builder put in there. That narrowly preserves the old behavior for expressions that compare the variable value directly to a constant, while treating all other references (which were previously totally invalid) in the standard way. This quirk was already covered by the existing test TestContext2Validate_variableCustomValidationsFail, which fails if the special workaround is removed.	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
Liam Cervante	3a75362cce	terraform test: run block names should be valid HCL identifiers (#34469) ... * terraform test: run block names should be valid HCL identifiers * fix test	2 years ago
James Bardin	8125fe56a4	cannot statically validate an import target moved ... The validation for checking if an import target is the source of a moved block is incorrect. Besides the noted FIXME of the check being incorrect for moved modules (and also resources scoped within modules); an import can only be statically identified at the granularity of a resource block, but moved block can have individual instances in the `from` field. Since we already validate that a resource block must _not_ exist in the config for `moved`, we can rely on that causing `import` to fail with a nonexistant resource block during evaluation if they have the same target.	2 years ago
Liam Cervante	041b54fb4b	explicitely disallow duplicate run block names in test files (#33836)	3 years ago
kmoe	1172d40d7b	error if import target is move source (#33192) ... It is invalid for any import block to have a "to" argument matching any moved block's "from" argument.	3 years ago
Alisdair McDiarmid	922de89be1	Conclude module variable optional attrs experiment	4 years ago
Alisdair McDiarmid	bb35f02c95	Conclude preconditions/postconditions experiment	4 years ago
Martin Atkins	9076400436	configs: Decode preconditions and postconditions ... This allows precondition and postcondition checks to be declared for resources and output values as long as the preconditions_postconditions experiment is enabled. Terraform Core doesn't currently know anything about these features, so as of this commit declaring them does nothing at all.	4 years ago
James Bardin	b91d9435ea	Merge pull request #29832 from hashicorp/jbardin/nullable-variable ... configs: explicitly nullable variable values	5 years ago
Martin Atkins	94cbc8fb5d	experiments: config_driven_move has concluded ... Based on feedback during earlier alpha releases, we've decided to move forward with the current design for the first phase of config-driven refactoring. Therefore here we've marked the experiment as concluded with no changes to the most recent incarnation of the functionality. The other changes here are all just updating test fixtures to no longer declare that they are using experimental features.	5 years ago
James Bardin	f0a64eb456	configs: explicitly nullable variable values ... The current behavior of module input variables is to allow users to override a default by assigning `null`, which works contrary to the behavior of resource attributes, and prevents explicitly accepting a default when the input must be defined in the configuration. Add a new variable attribute called `nullable` will allow explicitly defining when a variable can be set to null or not. The current default behavior is that of `nullable=true`. Setting `nullable=false` in a variable block indicates that the variable value can never be null. This either requires a non-null input value, or a non-null default value. In the case of the latter, we also opt-in to the new behavior of a `null` input value taking the default rather than overriding it. In a future language edition where we make `nullable=false` the default, setting `nullable=true` will allow the legacy behavior of `null` overriding a default value. The only future configuration in which this would be required even if the legacy behavior were not desired is when setting an optional+nullable value. In that case `default=null` would also be needed and we could therefor imply `nullable=true` without requiring it in the configuration.	5 years ago
Chris Arcand	18d54c1129	Allow cloud block overrides ... These changes allow cloud blocks to be overridden by backend blocks and vice versa; the logic follows the current backend behavior of a block overriding a preceding block in full, with no merges.	5 years ago
Martin Atkins	6b8e103d6a	configs: Include "moved" blocks when merging multiple files into a module ... An earlier commit added logic to decode "moved" blocks and do static validation of them. Here we now include that result also in modules produced from those files, which we can then use in Terraform Core to actually implement the moves. This also places the feature behind an active experiment keyword called config_driven_move. For now activating this doesn't actually achieve anything except let you include moved blocks that Terraform will summarily ignore, but we'll expand the scope of this in later commits to eventually reach the point where it's really usable.	5 years ago
Martin Atkins	31349a9c3a	Move configs/ to internal/configs/ ... This is part of a general effort to move all of Terraform's non-library package surface under internal in order to reinforce that these are for internal use within Terraform only. If you were previously importing packages under this prefix into an external codebase, you could pin to an earlier release tag as an interim solution until you've make a plan to achieve the same functionality some other way.	5 years ago