My team and I use the Spacelift stack dependencies to order the execution of related runs but we also try to take advantage of the dependency references to map outputs to inputs of different stacks. We are coming across an issue where when we try and destroy the stack using the stack destructor it produces the following error.
module.ecs-cluster-stack.spacelift_stack_destructor.this: Destroying... [id=destructor-1706552961]
╷
│ Error: could not delete stack test-ecs-cluster-us-east-1: can't delete stack when it has dependencies; please delete them first
I think that if dependency references goal is to provide i/o between dependent stacks then they should be allowed to exist while the resources are being destroyed.
Here is the current implementation of the stack destructor and dependencies.
resource "spacelift_stack_destructor" "this" {
depends_on = [
# Adding the following dependencies to ensure that the tracked resources are
# destroyed first before the following are destroyed.
spacelift_aws_integration_attachment.this,
spacelift_context_attachment.this,
spacelift_environment_variable.this,
spacelift_policy_attachment.this,
spacelift_stack.this,
spacelift_stack_dependency.this,
spacelift_stack_dependency_reference.this,
]
stack_id = spacelift_stack.this.id
}
...
resource "spacelift_stack_dependency" "this" {
count = local.number_of_dependencies
stack_id = spacelift_stack.this.id
depends_on_stack_id = local.depends_on_stack_ids[count.index]
}
resource "spacelift_stack_dependency_reference" "this" {
count = local.number_of_references
stack_dependency_id = local.dependency_mappings[count.index].stack_dependency_id
input_name = local.dependency_mappings[count.index].input_name
output_name = local.dependency_mappings[count.index].output_name
}
@Cwagne17, thank you for submitting the issue. We have fixed a bug that prevented the deletions in your scenario. Your code should work without issues.
My team and I use the Spacelift stack dependencies to order the execution of related runs but we also try to take advantage of the dependency references to map outputs to inputs of different stacks. We are coming across an issue where when we try and destroy the stack using the stack destructor it produces the following error.
I understand why the error is being produced. Because a stack cannot be destroyed because "A stack cannot be deleted if it has upstream or downstream dependencies. If you want to delete a stack, you need to delete all of its dependencies first." However, if you must destroy the dependency references first (causing an error on the destroy due to null variables), what is the reasoning of having dependency references in the first place?
I think that if dependency references goal is to provide i/o between dependent stacks then they should be allowed to exist while the resources are being destroyed.
Here is the current implementation of the stack destructor and dependencies.