spacelift_stack_dependency skips dependent stack run

[BryanFauble]

Background:

I have 3 stacks defined within Spacelift:

1. Stack A (Administrative stack) which is deploying out the related spacelift resources including new Modules to the Terraform registry
2. Stack B: Deploying an initial set of cloud infrastructure required for deploying applications to a kubernetes cluster
3. Stack C: Which is deploying applications to a kubernetes cluster

I have stack dependencies setup such that:

Stack C Depends on [Stack A and Stack B] Stack B Depends on [Stack A]

In addition, both Stack B and Stack C have "Additional project globs" that are pointing to deployments/ directory. I am using this parent deployments directory to pass down configuration from a central file.

What I am trying to accomplish:

Since I am using the private Terraform registry, I need to ensure that any new module versions I use within Stack C or Stack B exist before I use them. This is why I have a stack dependency on Stack A (Admin stack). The Admin stack needs to run first and create the module within the Terraform registry.

Problem:

1. Stack A is run first and correctly creates the new Terraform module versions
2. Stack B is run and finds no changes are required in the planning stage
3. Stack C is SKIPPED because This run has dependency references (...) which have not changed since the last run

Stack C in this case should have run because there were changes in the Project root that the spacelift stack is pointing to.

Pointers to the real code where I am encountering this:

1. Stack A (Administrative stack): https://github.com/Sage-Bionetworks-Workflows/eks-stack/blob/9b11a70060c7986fdbaad9ceadd1c43d245eca86/main.tf#L16-L36
2. Stack B (Cloud infra): https://github.com/Sage-Bionetworks-Workflows/eks-stack/blob/9b11a70060c7986fdbaad9ceadd1c43d245eca86/deployments/spacelift/dpe-k8s/main.tf#L38-L61
3. Stack C (Kubernetes cluster resources): https://github.com/Sage-Bionetworks-Workflows/eks-stack/blob/9b11a70060c7986fdbaad9ceadd1c43d245eca86/deployments/spacelift/dpe-k8s/main.tf#L72-L95
4. Dependency for Stack B and Stack C on Stack A: https://github.com/Sage-Bionetworks-Workflows/eks-stack/blob/9b11a70060c7986fdbaad9ceadd1c43d245eca86/deployments/spacelift/dpe-k8s/main.tf#L114-L122

What I would like to happen, and the ask of this issue:

Rather than a stack dependency I would rather want to use the same concept of the terraform depends_on here. Where Stack B and Stack C depend on Stack A. Where if Stack A, B, and C all have changes that need to be triggered, Stack B and Stack C will not be triggered until Stack A has finished. I do not want it to depend on a change in environment variables as there is state (New Terraform modules in the terraform registry) that is changing outside of what is getting passed down into the child stacks.

If the description of this makes sense is there a suggestion on how to accomplish this, or if needed, would you like additional context?

[peterdeme]

@BryanFauble wouldn't the trigger always flag solve your problem?

resource "spacelift_stack_dependency" "dependency-on-admin-stack" {
  for_each = {
    k8s-stack             = spacelift_stack.k8s-stack,
    k8s-stack-deployments = spacelift_stack.k8s-stack-deployments
  }

  stack_id            = each.value.id
  depends_on_stack_id = var.admin_stack_id
  trigger_always      = true
}

[BryanFauble]

Thanks for the comment @peterdeme

From these docs:

1. https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs/resources/stack_dependency_reference
2. https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs/resources/stack_dependency

It looks like the trigger_always exists on stack_dependency_reference, but not stack_dependency. That seems a bit counter-intuitive to me because a stack_dependency_reference relates to a single value being passed from a parent -> child stack.

If it really does exist on spacelift_stack_dependency then the docs are out of date. To me that seems a bit more logical for it to exist on this resource, then it would be true to say:

• "I am dependent on this parent. Regardless of what stack_dependency_reference's it has, I still want to always run the child stack".

[peterdeme]

@BryanFauble you have a good point, this was a slight oversight on our side.

[BryanFauble]

@peterdeme With the current implementation would trigger_always need to exist on at least 1, or all of stack_dependency_reference resources?

[peterdeme]

@BryanFauble one is enough

[BryanFauble]

Great. I'll make that change on my side. Feel free to close this out, or keep it open if you wanted something to base a schema change on.