10 Commits (f-gen-integration-tests)

Author	SHA1	Message	Date
Martin Atkins	f0ccee854c	command/0.13upgrade: Remove this subcommand ... We only preserve these major upgrade versions for one major version after they are added, because our upgrade path assumes moving forward only one major version at a time. Now that our main branch is tracking towards Terraform 0.14, we no longer need the 0.13upgrade subcommand. This also includes some minor adjustments to the 0.12upgrade command to align the terminology used in the output of both commands. We usually use the word "deprecated" to mean that something is still available but no longer recommended, but neither of these commands is actually available so "removed" is clearer. We could in principle have removed even the removal notice for 0.12upgrade here, but it's relatively little code and not a big deal to keep around to help prompt those who might try to upgrade directly from 0.11 to 0.14. We may still remove the historical configuration upgrade commands prior to releasing Terraform 1.0, though.	6 years ago
Alisdair McDiarmid	fc7e467d19	command: Add redirect support to 0.13upgrade ... If a provider changes namespace in the registry, we can detect this when running the 0.13upgrade command. As long as there is a version matching the user's constraints, we now use the provider's new source address. Otherwise, warn the user that the provider has moved and a version upgrade is necessary to move to it.	6 years ago
Masayuki Morita	ee913a1c87	command/0.13upgrade: make confirmation more user-friendly (#25142) ... I feel the current confirmation prompt for 0.13upgrade command is ambiguous what is expected. Actually, when I used it for the first time, I cancelled it by typing `y` instead of `yes`. I believe it would be great if the 0.13upgrade command tell us the expected value for confirmation like 0.12upgrade.	6 years ago
Alisdair McDiarmid	ca40107066	command/init: Better diagnostics for provider 404s ... Fetching a default namespace provider from the public registry can result in 404 Not Found error. This might be caused by a previously- default provider moving to a new namespace, which means that the configuration needs to be upgraded to use an explicit provider source. This commit adds a more detailed diagnostic for this situation, suggesting that the intended provider might be in a new namespace. The recommended course of action is to run the 0.13upgrade command to generate the correct required_providers configuration.	6 years ago
Alisdair McDiarmid	82ebbf9a23	command: Add prompt & confirmation to 0.13upgrade	6 years ago
Alisdair McDiarmid	62b0cbed12	internal: Fix LookupLegacyProvider ... When looking up the namespace for a legacy provider source, we need to use the /v1/providers/-/{name}/versions endpoint. For non-HashiCorp providers, the /v1/providers/-/{name} endpoint returns a 404. This commit updates the LegacyProviderDefaultNamespace method and the mock registry servers accordingly.	6 years ago
Alisdair McDiarmid	a740b739e0	command: Change 0.13upgrade default to versions.tf ... Instead of using providers.tf as the default output file for the upgrader, we now default to versions.tf. This means that if the configuration has no `required_providers` blocks at all, or has multiple, the provider version requirements will be stored in the versions.tf file. We now also update the versions.tf file to set a `required_version` attribute in the first `terraform` block, with value ">= 0.13". This is similar to the behaviour of the 0.12upgrade command, and signals that the configuration should not be used with older versions of Terraform.	6 years ago
Alisdair McDiarmid	01a3376ead	command: Check required_version before upgrading ... If a configuration has a version constraint which prevents use with Terraform 0.13, the upgrade command should exit before making any changes.	6 years ago
Alisdair McDiarmid	ae98bd12a7	command: Rework 0.13upgrade sub-command ... This commit implements most of the intended functionality of the upgrade command for rewriting configurations. For a given module, it makes a list of all providers in use. Then it attempts to detect the source address for providers without an explicit source. Once this step is complete, the tool rewrites the relevant configuration files. This results in a single "required_providers" block for the module, with a source for each provider. Any providers for which the source cannot be detected (for example, unofficial providers) will need a source to be defined by the user. The tool writes an explanatory comment to the configuration to help with this.	6 years ago
Alisdair McDiarmid	3b0b29ef52	command: Add scaffold for 0.13upgrade command	6 years ago