Terraform: 0.12 apply output no longer displays changes performed
Terraform Version
0.12.3
Overview
Running a terraform apply with no plan file (implicit plan) no longer displays what was changed, making it impossible to audit changes in CI workflows with terraform apply -auto-approve
Example File
resource "random_id" "foo" {
byte_length = 8
}
Expected Behavior
0.11.14:
actual resource changes are displayed underneath "Creating..." line
→ TF_IN_AUTOMATION=1 terraform-0.11.14 init
Initializing provider plugins...
- Checking for available provider plugins on https://releases.hashicorp.com...
- Downloading plugin for provider "random" (2.1.2)...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.random: version = "~> 2.1"
Terraform has been successfully initialized!
→ TF_IN_AUTOMATION=1 terraform-0.11.14 apply -auto-approve
random_id.foo: Creating...
b64: "" => "<computed>"
b64_std: "" => "<computed>"
b64_url: "" => "<computed>"
byte_length: "" => "8"
dec: "" => "<computed>"
hex: "" => "<computed>"
random_id.foo: Creation complete after 0s (ID: 7Djc_JH4gek)
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Actual Behavior
0.12.3
no resource changes are displayed underneath "Creating..." line
→ TF_IN_AUTOMATION=1 terraform-0.12.3 init
Initializing the backend...
Initializing provider plugins...
- Checking for available provider plugins...
- Downloading plugin for provider "random" (terraform-providers/random) 2.1.2...
The following providers do not have any version constraints in configuration,
so the latest version was installed.
To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.
* provider.random: version = "~> 2.1"
Terraform has been successfully initialized!
→ TF_IN_AUTOMATION=1 terraform-0.12.3 apply -auto-approve
random_id.foo: Creating...
random_id.foo: Creation complete after 0s [id=P2Awi6pw85Q]
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Steps to Reproduce
- define a resource
- apply the resource with
TF_IN_AUTOMATION=1 terraform apply -auto-approve - examine output
Additional Context
TF_IN_AUTOMATION=1
-auto-approve
References
- https://groups.google.com/forum/#!topic/terraform-tool/Za3JVt5PQfM
eedwards-sk
All 6 comments
Hi @eedwards-sk,
We made this change because previously the output of terraform apply was incredibly verbose, and we got feedback that it was too noisy and just repeating information already in the terraform plan output. Particularly now that the terraform plan output includes a full description of the resource configuration, the two together was a lot.
However, we can see here that when you use -auto-approve you don't see the plan output at all and thus are left with no information about the changes. While it could be argued that using -auto-approve indicates that you didn't actually _care_ to review the changes, we can see that it would be helpful to debug if you're using -auto-approve in development (the only place it should really be used) and something unexpected happened.
With that said, as a compromise here we should change the behavior of terraform apply -auto-approve so that it produces all the same output as terraform apply without that option, except that the interactive confirmation prompt would be replaced with a note about -auto-approve, perhaps like this:
Terraform will automatically apply the above changes because you used
the -auto-approve option.
That way all the same information would be present in both cases, and Terraform would be more explicit that running terraform apply -auto-approve is essentially the same as running terraform plan -out=tfplan && terraform apply tfplan, by making the output in these cases almost identical too.
teamterraform
on 16 Jul 2019
Thanks for the response.
we can see that it would be helpful to debug if you're using -auto-approve in development (the only place it should really be used) and something unexpected happened.
My use case is for production, where seeing the changes isn't just for debugging, it's also for historical record. I don't see why running a plan, generating a plan file, and then apply ing that plan file is any better for my use case than running apply -auto-approve.
If apply runs an implicit plan operation that will fail out the same way a plan would when ran separately, there is no benefit to me running them separately, and in fact it only takes more time.
apply -auto-approve allows me to quickly push a change through when time matters (CI)
I'm fully aware of the risks of the command, which is why it's only used in highly-scoped projects that manage only a few select resources (and since configuration comes from source code, we review the changes there, not the changes that will happen once deployed).
Things like creating a database go through a plan-approve-apply lifecycle. Updating the task definition for an ECS container, where the only change is the "image" field, does not require planning and approval.
I can certainly refactor my tooling to instead run a plan->apply (without approval), but at this point I would only do that if terraform made it clear that apply -auto-approve is an "unsupported" or "deprecated" apply method.
eedwards-sk
on 16 Jul 2019
Probably adding a CLI-Flag to output the plan would be good for this use-case. We also saw this behaviour change in our pipeline output and added the terraform plan back for now.
Would love some -output-plan option for this.
gerl1ng
on 23 Jul 2019
We've had numerous patch releases since this issue was created. Are we going to see this functionality added back anytime soon?
eedwards-sk
on 6 Sep 2019
Two more months passed, checking to see if we're getting movement on this yet?
No milestones or projects have been assigned that I've seen.
I continue to lack context during my apply phase.
eedwards-sk
on 15 Nov 2019
I ran into the same thing (also for ECS deploys) and am using the following until the functionality is available:
terraform plan -detailed-exitcode -out tfplan
if [[ $? -eq 2 ]]; then
terraform apply tfplan
fi
danieladams456
on 19 Feb 2020
Related issues
shanmugakarna
·
3Comments
sprokopiak
·
3Comments
Seraf
·
3Comments
rjinski
·
3Comments
carl-youngblood
·
3Comments
Most helpful comment
Thanks for the response.
My use case is for production, where seeing the changes isn't just for debugging, it's also for historical record. I don't see why running a
plan, generating a plan file, and thenapplying that plan file is any better for my use case than runningapply -auto-approve.If
applyruns an implicitplanoperation that will fail out the same way aplanwould when ran separately, there is no benefit to me running them separately, and in fact it only takes more time.apply -auto-approveallows me to quickly push a change through when time matters (CI)I'm fully aware of the risks of the command, which is why it's only used in highly-scoped projects that manage only a few select resources (and since configuration comes from source code, we review the changes there, not the changes that will happen once deployed).
Things like creating a database go through a plan-approve-apply lifecycle. Updating the task definition for an ECS container, where the only change is the "image" field, does not require planning and approval.
I can certainly refactor my tooling to instead run a
plan->apply(without approval), but at this point I would only do that if terraform made it clear thatapply -auto-approveis an "unsupported" or "deprecated" apply method.