You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
locals {
msg_creation = "I should be shown at creation-time"
msg_destruction = "I should be shown at destruction-time"
}
resource "null_resource" "myresource" {
provisioner "local-exec" {
command = "echo ${local.msg_creation}"
}
provisioner "local-exec" {
command = "echo ${local.msg_destruction}"
when = "destroy"
}
}
Expected Behavior
Doing a targeted destroy of myresource should execute the destroy-time provisioner, and then remove the resource from the state.
Actual Behavior
Invoking terraform destroy --target null_resource.myresource --force prints out a possibly faulty error message:
null_resource.myresource: Refreshing state... (ID: 95776629882402507)
null_resource.myresource: Destroying... (ID: 95776629882402507)
null_resource.myresource: Provisioning with 'local-exec'...
Error: Error applying plan:
1 error(s) occurred:
* null_resource.myresource (destroy): 1 error(s) occurred:
* local-exec provisioner command must be a non-empty string
Terraform does not automatically rollback in the face of errors.
Instead, your Terraform state file has been partially updated with
any resources that successfully completed. Please address the error
above and apply again to incrementally change your infrastructure.
It's worth noting that this error is not printed out when doing a targetless destroy, e.g. terraform destroy --force. Also, a targeted apply does not incur in any problems.
The workaround i used to overcome this problem might be useful in identifying the cause: to make the above steps work, I added the variable that appears in the destroy-time command into the creation-time provisioner block, as a comment.
Thus, the following configuration ensures that the terraform destroy --target null_resource.myresource --force works as well (notice the commented variable, in the creation-time provisioner command):
locals {
msg_creation = "I should be shown at creation-time"
msg_destruction = "I should be shown at destruction-time"
}
resource "null_resource" "myresource" {
provisioner "local-exec" {
command = "echo ${local.msg_creation} #${local.msg_destruction}"
}
provisioner "local-exec" {
command = "echo ${local.msg_destruction}"
when = "destroy"
}
}
The text was updated successfully, but these errors were encountered:
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
locked and limited conversation to collaborators
Apr 5, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Terraform Version
Terraform Configuration Files
Expected Behavior
Doing a targeted destroy of
myresource
should execute the destroy-time provisioner, and then remove the resource from the state.Actual Behavior
Invoking
terraform destroy --target null_resource.myresource --force
prints out a possibly faulty error message:It's worth noting that this error is not printed out when doing a targetless destroy, e.g.
terraform destroy --force
. Also, a targeted apply does not incur in any problems.Steps to Reproduce
Given the above config:
terraform init
terraform apply --auto-approve
terraform destroy --target null_resource.myresource --force
Found workaround
The workaround i used to overcome this problem might be useful in identifying the cause: to make the above steps work, I added the variable that appears in the destroy-time command into the creation-time provisioner block, as a comment.
Thus, the following configuration ensures that the
terraform destroy --target null_resource.myresource --force
works as well (notice the commented variable, in the creation-time provisioner command):The text was updated successfully, but these errors were encountered: