Skip to content
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.

Sign up for GitHub

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

Jump to bottom

read_terragrunt_config does not skip over disabled dependencies, and will error if the dependency has a config path that doesnt yet exist. #2734

Open
2 tasks done
RyanBaker19 opened this issue Sep 27, 2023 · 7 comments · May be fixed by #2816
Open
2 tasks done

read_terragrunt_config does not skip over disabled dependencies, and will error if the dependency has a config path that doesnt yet exist. #2734

RyanBaker19 opened this issue Sep 27, 2023 · 7 comments · May be fixed by #2816
Labels
bug Something isn't working

Comments

@RyanBaker19
Copy link

RyanBaker19 commented Sep 27, 2023 •
edited

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

dependency "example" {
 config_path = "/folder/" #this folder and path doesnt exist
 enabled = fileexists("/folder/terragrunt.hcl") #false
}

inputs {
example = try(dependency.example.outputs.test,null)
}

read_terragrunt_config HCL

locals {
  config = read_terragrunt_config("../dependency_example/terragrunt.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

  • Terminal output
  • Screenshots

Versions

  • Terragrunt version: Latest Version 0.51.x
  • Terraform version: 1.5
  • Environment details (Ubuntu 20.04, Windows 10, etc.): Alpine

Additional context
Add any other context about the problem here.
@RyanBaker19 RyanBaker19 added the bug Something isn't working label Sep 27, 2023
@RyanBaker19
Copy link
Author

Can we expect a hotfix for this relatively soon? Currently, this makes read_terragrunt_config useless when utilizing optional dependencies

@denis256
Copy link
Member

Hello,
PRs are always welcome to address this issue :)

@denis256
Copy link
Member

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 read_terragrunt_config("../app1/terragrunt.hcl") is working fine

@RyanBaker19
Copy link
Author

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 read_terragrunt_config failed: {path_here}/terragrunt.hcl does not exist

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:

include "env" {
  path = "/env/dependency.hcl"
  expose = true
}

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.

@RyanBaker19
Copy link
Author

Hello, PRs are always welcome to address this issue :)

Unfortunately I don't have the prowess to make a PR for this project, but want to be sure this issue is known.

@jlepere-everlaw
Copy link
Contributor

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 enabled would be beneficial is if it's variable (i.e enabled = local.has_dependency_x). Otherwise, the dependency wouldn't need enabled (it would always exist) or we wouldn't need it at all (no dependency block).

In the variable case, it's not clear to me what the expectation is for dependency outputs. If the dependency is enabled = false, what's the expectation for outputs that we'd otherwise reference?

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.

jlepere-everlaw added a commit to jlepere-everlaw/terragrunt that referenced this issue Nov 30, 2023
@jlepere-everlaw
Mock disabled dependency outputs.
2ab68cf 
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)
@jlepere-everlaw jlepere-everlaw linked a pull request Nov 30, 2023 that will close this issue
Open
@jlepere-everlaw
Copy link
Contributor

I've created #2816 aiming to address this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug Something isn't working
Projects
Terragrunt Roadmap
Status: To do
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Mock disabled dependency outputs. jlepere-everlaw/terragrunt
3 participants
@denis256 @jlepere-everlaw @RyanBaker19