Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement plan -out with cloud integration #33418

Merged
merged 9 commits into from
Jul 6, 2023

Conversation

nfagerlund
Copy link
Member

@nfagerlund nfagerlund commented Jun 23, 2023

This is it! We can use terraform plan -out my.tfplan in cloud mode to create an arbitrary number of saved plan runs, and then terraform apply my.tfplan one of the resulting plans to make it the workspace's next apply.

Because save-plan is a new attribute in the runs API, it requires an update to go-tfe — hashicorp/go-tfe#724

To smoke test this: Make sure your TFC org has been added to the saved-cloud-plans feature flag.

@nfagerlund nfagerlund changed the title Implement plan Implement plan -out with cloud integration Jun 23, 2023
@nfagerlund nfagerlund marked this pull request as ready for review June 23, 2023 00:27
Copy link
Contributor

@brandonc brandonc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So exciting to get rid of that error

internal/cloud/backend_plan.go Outdated Show resolved Hide resolved
if op.PlanOutPath != "" {
diags = diags.Append(tfdiags.Sourceless(
tfdiags.Error,
"Saving a generated plan is currently not supported",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😍

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I love it when "currently" becomes the past 😆

Copy link
Contributor

@Uk1288 Uk1288 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice! this worked smoothly for me!

One comment, I still receive the footer To perform exactly these actions, run the following command to apply... even when my plan errors out. See image below:

Screenshot 2023-06-27 at 10 29 21 AM

I was thinking the apply footer would not be displayed in this case. WDYT?

@nfagerlund
Copy link
Member Author

@Uk1288 That IS odd! I also expected it to not show that... But this relates to what @sebasslash brought up, too, so let's talk tomorrow and see if we actually want to skip saving the plan at all. (If so, I figure the way to suppress the message will come out of that.)

so we don't have to remember the format version number
This displays the footer that explains what happens if you saved a plan file (or
neglected to). We never used to show it, because we didn't support -out.
This was wrong when err != nil and saveErr == nil.
On further consideration, this is a nonsensical thing to do, and it doesn't
match the behavior of plain CLI!

Additionally, skip next steps message on failure.
@vercel vercel bot requested a deployment to Preview June 29, 2023 18:02 Abandoned
@vercel vercel bot requested a deployment to Preview June 29, 2023 18:02 Abandoned
Copy link
Contributor

@sebasslash sebasslash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-wise this looks awesome to me 👍. I have not smoke tested yet so I won't directly approve.

One minor thing: would it be possible to unit test instances where the run errors but the plan should be saved? I imagine with the mock API that might not be trivial to create. Or perhaps this might be better suited for an integration test.

internal/cloud/backend_plan.go Outdated Show resolved Hide resolved
internal/cloud/backend_plan.go Outdated Show resolved Hide resolved
Copy link
Contributor

@brandonc brandonc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some minor feedback on return values

// If the run errored, exit before checking whether to save a plan file
run, err := b.plan(stopCtx, cancelCtx, op, w)
if err != nil {
return run, err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we return an error, we should be make it clear that we are returning nil, err, I think.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, yeah, all right

op.View.PlanNextStep(op.PlanOutPath, "")
}

return run, err
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same suggestion here. I think we want to be clear about returning nil if we are also returning an error.

Copy link
Contributor

@sebasslash sebasslash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Smoke tested and most things are looking good. I've got some concerns (and are mostly on the TFC side of things):

What worked:

  • Specifying -out creates a JSON artifact representing the remote plan in my root dir
  • Specifying the created artifact in terraform apply indeed triggers a run
  • Can't re-apply a saved plan
  • Error is handled when specified plan file doesn't exist, and when the artifact is modified in some way with an incorrect value.

What did not work:

  • The state version was not processed correctly (no workspace resources/outputs showing). If I try to run a regular apply afterwards, I get some 'drift detected (delete)', and Terraform taints the resources in my config.
  • I might be wrong here, but I expected the run to show up on the UI upon running terraform plan -out. It only appeared once the plan was applied. This was quite confusing if the run is the first on a workspace.
  • I expected the plan file to be deleted once applied since it can no longer be used.

Comment on lines +100 to +102
if err != nil {
return nil, err
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we reach this block, run should not be nil. Wondering if there might be unintended consequences with not returning the run at this point.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's okay — the caller really needs to assume that the primary value is NOT safe to mess with if they got an err, and that's kind of just a limitation of having exactly two return values for failure handling.

Copy link
Contributor

@sebasslash sebasslash left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've discussed with @nfagerlund internally and several of the TFC-related issues I ran into turned out to be issues with my local dev or already planned work. :shipit:

On the matter of removing the remote plan artifact on your FS upon applying the saved plan, it is expected to match the existing OSS behavior which does not delete the plan binary.

@nfagerlund
Copy link
Member Author

(For posterity: the issue with the plan not appearing in the runs list is a pure UI bug in TFC: some slapstick around the run list taking its ball and going home if there's no "current" run, which is the case if you've never done an eager run or fully confirmed a saved plan run. Addressed in the UI PR!)

@nfagerlund nfagerlund merged commit dda00c8 into cli-team/saved-cloud-plans Jul 6, 2023
@nfagerlund nfagerlund deleted the nf/jun23-save-a-plan branch July 6, 2023 20:16
@github-actions
Copy link

github-actions bot commented Jul 6, 2023

Reminder for the merging maintainer: if this is a user-visible change, please update the changelog on the appropriate release branch.

Copy link

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 13, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants