plan -detailed-exitcode -destroy return "2" when nothing to destroy

[evbo]

To reproduce using Terraform 0.11.7:

define any resource (but don't create it), then run terraform plan -detailed-exitcode -destroy

I would expect the -destroy flag to switch the context, such that -detailed-exitcode reports back what's there to destroy - not create, but it returns a 2.

Returning codes that indicate what's there to destroy (rather than create) allows my jenkins pipeline to know if it was successful at planing a destroy. Based on the current error codes, if it gets back a "2", then it thinks there's something to destroy (when there isn't). Conversely, if there were no changes (to create), this incorrectly indicates that there's nothing to destroy when there definitely can be.

It's important to plan a destroy, so I don't want to skip that step, but I will for now work around this by ignoring the return code unless it's a 1 indicating error. Would be nice though if exit codes were context-specific in terms of either creation or destruction. BTW thanks for the great tool!

[mildwonkey]

Hi @evbo,
I'd like to try and take a look at this. I need some more information to reproduce this locally, can you help out?

I created a file with the following content:

resource "random_string" "string" {
  length = 8
}

output "o" {
  value = "${random_string.string.result}"
}

And ran the following commands:

$ terraform init
[ ... ]
$ terraform plan -detailed-exitcode -destroy
[ ... ]
$ echo $?
0

Can you share an example that results in the exit code 2 like you described? I'd like to figure out what's different between our examples. Thanks!

[evbo]

Hi @mildwonkey I'll try to help reproduce this issue, and I think it might be an issue when using remote state?

I get the following output when calling a "plan" like:

terraform plan -detailed-exitcode -destroy
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

------------------------------------------------------------------------

No changes. Infrastructure is up-to-date.

This means that Terraform did not detect any differences between your
configuration and real physical resources that exist. As a result, no
actions need to be performed.

echo $?
2

The actual module I'm doing the plan on has it's own unique key in my remote state, defined like:

terraform {
  backend "s3" {
    bucket         = "bucket name"
    key            = "module_name/terraform.tfstate"
    dynamodb_table = "table name"
    region         = "the region"
    encrypt        = "true"
  }
}

I am using s3 remote state with fairly standard configuration for me "backend" module storing the state:

resource "aws_s3_bucket" "tf_store" {
  bucket = "name here"
  acl    = "private"

  versioning {
    enabled = false
  }

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default {
        sse_algorithm = "AES256"
      }
    }
  }
}

resource "aws_dynamodb_table" "tf_lock" {
  name     = "tf-state"
  hash_key = "LockID"

  // only one person can access the lock at a time
  read_capacity  = 1
  write_capacity = 1

  attribute {
    name = "LockID"
    type = "S"
  }
}

[hashibot]

Hello! 🤖

This issue relates to an older version of Terraform that is no longer in active development, and because the area of Terraform it relates to has changed significantly since the issue was opened we suspect that the issue is either fixed or that the circumstances around it have changed enough that we'd need an updated issue report in order to reproduce and address it.

If you're still seeing this or a similar issue in the latest version of Terraform, please do feel free to open a new bug report! Please be sure to include all of the information requested in the template, even if it might seem redundant with the information already shared in this issue, because the internal details relating to this problem are likely to be different in the current version of Terraform.

Thanks!

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.