depends_on and stack ordering detection not working correctly

gwvandesteeg commented 1 year ago

Checklist

[X] Upgrade Terraspace: Are you using the latest version of Terraspace? This allows Terraspace to fix issues fast. There's an Upgrading Guide: https://terraspace.cloud/docs/misc/upgrading/
[X] Reproducibility: Are you reporting a bug others will be able to reproduce and not asking a question. If you're unsure or want to ask a question, do so on https://community.boltops.com
[X] Code sample: Have you put together a code sample to reproduce the issue and make it available? Code samples help speed up fixes dramatically. If it's an easily reproducible issue, then code samples are not needed. If you're unsure, please include a code sample.

My Environment

Software	Version
Operating System	Ubuntu 22.04LTS
Terraform	1.3.7
Terraspace	2.2.6
Ruby	ruby 3.0.3p157 (2021-11-24 revision 3fb7d2cadc) [x86_64-linux]

Expected Behaviour

Expected behaviour is for the defaults stack to be at batch level one, and the foxpass stack to be at batch level 2 for its dependency.

Current Behavior

Two stacks with a dependency between them are not being ordered in the graph as being dependant on each other. Observed behaviour when running terraspace all init (these are excerpts from the full project).

Running:
    terraspace init defaults               # batch 1
    terraspace init foxpass                # batch 1

Step-by-step reproduction instructions

See code samples

Code Sample

The foxpass stack has the following in the base.tfvars.

<% depends_on("defaults") %>

name_prefix = "<%= Terraspace.env %>"
environment = "<%= Terraspace.env %>"

ssm_kms_key_arn = <%= output("defaults.ssm_kms_key_arn", mock: "arn:aws:kms::::key") %>

Ouput of the defaults stack contains outputs.tf

output "ssm_kms_key_arn" {
  description = "The SSM encryption key ARN"
  value       = aws_kms_key.ssm.arn
}

When checking the generated output from the init we see that there is no such file in the .terraspace-cache/.../stacks/foxpass/ for a file called 1-base.auto.tfvars

Solution Suggestion

This seems indicative that there is some issue building the graph, although it works for everything else in the correct order for the other stacks in the entire project.

chloe-boylan commented 1 year ago

We came across something like this recently but and haven't had a chance to try to repro intentionally yet. Interesting that your example is KMS though, as ours was also.

gwvandesteeg commented 1 year ago

Interesting observation.. if i run the init on the staging environment, it's in the correct order

13:36:49 Thu May 18 ]-[ gerwin@wash:7 ]-[ 90:100047 ]-[ develop ]-[ terraspace:staging ]
[ ~/src/infrastructure ]
$ terraspace all init -y --exit-on-fail && terraspace all plan -y --exit-on-fail
Running:
    terraspace init defaults               # batch 1
    terraspace init foxpass                # batch 2

if i run init on the prod environment we get the reported issue.

Staging has had all the changes already applied, prod has not yet.

gwvandesteeg commented 1 year ago

The problem seems to be that something is causing the tfvars files to not get generated.

boltops-tools / terraspace