-
-
Notifications
You must be signed in to change notification settings - Fork 962
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
read_terragrunt_config does not skip over disabled dependencies, and will error if the dependency has a config path that doesnt yet exist. #2734
Comments
Can we expect a hotfix for this relatively soon? Currently, this makes read_terragrunt_config useless when utilizing optional dependencies |
Hello, |
Additionally, will be helpful to provide a returned error and an example how to reproduce this issue I tried to do a similar setup in https://github.com/denis256/terragrunt-tests/tree/master/issue-2734 but invocation of |
Unfortunately my environment is kind of complex with how its linked, but I pinpointed the issue to this issue and resolved it by adding a dummy dependency (empty tf) to load instead. The error just states that I THINK the issue actually is when the dependency is appended to the config from an include file. On app1, can you potentially create a separate HCL where you load the dependency (named dependency.hcl) and include it as such:
Then remove that dependency block from the terragrunt.hcl in app1? I believe this may actually cause the expected behavior, because this is how I have dependencies mostly setup. |
Unfortunately I don't have the prowess to make a PR for this project, but want to be sure this issue is known. |
Adding onto this, it's not clear to me how this attribute is meant to be used in practice. In particular, it seems like the only time In the variable case, it's not clear to me what the expectation is for dependency outputs. If the dependency is It seems to me that the answer to this problem is to always inject mocked outputs whenever we see a disabled dependency and not try loading the config. |
Previously, using disabled dependency outputs wasn't really working because it would require that the `terragrunt.hcl` file as present, which was a bug. Additionally, disabled dependencies didn't have mocked outputs loaded, which doesn't really make sense otherwise. See [1] for more details. This commit as a whole addresses [2]. [1] gruntwork-io#2734 (comment) [2] gruntwork-io#2734 (comment)
I've created #2816 aiming to address this. |
Describe the bug
When performing a read_terragrunt_config from a different .HCL to another .HCL that has dependencies, the .HCL with the dependency has its block read whether or not its enabled, when it should be skipped over if its not enabled. This means that if the block has a config path that doesnt exist, it will error even though the module itself will run.
A good subset of my config files utilize read terragrunt config and optional dependencies to achieve minimal definitions for the child HCL files using include blocks, but this completely breaks my process and makes terragrunt unusable with this new feature for dependency block.
To Reproduce
Create a .HCL file to read from where the config path is defined to a dependency path that doesn't exist, and then also set the dependency attribute of "enabled" to false.
// paste code snippets here
HCL with disabled dependency. It will run normally since it is false, and the call for the output is encapsulated in a try
read_terragrunt_config HCL
Not the best example, making it quickly but it should be obvious what you need to do to reproduce the steps here.
Expected behavior
The expected behavior is that read_terragrunt_config should skip over the dependency block, but its clearly processing it. This causes a glaring issue with any configs relying on read_terragrunt_config with optional dependencies based on file paths existing.
Nice to have
Versions
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: