547 Commits (efafadbe5edbfd8faa250aa1eaed46fbb2d52ee2)

Author	SHA1	Message	Date
Kristin Laemmert	e3416124cc	addrs: replace "Type string" with "Type Provider" in ProviderConfig ... * huge change to weave new addrs.Provider into addrs.ProviderConfig * terraform: do not include an empty string in the returned Providers / Provisioners - Fixed a minor bug where results included an extra empty string	6 years ago
Martin Atkins	30bf83cdeb	helper/logging: Bring the LevelFilter into our own codebase ... In order to make this work reasonably we can't avoid using some funny heuristics, which are somewhat reasonable to apply within the context of Terraform itself but would not be good to add to the general "logutils". Specifically, this is adding the additional heuristic that lines starting with spaces are continuation lines and so should inherit the log level of the most recent non-continuation line.	6 years ago
Kristin Laemmert	9891d0354a	providers: use addrs.Provider as map keys for provider.Factory (#23548) ... * terraform/context: use new addrs.Provider as map key in provider factories * added NewLegacyProviderType and LegacyString funcs to make it explicit that these are temporary placeholders This PR introduces a new concept, provider fully-qualified name (FQN), encapsulated by the `addrs.Provider` struct.	6 years ago
Martin Atkins	6db3cf8e5b	vendor: upgrade Azure SDK and Azure/go-autorest ... This involves some minor changes to the "azure" backend code to account for upstream breaking changes.	6 years ago
James Bardin	6caa5d23e2	fix diagnostics handling ... Located all non-test paths where a Diagnostic type was assigned to an error variable.	7 years ago
Robert Tillery	af77d1d22c	backend/remote: Filter environment variables when loading context (#23358) ... * backend/remote: Filter environment variables when loading context Following up on #23122, the remote system (Terraform Cloud or Enterprise) serves environment and Terraform variables using a single type of object. We only should load Terraform variables into the Terraform context. Fixes https://github.com/hashicorp/terraform/issues/23283.	7 years ago
Lars Lehtonen	1219acf467	backend/atlas: fix use of T.Fatal() inside goroutine	7 years ago
Joaquín Fernández Campo	d2bc7c25b9	backend/artifactory: Honor HTTP_PROXY and HTTPS_PROXY environment variables	7 years ago
Martin Atkins	9a62ab3014	command: "terraform show" renders plans like "terraform plan" ... During the Terraform 0.12 work we briefly had a partial update of the old Terraform 0.11 (and prior) diff renderer that could work with the new plan structure, but could produce only partial results. We switched to the new plan implementation prior to release, but the "terraform show" command was left calling into the old partial implementation, and thus produced incomplete results when rendering a saved plan. Here we instead use the plan rendering logic from the "terraform plan" command, making the output of both identical. Unfortunately, due to the current backend architecture that logic lives inside the local backend package, and it contains some business logic around state and schema wrangling that would make it inappropriate to move wholesale into the command/format package. To allow for a low-risk fix to the "terraform show" output, here we avoid some more severe refactoring by just exporting the rendering functionality in a way that allows the "terraform show" command to call into it. In future we'd like to move all of the code that actually writes to the output into the "command" package so that the roles of these components are better segregated, but that is too big a change to block fixing this issue.	7 years ago
He Guimin	bfae627112	add a new field ecs_role_name to support more scenario	7 years ago
Martin Atkins	8f27409007	backend/remote: Support HCL variable values in local operations ... For remote operations, the remote system (Terraform Cloud or Enterprise) writes the stored variable values into a .tfvars file before running the remote copy of Terraform CLI. By contrast, for operations that only run locally (like "terraform import"), we fetch the stored variable values from the remote API and add them into the set of available variables directly as part of creating the local execution context. Previously in the local-only case we were assuming that all stored variables are strings, which isn't true: the Terraform Cloud/Enterprise UI allows users to specify that a particular variable is given as an HCL expression, in which case the correct behavior is to parse and evaluate the expression to obtain the final value. This also addresses a related issue whereby previously we were forcing all sensitive values to be represented as a special string "<sensitive>". That leads to type checking errors for any variable specified as having a type other than string, so instead here we use an unknown value as a placeholder so that type checking can pass. Unpopulated sensitive values may cause errors downstream though, so we'll also produce a warning for each of them to let the user know that those variables are not available for local-only operations. It's a warning rather than an error so that operations that don't rely on known values for those variables can potentially complete successfully. This can potentially produce errors in situations that would've been silently ignored before: if a remote variable is marked as being HCL syntax but is not valid HCL then it will now fail parsing at this early stage, whereas previously it would've just passed through as a string and failed only if the operation tried to interpret it as a non-string. However, in situations like these the remote operations like "terraform plan" would already have been failing with an equivalent error message anyway, so it's unlikely that any existing workspace that is being used for routine operations would have such a broken configuration.	7 years ago
Martin Atkins	9f9f22091e	backend/remote: Unlock workspace if Context fails ... Previously any error case in the Context method would cause us to leave the remote workspace locked on exit, requiring manual action to unlock it.	7 years ago
Martin Atkins	b10f058cbb	backend/remote: Only load variables if we're going to use them ... Some commands don't use variables at all or use them in a way that doesn't require them to all be fully valid and consistent. For those, we don't want to fetch variable values from the remote system and try to validate them because that's wasteful and likely to cause unnecessary error messages. Furthermore, the variables endpoint in Terraform Cloud and Enterprise only works for personal access tokens, so it's important that we don't assume we can _always_ use it. If we do, then we'll see problems when commands are run inside Terraform Cloud and Enterprise remote execution contexts, where the variables map always comes back as empty.	7 years ago
Martin Atkins	a8d01e3940	backend/remote: Report invalid variables only remotely ... The remote backend uses backend.ParseVariableValues locally only to decide if the user seems to be trying to use -var or -var-file options locally, since those are not supported for the remote backend. Other than detecting those, we don't actually have any need to use the results of backend.ParseVariableValues, and so it's better for us to ignore any errors it produces itself and prefer to just send a potentially-invalid request to the remote system and let the remote system be responsible for validating it. This then avoids issues caused by the fact that when remote operations are in use the local system does not have all of the required context: it can't see which environment variables will be set in the remote execution context nor which variables the remote system will set using its own generated -var-file based on the workspace stored variables.	7 years ago
Radek Simko	7860f55e4f	Version tools per Go convention under tools.go	7 years ago
Pam Selle	a5f2f4cbba	Update messaging for .terraformignore	7 years ago
Radek Simko	32f9722d9d	Replace import paths & set UA string where necessary	7 years ago
Martin Atkins	8664749b59	backend: Allow certain commands to opt out of required variable checks ... Terraform Core expects all variables to be set, but for some ancillary commands it's fine for them to just be set to placeholders because the variable values themselves are not key to the command's functionality as long as the terraform.Context is still self-consistent. For such commands, rather than prompting for interactive input for required variables we'll just stub them out as unknowns to reflect that they are placeholders for values that a user would normally need to provide. This achieves a similar effect to how these commands behaved before, but without the tendency to produce a slightly invalid terraform.Context that would fail in strange ways when asked to run certain operations.	7 years ago
Martin Atkins	e21f0fa61e	backend/local: Handle interactive prompts for variables in UI layer ... During the 0.12 work we intended to move all of the variable value collection logic into the UI layer (command package and backend packages) and present them all together as a unified data structure to Terraform Core. However, we didn't quite succeed because the interactive prompts for unset required variables were still being handled _after_ calling into Terraform Core. Here we complete that earlier work by moving the interactive prompts for variables out into the UI layer too, thus allowing us to handle final validation of the variables all together in one place and do so in the UI layer where we have the most context still available about where all of these values are coming from. This allows us to fix a problem where previously disabling input with -input=false on the command line could cause Terraform Core to receive an incomplete set of variable values, and fail with a bad error message. As a consequence of this refactoring, the scope of terraform.Context.Input is now reduced to only gathering provider configuration arguments. Ideally that too would move into the UI layer somehow in a future commit, but that's a problem for another day.	7 years ago
Martin Atkins	39e609d5fd	vendor: switch to HCL 2.0 in the HCL repository ... Previously we were using the experimental HCL 2 repository, but now we'll shift over to the v2 import path within the main HCL repository as part of actually releasing HCL 2.0 as stable. This is a mechanical search/replace to the new import paths. It also switches to the v2.0.0 release of HCL, which includes some new code that Terraform didn't previously have but should not change any behavior that matters for Terraform's purposes. For the moment the experimental HCL2 repository is still an indirect dependency via terraform-config-inspect, so it remains in our go.sum and vendor directories for the moment. Because terraform-config-inspect uses a much smaller subset of the HCL2 functionality, this does still manage to prune the vendor directory a little. A subsequent release of terraform-config-inspect should allow us to completely remove that old repository in a future commit.	7 years ago
Paul Thrasher	f2ef8ef317	slow down tfce polling to 1s ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	4e308ef362	typos. some code, some text. ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	d2eaffabea	vendor latest go-tfe ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	d3fc3dee6e	clean up go mod for go-tfe ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	e2831b3d1e	tfce test additions ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	bc2d888b7b	update to go-tfe 0.3.23 ... this fixes the attr types Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Paul Thrasher	39817ac476	cost estimation status polling ... Properly wait for cost estimation to finish running before outputting the results. Waits 500 milliseconds between checks, rather than backing off exponentially, because we are not in a run queue. At the point we're waiting, we expect cost estimation to be run in a timely manner.	7 years ago
Paul Thrasher	979bba0f32	tfce mock fix ... Signed-off-by: Paul Thrasher <pthrasher@hashicorp.com>	7 years ago
Kristin Laemmert	006ef022e6	Merge pull request #22918 from hashicorp/mildwonkey/to-e2e-or-not-e2e ... Sundry fixes to e2e tests	7 years ago
Kristin Laemmert	68dfc3046d	backend/remote-state: etcdv3, oss, and manta acc tests should fail ... faster The acceptance tests for etcdv3, oss and manta were not validating required env variablea, chosing to assume that if one was running acceptance tests they had already configured the credentials. It was not always clear if this was a bug in the tests or the provider, so I opted to make the tests fail faster when required attributes were unset (or "").	7 years ago
Kristin Laemmert	5300f85a79	backend/manta: fix panic when insecure_skip_tls_verify was not set ... The DefaultFunc for insecure_skip_tls_verify was sending an empty string instead of a bool. Fixes to default to `false`.	7 years ago
Paddy	9b24ef7870	Merge pull request #21772 from luis-silva/21680/GCS_OAUTH ... Add OAuth2 token support for GCS backend	7 years ago
Martin Atkins	7e29b9b5d4	core: Warn when creating and applying with -target ... The documentation for the -target option warns that it's intended for exceptional circumstances only and not for routine use, but that's not a very prominent location for that warning and so some users miss it. Here we make the warning more prominent by including it directly in the Terraform output when -target is in use. We first warn during planning that the plan might be incomplete, and then warn again after apply concludes and direct the user to run "terraform plan" to make sure that there are no further changes outstanding. The latter message is intended to reinforce that -target should only be a one-off operation and that you should always run without it soon after to ensure that the workspace is left in a consistent, converged state.	7 years ago
Luis Silva	9ae8eca55d	Merge branch 'master' into 21680/GCS_OAUTH	7 years ago
yanndegat	be5280e4e1	remote-state/pg: add option to skip schema creation (#21607) ... * add `skip_schema_creation` option * add sanity check to avoid situations where postgres users hasn't been granted the "CREATE SCHEMA" right closes #21604 Signed-off-by: yann degat <yann@2kmail.net>	7 years ago
yuanye	b69c0b4199	oss backend support profile	7 years ago
James Bardin	10d94fb764	Merge pull request #21967 from williams-brian/SSE-C_Remote_State ... Add support for SSE-C to S3 backend	7 years ago
Radek Simko	f3357aad45	vendor: Downgrade Azure dependencies ... This is to allow Terraform providers to upgrade to at least one more minor version of the plugin SDK without major UX hiccups. This concludes (unsuccessful) experiments involving upgrades to SDK with https://github.com/Azure/go-autorest/pull/455 Even with that patch all providers still experience broken UX as described in https://github.com/hashicorp/terraform/pull/22490 This downgrade reduces the uncomfort to only a handful of providers from >100s. The affected providers more or less directly depend on Azure SDK(s), which is ~8. Affected providers practically cannot consume Terraform Plugin SDK with this patch (downgraded Azure SDKs) and can just wait for extracted Terraform Plugin SDK which is planned to be released soon. This reverts the following PRs: - https://github.com/hashicorp/terraform/pull/22247 - https://github.com/hashicorp/terraform/pull/22248 - https://github.com/hashicorp/terraform/pull/22524 - https://github.com/hashicorp/terraform/pull/22525 and it is otherwise result of the following commands ``` go get github.com/Azure/azure-sdk-for-go@v21.3.0 go get github.com/hashicorp/go-azure-helpers@166dfd221bb2 go mod tidy ```	7 years ago
Radek Simko	dee450cf8c	vendor: Bump go-azure-helpers to 0.7.0	7 years ago
Roberto Jung Drebes	b459a92575	backend/gcs: Use new endpoints for Google OAuth ... This is a consequence of googleapis/google-cloud-common#260.	7 years ago
Pam Selle	9631e4c73d	Merge pull request #20571 from sergkondr/fix_misspelling ... fix misspelling	7 years ago
Alex Pilon	4bf43efcfd	move hcl2shim package to configs	7 years ago
Chris Marchesi	d43fc71135	modules: update go-azure-helpers to v0.5.0 ... To help address the issues posed on #22087 and #22085.	7 years ago
He Guimin	a490dfa495	backend/oss: Support for assume role config	7 years ago
Kristin Laemmert	412d459292	backend/remote: remove milseading contents from error message (#22148) ... Previously, terraform was returning a potentially-misleading error message in response to anything other than a 404 from the b.client.Workspaces.Read operation. This PR simplifies Terraform's error message with the intent of encouraging those who encounter it to focus on the error message returned from the tfe client. The added test is odd, and a bit hacky, and possibly overkill.	7 years ago
Kristin Laemmert	190ef537ec	backend/remote: notify users when uploading something other than cwd ... When a TFC workspace is configured without a VCS root, and with a working directory, and a user is running `terraform init` from that same directory, TFC uploads the entire configuration directory, not only the user's cwd. This is not obvious to the user, so we are adding a descriptive message explaining what is being uploaded, and why.	7 years ago
Kristin Laemmert	89eeaed0a0	[WIP] backend/enhanced: start with absolute configuration path (#22096) ... * backend/enhanced: start with absolute config path We recently started normalizing the config path before all "command" operations, which was necessary for consistency but had unexpected consequences for remote backend operations, specifically when a vcs root with a working directory are configured. This PR de-normalizes the path back to an absolute path. * Check the error and add a test It turned out all required logic was already present, so I just needed to add a test for this specific use case.	7 years ago
Pam Selle	23a187d85d	Merge pull request #21739 from hasheddan/s3-backend-comment-typo ... s3 backend: minor typo in putMD5 comment	7 years ago
Colin Fowler	cd7bfba141	rebased to terraform master branch	7 years ago
Brian Williams	5e3c3bafb8	Add support for SSE-C to S3 backend ... These changes add support for encrypting terraform remote-state in S3 using customer-supplied encryption keys (SSE-C).	7 years ago