184 Commits (6dcf00aefc56b48bae54822a6e62eacffd2bc3ea)

Author	SHA1	Message	Date
Krista LaFentres (she/her)	6dcf00aefc	Merge pull request #30344 from hashicorp/lafentres/refactor-show-command ... cli: Refactor show command & migrate to command arguments and views	4 years ago
Krista LaFentres	fea8f6cfa2	cli: Migrate show command to use command arguments and views	4 years ago
Krista LaFentres	8d1bced812	cli: Refactor show command to remove dependence on local run and only load the backend when we need it ... See https://github.com/hashicorp/terraform/pull/30205#issuecomment-997113175 for more context	4 years ago
Martin Atkins	36c4d4c241	core and backend: remove redundant handling of default variable values ... Previously we had three different layers all thinking they were responsible for substituting a default value for an unset root module variable: - the local backend, via logic in backend.ParseVariableValues - the context.Plan function (and other similar functions) trying to preprocess the input variables using terraform.mergeDefaultInputVariableValues . - the newer prepareFinalInputVariableValue, which aims to centralize all of the variable preparation logic so it can be common to both root and child module variables. The second of these was also trying to handle type constraint checking, which is also the responsibility of the central function and not something we need to handle so early. Only the last of these consistently handles both root and child module variables, and so is the one we ought to keep. The others are now redundant and are causing prepareFinalInputVariableValue to get a slightly corrupted view of the caller's chosen variable values. To rectify that, here we remove the two redundant layers altogether and have unset root variables pass through as cty.NilVal all the way to the central prepareFinalInputVariableValue function, which will then handle them in a suitable way which properly respects the "nullable" setting. This commit includes some test changes in the terraform package to make those tests no longer rely on the mergeDefaultInputVariableValues logic we've removed, and to instead explicitly set cty.NilVal for all unset variables to comply with our intended contract for PlanOpts.SetVariables, and similar. (This is so that we can more easily catch bugs in callers where they _don't_ correctly handle input variables; it allows us to distinguish between the caller explicitly marking a variable as unset vs. not describing it at all, where the latter is a bug in the caller.)	4 years ago
Martin Atkins	b802db75d7	build: Build and run e2etest as part of the release build pipeline ... This uses the decoupled build and run strategy to run the e2etests so that we can arrange to run the tests against the real release packages produced elsewhere in this workflow, rather than ones generated just in time by the test harness. The modifications to make-archive.sh here make it more consistent with its originally-intended purpose of producing a harness for testing "real" release executables. Our earlier compromise of making it include its own terraform executable came from a desire to use that script as part of manual cross-platform testing when we weren't yet set up to support automation of those tests as we're doing here. That does mean, however, that the terraform-e2etest package content must be combined with content from a terraform release package in order to produce a valid contest for running the tests. We use a single job to cross-compile the test harness for all of the supported platforms, because that build is relatively fast and so not worth the overhead of matrix build, but then use a matrix build to actually run the tests so that we can run them in a worker matching the target platform. We currently have access only to amd64 (x64) runners in GitHub Actions and so for the moment this process is limited only to the subset of our supported platforms which use that architecture.	4 years ago
Alisdair McDiarmid	535da4ebc7	Merge pull request #30205 from hashicorp/alisdair/fix-show-plan-against-non-default-state ... command/show: Disable plan state lineage checks	4 years ago
Martin Atkins	23395a1022	providercache: Discard lock entries for unused providers ... Previously we would only ever add new lock entries or update existing ones. However, it's possible that over time a module may _cease_ using a particular provider, at which point we ought to remove it from the lock file so that operations won't fail when seeing that the provider cache directory is inconsistent with the lock file. Now the provider installer (EnsureProviderVersions) will remove any lock file entries that relate to providers not included in the given requirements, which therefore makes the resulting lock file properly match the set of packages the installer wrote into the cache. This does potentially mean that someone could inadvertently defeat the lock by removing a provider dependency, running "terraform init", then undoing that removal, and finally running "terraform init" again. However, that seems relatively unlikely compared to the likelihood of removing a provider and keeping it removed, and in the event it _did_ happen the changes to the lock entry for that provider would be visible in the diff of the provider lock file as usual, and so could be noticed in code review just as for any other change to dependencies.	4 years ago
Alisdair McDiarmid	768741c0f7	command/show: Disable plan state lineage checks ... When showing a saved plan, we do not need to check the state lineage against current state, because the plan cannot be applied. This is relevant when plan and apply specify a `-state` argument to choose a non-default state file. In this case, the stored prior state in the plan will not match the default state file, so a lineage check will always error.	4 years ago
Chris Arcand	8b8fe2771f	Merge pull request #30142 from hashicorp/chrisarcand/remote-backend-no-workspaces-regression ... command/meta_backend: Allow the remote backend to have no workspaces [again]	4 years ago
Chris Arcand	98978b3853	command/meta_backend: Allow the remote backend to have no workspaces [again] ... A regression introduced in d72a413ef8 The comment explains, but TLDR: The remote backend actually *depended* on being able to write it's backend state even though an 'error' occurred (no workspaces).	4 years ago
Martin Atkins	096cddb4b7	command/format: Limitation of plans.ResourceInstanceDeleteBecauseNoModule ... This is an explicit technical debt note that our plan renderer isn't able to give a fully-specific hint in this particular case of deletion reason. This reason code means that at least one of the module instance keys in the resource's module path doesn't match an instance declared in the configuration, but the plan data structure doesn't retain enough information to know which is the first step in the path which refers to a missing instance, and so we just always return the whole thing. This would be confusing if we return module.foo[0].module.bar not being in the configuration as a result of module.foo not using "count"; it would be better to say "module.foo[0] is not in the configuration" instead. It would be most ideal to handle all of the different situations that ResourceInstanceDeleteBecauseWrongRepetition's rendering does, so that we can go further and explain exactly _why_ that module instance isn't declared anymore. We can do neither of those things today because only the Terraform Core "expander" component knows that information, and we've discarded that by the time we get to rendering a plan. To fix this one day would require preserving in the plan information about which module instances are declared, as a separate sidecar data structure from which resource instances we're taking actions on, and then using that to identify which step in addr.Module here first selects an invalid instance.	4 years ago
Chris Arcand	f4f5b7c968	Merge pull request #30059 from hashicorp/barrettclark/explicit-local-empty-migrate-messaging ... Cloud: Do not ask to migrate empty default workspace	4 years ago
Barrett Clark	c706c8f92b	Do not ask to migrate empty default workspace ... When migrating from an explicit local backend to Terraform Cloud, we ask if you want to migrate the state. If there is no state to migrate we should not ask if they want to migrate the emptiness.	4 years ago
Barrett Clark	e08a02e7bf	Fixes Issue #29959, Apply w/o init error message ... When going from a local backend to Terraform Cloud, if you skip the `terraform init` and run `terraform apply` this will give the user more clear instructions.	4 years ago
Luces Huayhuaca	d72a413ef8	command/meta_backend: Prompt to select workspace before saving backend config (#29945) ... When terraform detects that a user has no workspaces that map to their current configuration, it will prompt the user to create a new workspace and enter a value name. If the user ignores the prompt and exits it, the legacy backend (terraform.tfstate) will be left in a awkward state: 1. This saved backend config will show a diff for the JSON attributes "serial", "tags" and "hash" 2. "Terraform workspace list" will show an empty list 3. "Terraform apply" will run successfully using the previous workspace, from the previous config, not the one from the current saved backend config 4. The cloud config is not reflective of the current working directory Solution: If the user exits the prompt, the saved backend config should not be updated because they did not select a new workspace. They are back at the beginning where they are force to re run the init cmd again before proceeding with new changes.	4 years ago
Chris Arcand	b5af7b6c92	Merge pull request #29987 from hashicorp/chrisarcand/backend-flag-with-tfc ... command/init: Add -cloud alias to -backend, adjust `init` help output	4 years ago
Barrett Clark	a6b56ad76f	Merge pull request #29997 from hashicorp/barrettclark/cloud-input-false ... Cloud integration requires input for migrations	4 years ago
Barrett Clark	419676cb69	Cloud integration requires input for migrations ... We cannot programmatically migrate workspaces to Terraform Cloud without prompts, so `-input=false` should not be allowed in those cases. There are 4 scenarios where we need input from a user to complete migrating workspaces to Terraform Cloud. 1.) Migrate from a single local workspace to Terraform Cloud * Terraform config for a local backend. Implicit local (no backend specified) is fine. * `terraform init` and `terraform apply` * Change the Terraform config to use the cloud block * `terraform init -input=false` * You should now see an error message 2.) Migrate from a remote backend with a prefix to Terraform Cloud with tags * Create a workspace in Terraform Cloud manually. The name should include a prefix, like "app-one" * Have the terraform config use `backend "remote"` with a prefix set to "app-" * `terraform init` and `terraform apply` * Update the Terraform config to use a cloud block with `tags = ["app"]`. There should not be a prefix defined in the config now. * `terraform init -input=false` * You should now see an error message 3.) Migrate from multiple local workspaces to a single Terraform Cloud workspace * Create one or many local workspaces * `terraform init` and `terraform apply` in each * Change the Terraform config to use the cloud block * `terraform init -input=false` * You should now see an error message 4.) Migrate to Terraform Cloud and ask for a workspace name * Create several local workspaces * `terraform init` and `terraform apply` in each * Change the Terraform config to use the cloud block with tags * `terraform init -input=false` * You should now see an error message	4 years ago
Luces Huayhuaca	f63b6198ca	Create a function for logic that assigns value to initReason var after changing backend configuration (#29967) ... * Create a function for logic that assigns value to initReason var after changing backend configuration Create func determineInitReason() for logic block that assigns value to initReason var after changing backend/cloud configuration block or migrating to a different type of backend configuration. Also clarify 'cloud' configuration block message to say 'Terraform Cloud configuration block has changed' instead of 'Terraform Cloud configuration has changed'.	4 years ago
Alisdair McDiarmid	a8b9d086b2	cli: Fix nested single and map diff rendering ... Indentation was out by two spaces. This is now consistent with the other displays of object/map values: four spaces for each nesting level.	4 years ago
Chris Arcand	a0c7c1dc8d	command/init: Adjust init help output ... Some of the wording here needed adjusting with the change that backends largely reflect state snapshot storage (removing 'enhanced' designation), and that a 'backend' is not necessarily always present.	4 years ago
Chris Arcand	33d7c1e6d6	command/init: Add -cloud alias (of -backend) ... This fixes an issue where a user could not disable initialization of the 'cloud' configuration block (As is possible with -backend=false), as well as add some syntactic sugar around -backend by adding a mutually exclusive -cloud alias.	4 years ago
Alisdair McDiarmid	b562c4fb84	cli: Fix nested set diff rendering indentation	4 years ago
Alisdair McDiarmid	2d0349d9a4	cli: Fix diff for nested set unchanged elements ... Unchanged elements in nested attributes backed by sets were previously misrendered as empty objects. This commit removes the additional brackets and adds a count of unchanged elements.	4 years ago
Martin Atkins	7d6d31eff8	command/init: Skip redundant state migration prompt in Cloud mode ... The specialized Terraform Cloud migration process asks right up top whether the user wants to migrate state, because there are various other questions contingent on that answer. Therefore we ought to just honor their earlier answer when we get to the point of actually doing the state migration, rather than prompting again. This is tricky because we're otherwise just reusing a codepath that's common to both modes. Hopefully we can find a better way to do this in a later commit, but for the moment our main motivation is minimizing risk to the very next release.	4 years ago
Martin Atkins	bac59d2480	command/init: Be explicit that some options are not relevant for Cloud ... There are a few command line options for "terraform init" which are only relevant when working with traditional backends, with the Cloud integration previously just mostly ignoring them, or sometimes misbehaving slightly due to them creating an unreasonable situation. Now we'll catch these and return explicit errors, in order to be clear that these options are not needed nor supported in Cloud mode.	4 years ago
Barrett Clark	a146a2746e	Add clarifying commend and e2e test ... This pull request focuses on removing the prompt to rename the default workspace when it is empty. Functionality already exists to not migrate an empty workspace. This commit adds some clarifying language in the comment where we do the evaluation to know whether to ask for a new name or not. I also added an end to end test, which I should have added to begin with.	4 years ago
Barrett Clark	a9eb62d692	Cloud: Migrate empty default workspace prompt ... Given: You have multiple explicit local workspaces, and the `default` workspace is empty. When: You migrate the workspaces to Terraform Cloud. Then: Terraform should _not_ ask for a workspace to migrate the `default` workspace to in Terraform Cloud.	4 years ago
Chris Arcand	bf76cc98ef	command: Suggestions on migration copy from user feedback ... Some small edits to the TFC migration copy.	4 years ago
kmoe	64635edfb9	Merge pull request #29885 from hashicorp/kmoe/more-init-interrupts ... command: make module installation interruptible	4 years ago
Katy Moe	6da61bf07b	revert change to installModules diag handling ... Error diags from c.installModules() no longer cause getModules() to exit early. Whether installModules completed successfully, errored, or was cancelled, we try to update the manifest as best we can, preferring incomplete information to none.	4 years ago
kmoe	40ec62c139	command: make module installation interruptible ... Earlier work to make "terraform init" interruptible made the getproviders package context-aware in order to allow provider installation to be cancelled. Here we make a similar change for module installation, which is now also cancellable with SIGINT. This involves plumbing context through initwd and getmodules. Functions which can make network requests now include a context parameter whose cancellation cancels those requests. Since the module installation code is shared, "terraform get" is now also interruptible during module installation.	4 years ago
Krista LaFentres	c44c589f0a	Error if backup or backup-out options are used without the state option on non-local backends for the state mv command	4 years ago
Chris Arcand	779c958fbf	cloud: Add streamlined 'remote' backend state migration path ... For Terraform Cloud users using the 'remote' backend, the existing 'pattern' prompt should work just fine - but because their workspaces are already present in TFC, the 'migration' here is really just realigning their local workspaces with Terraform Cloud. Instead of forcing users to do the mental gymnastics of what it means to migrate from 'prefix' - and because their remote workspaces probably already exist and already conform to Terraform Cloud's naming concerns - streamline the process for them and calculate the necessary pattern to migrate as-is, without any user intervention necessary.	4 years ago
Chris Arcand	6f25ad3e17	cloud: Display the newly renamed workspaces after a migration	4 years ago
Chris Arcand	c3bf5d4512	cloud: Automatically select renamed current workspace ... After migrating to TFC with renamed workspaces, automatically select what was the previous current workspace on behalf of the user. We don't need to make the user reselect.	4 years ago
Chris Arcand	f80b2177c8	cloud: Tweak multi-to-multi migration UX ... Note these change do break the internal/cloud/e2e tests; they are in a sad state that needs adjusting anyway, so I'm not updating them for these changes at this time.	4 years ago
Chris Arcand	f04ea2bd3d	Merge pull request #29860 from hashicorp/fix-init-after-error-take-two ... command: Update backend hash value only after a successful migration	4 years ago
Chris Arcand	7c0c2e952f	command: Don't always update backend hash when fetching the saved backend ... The Meta.backend_C_r_S_unchanged() method was sadly a bit of a mess. It seems to have originally been used as a method to be called when the backend is not changing, with an extra assumption that if the configured backend's hash doesn't match the one in state, surely the hash should just be updated as an option might have been moved to command line flags. However, this function was used throughout this file as 'the method to load the initialized (but not necessarily configured) backend', regardless of whether or not it is the same (unchanged). This is in addition to Meta.backendFromState(), which is used to load the same thing except in the main codepath of 'init -backend=false'. These changes separate the concerns of backend_C_r_S_unchanged() by 1) Fetching the saved backend (savedBackend()) 2) Updating the hash value in the backend cache when appropriate (either by leaving it to the caller to do themselves or by calling updateSavedupdateSavedBackendHash()) This allows migration codepaths to *not* update the hash value until after a migration has successfully taken place.	4 years ago
Łukasz Sierant	19cce931a8	Test case for changing backend hash during aborted state migration ... Pulled and updated from https://github.com/hashicorp/terraform/pull/26260	4 years ago
Billy Keyes	52ca30273f	command/format: improve list nested attribute rendering (#29827) ... * command/format: fix list nested attr diff rendering Previously, diffs only rendered correctly if all changed elements appeared before all unchanged elements. Once an unchanged element was found, all remaining elements were skipped. This usually led to the output being an empty list with a weird amount of space between the brackets. * command/format: improve list nested attr rendering This makes several changes that make diffs for lists clearer and more consistent: * Separate items with brackets instead of only new lines. This better matches the input syntax and avoids confusion from the first and last brackets implying there is a single item. * Render an action symbol for each element of the list * Use the correct action symbol for new and deleted items * Fix the alignment of opening and closing brackets I also refactored the structure so it is similar to the set and map cases to minimize duplication of the new prints. * Fix re-use of blockBodyDiffResult struct	4 years ago
Nick Fagerlund	02e62c9851	Cloud: Init without erroring when no workspaces match the `tags` (#29835) ... Previously, `terraform init` was throwing an error if you configured the cloud block with `tags` and there weren't any tagged workspaces yet. Confusing and alienating, since that that's a fairly normal situation! Basically TFC was handling an empty list of workspaces worse than other backends, because it doesn't support an unnamed default workspace. This commit catches that condition during `Meta.selectBackend()` and asks the user to pick a name for their first tagged workspace. If they cancel out, we still error, but if we know what name they want, we can handle it the same way as a nonexistent workspace specified in `name` -- just pass it to `Meta.SetWorkspace()`, and let the workspace get implicitly created when `InitCommand.Run()` eventually calls `StateMgr()`.	4 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.	4 years ago
Chris Arcand	511afcd43a	command: Adjust skipping of resource counts for any remote implementation ... When using the Terraform Cloud integration - like the 'remote' backend - resource count output should be suppressed if those counts are being rendered remotely. This generalizes this to the shared BackendWithRemoteTerraformVersion interface.	4 years ago
James Bardin	81e709d185	Merge pull request #29825 from hashicorp/jbardin/no-panicwrap ... Remove the use of panicwrap in the Terraform CLI	4 years ago
Martin Atkins	f266d1ee82	"Add cloud integration option" ... A more native integration for Terraform Cloud and its CLI-driven run workflow. Instead of a backend, users declare a special block in the top-level terraform settings block to configure Terraform Cloud, then run terraform init. Full documentation will follow in later commits.	4 years ago
Chris Arcand	6dc1fed6d5	Clarify legacy Ui comments	4 years ago
Chris Arcand	14260a5b4c	Adjust default workspace naming prompt ... The previous version is a little overdramatic and somewhat accusatory. Just lay it out how it is: TFC needs workspaces to be named.	4 years ago
Omar Ismail	fc5863844c	Cloud migration: ignore backend version check when empty worksapces	4 years ago
Barrett Clark	f5366468b4	Cloud Backend reference migrating away from TFC	4 years ago