mirror of
https://github.com/patrickchugh/terravision.git
synced 2026-05-09 08:25:25 +02:00
[GH-ISSUE #114] [FEATURE] terragrunt support #58
Labels
No labels
bug
enhancement
enhancement
good first issue
good first issue
good first issue
pipeline
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/terravision#58
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @ghulteen on GitHub (Apr 10, 2024).
Original GitHub issue: https://github.com/patrickchugh/terravision/issues/114
Originally assigned to: @patrickchugh on GitHub.
In our env we use terragrunt. so I created symlink "localterraform -> terragrunt" and updated the modules/ftwrapper.py which got me closer but it seems that terravision now cannot find the .tf files in the local directory. My guess right now is that it doesn't understand the module config. Are there any plan to test/add terragrunt support?
@patrickchugh commented on GitHub (Jan 31, 2026):
Hi @ghulteen could you share an example repo using Terragrunt and how would you expect it to work?
@lgg42 commented on GitHub (Mar 26, 2026):
I have this same issue. Following terragrunt best practices, our infra repo is similar to:
I'd expect going to an environment folder and run terravision there, wrapping terragrunt generated files, rendering the whole environment diagram.
@patrickchugh commented on GitHub (Mar 29, 2026):
@ghulteen @lgg42 My friend Claude and I have added terragrunt support with the latest release, can you try it out and give me your feedback?
@lgg42 commented on GitHub (Mar 29, 2026):
Woah! such fast! thanks a lot! I give it a go and I suspect I ran into a layer 8 problem..
I want to first try it out against a single terragrunt unit in
infrastructure/live/staging/us-east-1/data-stores/rds/shared(RDS DB)So that's my CWD having a
terragrunt.hclfile. I run terravision the following way:I have the following error:
I tried also changing the CWD to
infrastructure/live/staging/us-east-1/data-stores/which has:And I have the same results.
The terragrunt.hcl files in my infra repo normally have several includes and dependencies, example:
I think I might need to mount just the root of the infra repo instead so it finds all the files, I'm gonna give it a go now
@lgg42 commented on GitHub (Mar 29, 2026):
Ok, if I set my CWD in
infrastructure/live, having:And running:
Then I get up to the init phase but it breaks due to failing cloning private git repos. Example
I'll check and try to carry out a local install instead of a docker run
@lgg42 commented on GitHub (Mar 29, 2026):
Ok, local install did the trick, now I have newer errors...
If I try to run it against a single terragrunt unit (CWD: .../rds/shared) having a
terragrunt.hclfile:If I try to run it against a whole environment stack (
live/staging)Side to side this is a diff comparison of the different stack traces: (multi-unit vs single-unit)
@patrickchugh commented on GitHub (Mar 29, 2026):
@lgg42 Thanks for the detailed bug reports and code examples — they were super helpful in tracking down the root cause. We have shipped fixes in v0.27.0 that address the issues you hit. Here is what changed:
What was wrong
Backend conflict with generate backend / remote_state: TerraVision writes a terravision_override.tf to force a local backend (we do not need remote state — we just need the plan output). But the override file was not being picked up correctly in the .terragrunt-cache directory, so Terraform kept trying to configure the S3 backend and failing with "Backend initialization required".
//subfolder in remote sources: For source URLs like git::https://...//modules/db_subnet_group, Terragrunt runs terraform in the subfolder, not the repo root. We were looking in the wrong directory for plan output.
Dependency resolution during init: When module A depends on module B, Terragrunt auto-initialises module B to read its outputs. The local backend override now gets written to all child modules upfront and -reconfigure is passed via TF_CLI_ARGS_init so auto-inits accept it too.
What you should see now
Better error messages
If things still go wrong, you should now get actionable hints:
I have pushed a docker image and pypi package for version 0.27 with the latest fixes. Please check it out when you have time.
Would love to hear if this resolves your issues. If you hit anything else, the --debug flag will dump tfdata.json which helps us diagnose.
@robinbowes commented on GitHub (Mar 30, 2026):
This is a very timely development as we use Terragrunt!
However, when I run terravision to create a diagram of our multi-module setup, I get an error.
Note: the top-level of the project is
/Users/robin/code/test/project/infraand there are three sub-modules, one for each cloud: aws,, azure, gcp.Any idea how to fix, or diagnose what might be the problem?
@lgg42 commented on GitHub (Mar 30, 2026):
Thanks a lot for the quick support and help @patrickchugh ! I tried it again with 0.27.0, with multi unit and single unit. I've got the same error so I'm going to focus in the single unit here. This time is only the init error:
For whatever reason I didnt't have a
tfdata.jsoncreated or I wasn't able to find it.I'm able to run normally a terragrunt init and terragrunt plan in the unit folder.
terragrunt plan
terragrunt init
terragrunt version 0.94.0
terraform version 1.7.5
@patrickchugh commented on GitHub (Apr 3, 2026):
@lgg42 @robinbowes @ghulteen Thanks for the detailed bug reports and patience — they were incredibly helpful in tracking down the root causes. We've been doing deep testing and found several issues that explain what you've been hitting:
What we found
Backend override not reaching dependency modules
When you run TerraVision on a single module (e.g. rds/shared) that has dependency blocks, Terragrunt auto-initializes those dependencies to read their outputs. Our backend override (terravision_override.tf) was only being written to the target module's directory — not to dependency modules like vpc. So the dependency auto-init would try to configure the real S3 backend and fail.
"No Terraform .tf files found" (@robinbowes's issue)
After init/plan succeeded, TerraVision was looking for .tf files in the module directory (which only contains terragrunt.hcl). The actual .tf files live inside .terragrunt-cache/. We now correctly resolve the cache path and point the source parser there.
What we fixed
Override files are now written to all dependency module directories before init, so Terragrunt's auto-init picks up the local backend override everywhere
codepath now points to the .terragrunt-cache working directory where the .tf files actually live
Added a safety net that writes the override directly to the cache directory after init
If init fails on backend, we attempt recovery via terraform init -reconfigure directly in the cache
Hope this works. If there are any issues with the final diagram the --debug flag will dump tfdata.json which helps us diagnose.
Let me know how it goes and thanks for your patience in making terragrunt support a reality.
@patrickchugh commented on GitHub (Apr 7, 2026):
@lgg42 any luck trying this ?
@lgg42 commented on GitHub (Apr 7, 2026):
Hi! I just tried out the single unit scenario rds/shared. ⚠️ These past days I have upgraded my terraform binary.
terravision 0.32.0
terragrunt 0.94.0
terraform 1.14.8
I do
rm -rf .terragrunt-cache*firstthen
terragrunt init, thenterragrunt plan, everything ok.Then I execute
terravision draw --debug --source ., this is the output:If I run the terravision comand again the output is the same.
I also noticed that I have activated provider caching but I thiiiiink terravision is always downloading them
@robinbowes commented on GitHub (Apr 7, 2026):
@patrickchugh I tried again with the latest version (0.32.0) and I now see init and plan executed for all three clouds.
However, I get this backtrace before the graph is shown:
I have a tfdata.json - I can't share it, but I'm happy to issue any debug commands that might help figure out what the problem is.
@patrickchugh commented on GitHub (Apr 11, 2026):
@lgg42 New release out with --debug improvements and targeted Terragrunt diagnostics aimed at your "backend keeps changing" symptom.
I've tried hard to reproduce locally — terragrunt 0.94.0, real S3 backend, your exact dependency + generate "backend" pattern, with TG_PROVIDER_CACHE set — and can't trigger it. Something specific to your env is in play.
Could you upgrade and re-run
terravision draw --debug --source .?The new diagnostic prints --- [tg-debug] --- sections at four checkpoints (after init, after fallback init, before plan, after plan). Each shows whether terravision_override.tf exists, what backend backend.tf declares, what terraform's stored state claims, and every .tf-containing dir under .terragrunt-cache/. Paste those sections (sanitized) and we should be able to pinpoint exactly when things go wrong.
Also helpful:
If that fails standalone → terragrunt/config bug. If it succeeds but terravision still fails → terravision is doing something extra.
Thanks for sticking with this.
@patrickchugh commented on GitHub (Apr 11, 2026):
@robinbowes Can you try again with the latest code? That was a bug unrealted to terragrunt and it should be fixed
@lgg42 commented on GitHub (Apr 12, 2026):
Hey! Thanks! I need to dedicate some time to execute these steps carefully and provide you with the info you request. In the meanwhile, here's the new output with the new terravision version 0.33.0 (the rest of the error is the same as before)
@patrickchugh commented on GitHub (Apr 14, 2026):
@lgg42 We implemented a fix. Can you try with the latest version? I still cannot reproduce your problem locally so if it still doesn't work just share the debug output again. Thanks.
@robinbowes commented on GitHub (Apr 14, 2026):
Hi @patrickchugh,
I still see the same error:
I also see lots of warnings:
and:
Both warnings show for various variables and resources, not just the two listed above.
@patrickchugh commented on GitHub (Apr 14, 2026):
@robinbowes Can you produce a diagram in the end? If so, can you please run terravision with the --debug flag, and then share your tfdata.json dump file so I can try to re-produce the error? You can do a find/replace on the JSON to replace any account numbers or other data you wish to mask before sharing.
@lgg42 commented on GitHub (Apr 15, 2026):
For the rds/shared unit it shows the same error, but I tried a different unit and it worked and generated the diagram. I've tried another single-module and multi-modules and it fails in some of them and succeed in other