20 Commits (add-missing-variable-loading)

Author	SHA1	Message	Date
Daniel Schmidt	c5f9b060c7	remove mention of before_destroy, we postponed implementing this event type	7 months ago
Daniel Schmidt	c6c8be3e79	terraform init should pick up action providers	9 months ago
Kristin Laemmert	5adceda98f	feat: update Actions parsing with current syntax (#37313) ... * feat: update Actions parsing with current syntax Updating actions to match the current RFC: - config is in a block - linked_resource(s) exist and need parsing I added a very basic test for the decoding, and updated existing tests with the correct syntax. * very important copyrighted test file	9 months ago
Kristin Laemmert	386988cb50	Decode action blocks and action_triggers inside resource blocks. (#37030) ... * Decode action blocks and action_triggers inside resource blocks. This commit adds decoding of action and action_triggers inside terraform configuration. I added an Actions experiment as a hacky way of keeping the functionality out of main until we're ready for the alpha; this may never be an experiment but it's a handy feature flag so we don't have to do all the work in a long-lived feature branch. * remove legacy shim handling * validate that the referenced entry in actions is indeed an action	11 months ago
James Bardin	be308d07f3	ephemeral configs test files	2 years ago
kmoe	fab3673f8d	lang: stabilise ephemeral values experiment (#35636) ... * lang: stabilise ephemeral values experiment Stabilise the ephemeral values experiment and ephemeralasnull experimental function. * simplify handling of apply time input vars As the final step in stabilising the ephemeral values experiment, we can remove the separate code path for handling input variables supplied via -var and -var-file during apply. The intent here is conveyed in the tests: when applying a saved plan, all ephemeral variables set in the plan (the "apply-time variables"), must be set, and no others. As per the TODO copied from the prototype, there is some more work to be done here in making the handling of undeclared variables during apply as sophisticated as that during plan, emitting helpful warnings (for example) when input variables are supplied unnecessarily via environment variables. * experiments: officially conclude EV experiment --------- Co-authored-by: Radek Simko <radek.simko@gmail.com>	2 years 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
James Bardin	a2b189fd71	handle to expression from json files ... Because expression from JSON files are handled differently from HCL, we need to deal with these manually when evaluating the special "to" syntax. We take the same approach as was done for replace_triggered_by, where the raw string is extracted from the json expression, and re-evaluated as an HCL expression.	3 years ago
Liam Cervante	5d6c5a9a33	plannable import: add a provider argument to the import block (#33175) ... * command: keep our promises * remove some nil config checks Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time. * add GeneratedConfig to plan changes objects Add a new GeneratedConfig field alongside Importing in plan changes. * add config generation package The genconfig package implements HCL config generation from provider state values. Thanks to @mildwonkey whose implementation of terraform add is the basis for this package. * generate config during plan If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node. The generated config string is attached to the change emitted by the plan. * complete config generation prototype, and add tests * plannable import: add a provider argument to the import block * Update internal/configs/config.go Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * Update internal/configs/config.go Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * Update internal/configs/config.go Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com> * fix formatting and tests --------- Co-authored-by: Katy Moe <katy@katy.moe> Co-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>	3 years ago
Liam Cervante	79f7f59155	Plannable import: Generate config for imported resources during the plan. (#33153) ... * command: keep our promises * remove some nil config checks Remove some of the safety checks that ensure plan nodes have config attached at the appropriate time. * add GeneratedConfig to plan changes objects Add a new GeneratedConfig field alongside Importing in plan changes. * add config generation package The genconfig package implements HCL config generation from provider state values. Thanks to @mildwonkey whose implementation of terraform add is the basis for this package. * generate config during plan If a resource is being imported and does not already have config, attempt to generate that config during planning. The config is generated from the state as an HCL string, and then parsed back into an hcl.Body to attach to the plan graph node. The generated config string is attached to the change emitted by the plan. * complete config generation prototype, and add tests --------- Co-authored-by: Katy Moe <katy@katy.moe>	3 years ago
Alisdair McDiarmid	551f6316fa	Do not apply type defaults to null values ... Applying object type defaults to null values can convert null to an object with partial attributes. This means that even a specified default value of null will not remain null after variable evaluation. In turn, the result can then be invalid, if not all attributes in an object type have defaults specified. This commit skips the type default application step during config load and variable evaluation if the default or given value is null of any type. We still perform type conversion.	4 years ago
Martin Atkins	fda0579537	Experiments supported only in alpha/dev builds ... We originally introduced the idea of language experiments as a way to get early feedback on not-yet-proven feature ideas, ideally as part of the initial exploration of the solution space rather than only after a solution has become relatively clear. Unfortunately, our tradeoff of making them available in normal releases behind an explicit opt-in in order to make it easier to participate in the feedback process had the unintended side-effect of making it feel okay to use experiments in production and endure the warnings they generate. This in turn has made us reluctant to make use of the experiments feature lest experiments become de-facto production features which we then feel compelled to preserve even though we aren't yet ready to graduate them to stable features. In an attempt to tweak that compromise, here we make the availability of experiments _at all_ a build-time flag which will not be set by default, and therefore experiments will not be available in most release builds. The intent (not yet implemented in this PR) is for our release process to set this flag only when it knows it's building an alpha release or a development snapshot not destined for release at all, which will therefore allow us to still use the alpha releases as a vehicle for giving feedback participants access to a feature (without needing to install a Go toolchain) but will not encourage pretending that these features are production-ready before they graduate from experimental. Only language experiments have an explicit framework for dealing with them which outlives any particular experiment, so most of the changes here are to that generalized mechanism. However, the intent is that non-language experiments, such as experimental CLI commands, would also in future check Meta.AllowExperimentalFeatures and gate the use of those experiments too, so that we can be consistent that experimental features will never be available unless you explicitly choose to use an alpha release or a custom build from source code. Since there are already some experiments active at the time of this commit which were not previously subject to this restriction, we'll pragmatically leave those as exceptions that will remain generally available for now, and so this new approach will apply only to new experiments started in the future. Once those experiments have all concluded, we will be left with no more exceptions unless we explicitly choose to make an exception for some reason we've not imagined yet. It's important that we be able to write tests that rely on experiments either being available or not being available, so here we're using our typical approach of making "package main" deal with the global setting that applies to Terraform CLI executables while making the layers below all support fine-grain selection of this behavior so that tests with different needs can run concurrently without trampling on one another. As a compromise, the integration tests in the terraform package will run with experiments enabled _by default_ since we commonly need to exercise experiments in those tests, but they can selectively opt-out if they need to by overriding the loader setting back to false again.	4 years ago
Alisdair McDiarmid	922de89be1	Conclude module variable optional attrs experiment	4 years ago
James Bardin	6eb3264d1a	parse replace_triggered_by in resource configs	4 years ago
Alisdair McDiarmid	bb35f02c95	Conclude preconditions/postconditions experiment	4 years ago
Alisdair McDiarmid	b06fe04621	core: Check rule error message expressions ... Error messages for preconditions, postconditions, and custom variable validations have until now been string literals. This commit changes this to treat the field as an HCL expression, which must evaluate to a string. Most commonly this will either be a string literal or a template expression. When the check rule condition is evaluated, we also evaluate the error message. This means that the error message should always evaluate to a string value, even if the condition passes. If it does not, this will result in an error diagnostic. If the condition fails, and the error message also fails to evaluate, we fall back to a default error message. This means that the check rule failure will still be reported, alongside diagnostics explaining why the custom error message failed to render. As part of this change, we also necessarily remove the heuristic about the error message format. This guidance can be readded in future as part of a configuration hint system.	4 years ago
James Bardin	b91d9435ea	Merge pull request #29832 from hashicorp/jbardin/nullable-variable ... configs: explicitly nullable variable values	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	a4c24e3147	Add cloud {} configuration block for Terraform Cloud ... This is a replacement declaration for using Terraform Cloud as a remote backend, leaving the literal backend as an implementation detail and not a user-level concept.	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