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

Add terraform configuration to require a plan file when applying #15263

Closed
kamalmarhubi opened this issue Jun 12, 2017 · 7 comments
Closed

Add terraform configuration to require a plan file when applying #15263

kamalmarhubi opened this issue Jun 12, 2017 · 7 comments

Comments

@kamalmarhubi
Copy link

At my workplace, we prefer running terraform plan -out somefile before then running terraform apply somefile. However, the default state is that a bare terraform apply will go through. It would be ideal to forbid terraform apply without a plan.

This could go in the terraform configuration block so that we can include it in our repo and require it across all developers. Perhaps something like

terraform {
  require_plan_file = true
}

Terraform Version

Terraform v0.9.4

Expected Behavior

I can make terraform apply without a plan issue an error or warning.

Actual Behavior

I cannot make terraform apply without a plan issue an error or warning.

Steps to Reproduce

N/A

@sethvargo
Copy link
Contributor

Terraform 0.10 has this behavior, just slightly different. Could you take a look at the upgrade guide and see if the 0.10 behavior would satisfy you? At this time, 0.10 is not yet released.

https://github.com/hashicorp/terraform/blob/master/website/source/upgrade-guides/0-10.html.markdown

@apparentlymart
Copy link
Contributor

Ahh yes, thanks for pointing that out, Seth.

The behavior Seth is pointing at in 0.10 is to support an interactive mode for terraform apply which will show the plan and then prompt for approval before continuing. The upgrade guide has been updated a bit pre-emptively here since that particular change (#7251) hasn't landed in master yet, but you can see there what the intended behavior is.

I expect that as of 0.10 this won't address what you want here because auto-approving will still be the default. However, in future we plan to make it default to false, specifically to avoid the problem you describe here of accidentally applying changes blindly, while retaining the convenience of using terraform apply. We're just doing this in two steps to give maintainers of automation around Terraform a chance to get their tools ready to deal with this before we make it the default.

@kamalmarhubi
Copy link
Author

Ah this is cool. Any chance we can have a config setting somewhere to set -auto-approve as default ahead of schedule?

@apparentlymart
Copy link
Contributor

I can see where you are coming from with that, but I don't really want to go there just because it creates more surface area for us to test, and another thing to deprecate and phase out, etc.

I'm hoping we can get the default changed after not too long, so I'd ask for patience here while we get through this deprecation cycle and then we can settle into a nice end state.

@ngenator
Copy link

@kamalmarhubi You can get the behavior of "always disable auto-approval" by setting an environment variable to pass the flag to apply whenever it is used: export TF_CLI_ARGS_apply=-auto-approve=false I don't know what the implications are when adding that to an apply that specifies a plan file, however.

@apparentlymart
Copy link
Contributor

Hi all!

In Terraform 0.11.0 the default for terraform apply (with no plan argument) was changed to prompt for interactive approval by default. With that in place, we're now recommending the interactive form of terraform apply as the primary workflow for directly running Terraform from CLI, with terraform plan -out=... now being primarily for running Terraform in automation.

I think this addresses the original motivation for this issue, albeit in a different way than was originally suggested, so I'm going to close this. Thanks for your patience while we worked through the deprecation cycle for the old workflow.

@ghost
Copy link

ghost commented Apr 6, 2020

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.

@ghost ghost locked and limited conversation to collaborators Apr 6, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants