21 Commits (80d4c4841900bc4e6a555ffce21e3e2eae1fbe03)

Author	SHA1	Message	Date
Liam Cervante	8e47b5907c	stacks: provide more helpful diagnostics when providers types are mismatched (#35422) ... * stacks: provide more helpful diagnostics when providers types are mismatched * remove left over implementation experiments * remove unnecessary fmt.Sprintf * address comments * fix incorrect pluralisation * fix tests	2 years ago
Liam Cervante	48fc2d3ac7	terraform test: Disallow version constraints within test files (#35161)	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
Liam Cervante	cec4b7b74c	stacks: validate providers based on types instead of local names (#34735) ... * stacks: validate providers based on types instead of local names * fix tests	2 years ago
Martin Atkins	ff992238c1	core: Allow passing in externally-configured provider instances ... Normally Terraform Core expects what it sees as the root module to be a self-contained root module which defines all of the provider configurations it needs. This commit is the start of making it valid for the apparent root module to actually be a shared module, which means it'd expect to receive provider configurations from its caller rather than defining them itself. The caller of the "root" module is the Terraform Core caller written in Go, so this is essentially a Go equivalent of the "providers" argument in a "module" block in the Terraform language.	2 years ago
Martin Atkins	bd5b49b036	configs: Config.EffectiveRequiredProviderConfigs ... This new helper summarizes all of the provider configuration addresses that a module would require to have passed in or inherited from its caller.	2 years ago
Liam Cervante	57edb9c248	testing framework: add warnings for override blocks with invalid targets (#34181) ... * testing framework: add warnings for override blocks with invalid targets * pre-add the override sources for upcoming features * address comments	2 years ago
Liam Cervante	5bbdc4c3b6	terraform test: allow providers in test files to reference variables (#34069) ... * Process only relevant variables in the testing framework * add support for variables within test provider configurations * remove unused function * fix consistency checks	3 years ago
kmoe	4b88808201	configs/terraform: refactor expansion code, add diags (#33962) ... * configs: remove unneeded code This code inside addProviderRequirements adds an entry to the provider map for each resource targeted by an import block. In the normal case without config generation, a resource block must exist for each import block, so provider requirements will be collected from the resource block. In the config generation case, the code block directly below this deleted one will add the appropriate provider requirements where these must come from the import block. * terraform: diags in DynamicExpand	3 years ago
James Bardin	df23c703ce	import block decode ... Update the import configuration block to decode for_each and to into raw expressions, so that we can later evaluate those during expansion.	3 years ago
hashicorp-copywrite[bot]	53c34ff49c	Update copyright file headers to BUSL-1.1	3 years ago
Liam Cervante	222676390c	testing framework: add validation for provider blocks in test files (#33542) ... * testing framework: add validation for provider blocks in test files * .tftest -> .tftest.hcl	3 years ago
Liam Cervante	4b34902fab	[testing framework] allow tests to define and override providers (#33466) ... * [testing framework] prepare for beta phase of development * [Testing Framework] Add module block to test run blocks * [testing framework] allow tests to define and override providers	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
hashicorp-copywrite[bot]	325d18262e	[COMPLIANCE] Add Copyright and License Headers	3 years ago
Alisdair McDiarmid	8df065a2fe	initwd: Switch from earlyconfig to configs ... This is a mostly mechanical refactor with a handful of changes which are necessary due to the semantic difference between earlyconfig and configs. When parsing root and descendant modules in the module installer, we now check the core version requirements inline. If the Terraform version is incompatible, we drop any other module loader diagnostics. This ensures that future language additions don't clutter the output and confuse the user. We also add two new checks during the module load process: * Don't try to load a module with a `nil` source address. This is a necessary change due to the move away from earlyconfig. * Don't try to load a module with a blank name (i.e. `module ""`). Because our module loading manifest uses the stringified module path as its map key, this causes a collision with the root module, and a later panic. This is the bug which triggered this refactor in the first place.	3 years ago
Martin Atkins	df578afd7e	backend/local: Check dependency lock consistency before any operations ... In historical versions of Terraform the responsibility to check this was inside the terraform.NewContext function, along with various other assorted concerns that made that function particularly complicated. More recently, we reduced the responsibility of the "terraform" package only to instantiating particular named plugins, assuming that its caller is responsible for selecting appropriate versions of any providers that _are_ external. However, until this commit we were just assuming that "terraform init" had correctly selected appropriate plugins and recorded them in the lock file, and so nothing was dealing with the problem of ensuring that there haven't been any changes to the lock file or config since the most recent "terraform init" which would cause us to need to re-evaluate those decisions. Part of the game here is to slightly extend the role of the dependency locks object to also carry information about a subset of provider addresses whose lock entries we're intentionally disregarding as part of the various little edge-case features we have for overridding providers: dev_overrides, "unmanaged providers", and the testing overrides in our own unit tests. This is an in-memory-only annotation, never included in the serialized plan files on disk. I had originally intended to create a new package to encapsulate all of this plugin-selection logic, including both the version constraint checking here and also the handling of the provider factory functions, but as an interim step I've just made version constraint consistency checks the responsibility of the backend/local package, which means that we'll always catch problems as part of preparing for local operations, while not imposing these additional checks on commands that _don't_ run local operations, such as "terraform apply" when in remote operations mode.	5 years ago
Martin Atkins	17b766c3ea	configs: EntersNewPackage methods for descendant modules ... Now that we (in the previous commit) refactored how we deal with module sources to do the parsing at config loading time rather than at module installation time, we can expose a method to centralize the determination for whether a particular module call (and its resulting Config object) enters a new external package. We don't use this for anything yet, but in later commits we will use this for some cross-module features that are available only for modules belonging to the same package, because we assume that modules grouped together in a package can change together and thus it's okay to permit a little more coupling of internal details in that case, which would not be appropriate between modules that are versioned separately.	5 years ago
Martin Atkins	1a8da65314	Refactoring of module source addresses and module installation ... It's been a long while since we gave close attention to the codepaths for module source address parsing and external module package installation. Due to their age, these codepaths often diverged from our modern practices such as representing address types in the addrs package, and encapsulating package installation details only in a particular location. In particular, this refactor makes source address parsing a separate step from module installation, which therefore makes the result of that parsing available to other Terraform subsystems which work with the configuration representation objects. This also presented the opportunity to better encapsulate our use of go-getter into a new package "getmodules" (echoing "getproviders"), which is intended to be the only part of Terraform that directly interacts with go-getter. This is largely just a refactor of the existing functionality into a new code organization, but there is one notable change in behavior here: the source address parsing now happens during configuration loading rather than module installation, which may cause errors about invalid addresses to be returned in different situations than before. That counts as backward compatible because we only promise to remain compatible with configurations that are _valid_, which means that they can be initialized, planned, and applied without any errors. This doesn't introduce any new error cases, and instead just makes a pre-existing error case be detected earlier. Our module registry client is still using its own special module address type from registry/regsrc for now, with a small shim from the new addrs.ModuleSourceRegistry type. Hopefully in a later commit we'll also rework the registry client to work with the new address type, but this commit is already big enough as it is.	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