I've seen this behavior several times and I can gather more info but first wanted to ask -
(windows 10, terragrunt version v0.23.30)
If I have a nested directory structure of terragrunt modules and try and apply-all from the top level, and forever reason it fails.
If I cd into the failing module and run terragrunt from there I get a .terragrunt-cache dir in that child dir.
after resolving the issue I should be able to cd back to the top and apply-all again to deploy any remaining modules which depended on the failed one.
What I see is that apply-all shows me all the expected modules AND one it found in the clild .terragrunt-cache dir created above.
Am I alone in seeing this issue? I have encountered this quite a few times.
This affects all -all commands, here is a snip from destroy-all (in D:/live/live/project/us-west-1/xxx/demo) showing a module being found in a cache dir -
=> Module D:/live/live/project/us-west-1/xxx/demo/infra/network/peering (excluded: false, dependencies: [D:/live/live/project/us-west-1/xxx/demo/infra/network/vpc_compute, D:/live/live/project/us-west-1/xxx/demo/infra/network/vpc_docdb])
=> Module D:/live/live/project/us-west-1/xxx/demo/infra/network/vpc_compute (excluded: false, dependencies: [])
=> Module D:/live/live/project/us-west-1/xxx/demo/infra/network/vpc_compute/.terragrunt-cache/9XMpZZzIpP7iixD598IFNEhphH4/Rvcr1Xqh4QpJ60TT9YEtkizwh6A (excluded: false, dependencies: [])
=> Module D:/live/live/project/us-west-1/xxx/demo/infra/network/vpc_docdb (excluded: false, dependencies: [])
Anyway, before I gather a bunch of other info, is there something obvious I'm overlooking?
Thanks,
Tim
Strange... The FindConfigFilesInPath method is what we use to find Terragrunt modules when you run xxx-all commands. That method, in turn, calls containsTerragruntModule, which _should_ explicitly exclude anything in the Terragrunt cache. Not sure why that isn't working in your case!
If you're up for an experiment, perhaps check out the Terragrunt source, add some logging to those methods, and run it from source (go run main.go apply-all)?
@brikis98 Looking at the code, it looks like it is based on options.TerragruntCacheDir. Does that mean that it is based on the current context? E.g., if I run terragrunt in a child dir without a custom cache dir (and thus use .terragrunt-cache in the current dir), but then run apply-all with a custom cache dir, it would pick up the config in the original cache dir from the first run right (because options.TerragruntCacheDir is set to the custom cache dir)?
Yes, I think so.
Then perhaps a potential solution is to also always reject any path that contains .terragrunt-cache? It seems like you would never want to pick anything up in there in the real world.
Most helpful comment
Then perhaps a potential solution is to also always reject any path that contains
.terragrunt-cache? It seems like you would never want to pick anything up in there in the real world.