backend/remote: Support -target on plan and apply#24834
backend/remote: Support -target on plan and apply#24834apparentlymart merged 5 commits intomasterfrom
Conversation
|
Might be worth adding a different default message when using targetAddrs here - terraform/backend/remote/backend_plan.go Line 222 in dcbd835 |
ee50f0e to
43baf8d
Compare
Codecov Report
|
43baf8d to
330641f
Compare
This includes a new TargetAddrs field on both Run and RunCreateOptions which we'll use to send resource addresses that were specified using -target on the CLI command line when using the remote backend. There were some unrelated upstream breaking changes compared to the last version we had vendored, so this commit also includes some changes to the backend/remote package to work with this new API, which now requires the remote backend to be aware of the remote system's opaque workspace id.
Previously we did not allow -target to be used with the remote backend because there was no way to send the targets to Terraform Cloud/Enterprise via the API. There is now an attribute in the request for creating a plan that allows us to send target addresses, so we'll remove that restriction and copy the given target addresses into the API request.
330641f to
650a272
Compare
bbc4a01 to
d9d4b6b
Compare
backend/remote/backend_apply.go
Outdated
| } | ||
|
|
||
| if len(op.Targets) != 0 { | ||
| currentAPIVersion, err := version.NewVersion(b.client.RemoteAPIVersion()) |
There was a problem hiding this comment.
@radditude maybe we should include a comment here noting that RemoteAPIVersion returns an invalid version number (empty string) for versions before 2.3, to help a future reader understand why a parse error is treated the same as a version mismatch below...
d9d4b6b to
0eea4e7
Compare
The remote server might choose to skip running cost estimation for a targeted plan, in which case we'll show a note about it in the UI and then move on, rather than returning an "invalid status" error. This new status isn't yet available in the go-tfe library as a constant, so for now we have the string directly in our switch statement. This is a pragmatic way to expedite getting the "critical path" of this feature in place without blocking on changes to ancillary codebases. A subsequent commit should switch this over to tfe.CostEstimateSkippedDueToTargeting once that's available in a go-tfe release.
| b.CLI.Output(b.Colorize().Color("Waiting for cost estimate to complete..." + elapsed + "\n")) | ||
| } | ||
| continue | ||
| case "skipped_due_to_targeting": // TEMP: not available in the go-tfe library yet; will update this to be tfe.CostEstimateSkippedDueToTargeting once that's available. |
There was a problem hiding this comment.
We're planning to submit this tfe.CostEstimateSkippedDueToTargeting upstream to go-tfe asynchronously from getting this PR in. Will update this to use the named constant in a subsequent PR once it's included in a go-tfe release.
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
This is the local-CLI portion of allowing
-targetto be used with remote operations.-targetaddresses given on local CLI are copied into the API request to create a run, which Terraform Cloud will then in turn pass back into-targetoptions for the remote Terraform CLI process.Old versions of Terraform Cloud/Enterprise that lack support for this new attribute would silently ignore the
target-addrsattribute and run an untargeted plan, so this also includes some version-sniffing so we can continue to return an error for an older server. The design ofgo-tfe's versioning API combined with the mocking approach of the remote backend makes it annoyingly messy to unit test the case where-targetisn't available on the server yet, so as a pragmatic compromise we elected to just test that part manually, with the rationale that the "not supported" situation will go away in the not-too-distant future as new versions of Terraform Cloud and Terraform Enterprise roll out, so that's not a long-term maintenance concern.This also includes some unrelated updates to
backend/remoteto deal with some upstream breaking changes in the hashicorp/go-tfe library, which now requires use of the server's opaque workspace ID rather than the (organization-name, workspace-name) pair it expected before.