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.

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

Expose Dependencies from read_terragrunt_config calls in PartialDecodeSectionType #1107

Open
dmattia opened this issue Mar 31, 2020 · 4 comments
Labels
bug Something isn't working needs design We need to flesh out the design before we can resolve the issue p:needs triage Needs to be processed by maintainer and issue type / priority added

Comments

@dmattia
Copy link
Contributor

dmattia commented Mar 31, 2020

Hello! I am working on a go binary that generates atlantis config from terragrunt files.

My repo is here: https://github.com/transcend-io/terragrunt-atlantis-config, and the part of my code that tries to find all terragrunt dependencies is here: https://github.com/transcend-io/terragrunt-atlantis-config/blob/master/cmd/generate.go#L88-L123

One thing that I'm noticing is that read_terragrunt_config can now add dependencies from other files, but that those dependencies are not anywhere to be found (as best I can tell), in the output of calls to PartialDecodeSectionType, even though PartialDecodeSectionType does evaluate local values.

Would it be possible to add an option in the config library to get those dependencies?

@yorinasub17
Copy link
Contributor

I understand the use case, but this is not something we want to support in PartialParseConfigFile, as that overcomplicates the function (e.g., we need to track and return all the config that is parsed in the tree) for a use case that is not necessary for terragrunt right now.

It's particularly challenging because it is parsed as part of a function call that is not made at the top level, and so you need to use some kind of global map and look that up later, which is going to be an ugly mess to what is already very difficult to work code.

@yorinasub17
Copy link
Contributor

That said, we would like to help out but we are buried right now. I think this requires some deep thinking and I don't have any cycles at the moment to help out from scratch.

If you have a PR that can do this in a sane way and relatively easy to maintain, happy to review and include that!

@yorinasub17
Copy link
Contributor

Gah! After thinking about this in the shower, I just realized we will most likely need this as apply-all and plan-all is probably broken when read_terragrunt_config is in the mix. Will be taking a deeper look at this next week.

@yorinasub17 yorinasub17 added bug Something isn't working needs design labels Apr 3, 2020
@dmattia
Copy link
Contributor Author

dmattia commented Apr 3, 2020

Sounds great! I did happen to notice earlier today that terragrunt providers error messages weren't ideal when I had an issue with a provider from a dependency I read in in a read_terragrunt_config call. If you think that might be related, I'd gladly try to come up with a simple example that shows the behavior

@infraredgirl infraredgirl added p:needs triage Needs to be processed by maintainer and issue type / priority added needs design We need to flesh out the design before we can resolve the issue and removed needs investigation labels Oct 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs design We need to flesh out the design before we can resolve the issue p:needs triage Needs to be processed by maintainer and issue type / priority added
Projects
None yet
Development

No branches or pull requests

3 participants