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
Between versions v0.58.9 and v.58.10 the behavior of at least graph-dependencies changed when using Terragrunt's working dir configuration.
When provided a relative path that doesn't end in a root module, the DOT representation changes from fully-qualified paths to relative paths, rooted on Terragrunt's working dir.
Steps To Reproduce
Configuration layout. main.tf and terragrunt.hcl are both empty.
$ tree $(pwd)
/private/tmp/foo
└── bar
└── baz
├── main.tf
└── terragrunt.hcl
3 directories, 2 files
$ tgenv use 0.58.10 && terragrunt graph-dependencies --terragrunt-working-dir bar/
[INFO] Switching to v0.58.10
[INFO] Switching completed
digraph {
"baz";
}
What's interesting is that if you use a fully-qualified path for Terragrunt's working dir, even on v.0.58.9, you get relative paths:
$ tgenv use 0.58.9 && terragrunt graph-dependencies --terragrunt-working-dir /private/tmp/foo/bar
[INFO] Switching to v0.58.9
[INFO] Switching completed
digraph {
"baz";
}
Expected behavior
I am not sure what the preferred output should be. I can see arguments being made for fully-qualified or relative paths.
My problem is that I can't see what changes between v0.58.9..v0.58.10 would cause this behavior difference.
Nice to haves
Terminal output
Screenshots
Versions
$ tgenv use 0.58.9 && terragrunt --version
[INFO] Switching to v0.58.9
[INFO] Switching completed
terragrunt version v0.58.9
$ tgenv use 0.58.10 && terragrunt --version
[INFO] Switching to v0.58.10
[INFO] Switching completed
terragrunt version v0.58.10
$ terraform version
Terraform v1.9.8
on darwin_arm64
$ uname -a
Darwin 23.6.0 Darwin Kernel Version 23.6.0: Thu Sep 12 23:35:29 PDT 2024; root:xnu-10063.141.1.701.1~1/RELEASE_ARM64_T6000 arm64
Additional context
We use terragrunt graph-dependencies to provide summaries on our Plans and Applies. We were using a very old version of Terragrunt and were going through the upgrade process when we ran into this behavioral change.
In searching for what code change might have induced this, the first hit was #3248, which is suspicious due to the prefix snippet:
I should have mentioned: I'm looking to see if I can restore the original behavior. Is there a CLI flag I can use to restore the DOT representation to use fully-qualified paths?
Hey @KetchupBomb , it looks like this behavior should be adjustable via the --terragrunt-log-show-abs-paths or a dedicated flag on the graph-dependencies command.
Are you interested in doing the update to make that configurable? If so, we're happy to help you make it a happen. Otherwise, I'm not sure when we'd be able to prioritize this, as I don't think the majority of users find graph-dependencies unusable with relative paths.
Describe the bug
Between versions
v0.58.9
andv.58.10
the behavior of at leastgraph-dependencies
changed when using Terragrunt's working dir configuration.When provided a relative path that doesn't end in a root module, the DOT representation changes from fully-qualified paths to relative paths, rooted on Terragrunt's working dir.
Steps To Reproduce
Configuration layout.
main.tf
andterragrunt.hcl
are both empty.$ tree $(pwd) /private/tmp/foo └── bar └── baz ├── main.tf └── terragrunt.hcl 3 directories, 2 files
Terragrunt
v0.58.9
Terragrunt
v0.58.10
What's interesting is that if you use a fully-qualified path for Terragrunt's working dir, even on
v.0.58.9
, you get relative paths:Expected behavior
I am not sure what the preferred output should be. I can see arguments being made for fully-qualified or relative paths.
My problem is that I can't see what changes between
v0.58.9..v0.58.10
would cause this behavior difference.Nice to haves
Versions
Additional context
We use
terragrunt graph-dependencies
to provide summaries on our Plans and Applies. We were using a very old version of Terragrunt and were going through the upgrade process when we ran into this behavioral change.In searching for what code change might have induced this, the first hit was #3248, which is suspicious due to the
prefix
snippet:terragrunt/configstack/module.go
Lines 309 to 320 in 6839411
But this code did not land seemingly until e37d71e and
v0.61.0
.The text was updated successfully, but these errors were encountered: