0.12 apply output no longer displays changes performed

[eedwards-sk]

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

1. define a resource
2. apply the resource with TF_IN_AUTOMATION=1 terraform apply -auto-approve
3. examine output

Additional Context

TF_IN_AUTOMATION=1
-auto-approve

References

• https://groups.google.com/forum/#!topic/terraform-tool/Za3JVt5PQfM

[teamterraform]

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.

[eedwards-sk]

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.

[gerl1ng]

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.

[eedwards-sk]

We've had numerous patch releases since this issue was created. Are we going to see this functionality added back anytime soon?

[eedwards-sk]

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.

[danieladams456]

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

[vikas027]

Hey guys,

Not ideal but here is a hack :)

❯ echo yes |  terraform apply

[NMFR]

Hello,

I have a use case in terraform v0.14.11 where terraform plan shows a lot of changes with (known after apply). This is due to resources using ids or depending on other resources that will actual be changed. The problem is we can not know at plan time if the (known after apply) changes will happen or not (read this for more details).

Since terraform apply does not show detailed changes it is hard to track what (known after apply) changes were actually an no op or were real changes. If terraform apply would give detailed output we could apply the changes in a development or staging environment for example to gain awareness on the actual changes.

I don't think this issue is specific to -auto-approve, i think terraform apply should have a flag (--detailed-changes?) to print detailed changes information (similar to what terraform plan shows). This is not only is useful for audit / historic data reasons but also for debugging / actual changes awareness (my current use case).

[danieladams456]

It seems that (at least by 1.4.0, but noticed in 1.3 as well) terraform apply -auto-approve shows the diff, even with the following variables set.

export TF_INPUT=false
export TF_IN_AUTOMATION=true
export TF_CLI_ARGS="-no-color"