hclvalidate didn't works on hcl that contains dependency

[kamontat]

Describe the bug

When I try to run hclvalidate command on terragrunt.hcl that contains dependency, I got dependency.namespace is object with 1 attribute "inputs".

When I try to run hclvalidate command with --terragrunt-hclvalidate-show-config-path, I got json: cannot unmarshal string into Go struct field CtyJSONOutput.Value of type map[string]interface {}.

Steps To Reproduce

Create terragrunt.hcl with dependency field, and run hclvalidate on that directory.

dependency "namespace" {
  config_path = "${get_terragrunt_dir()}/../namespace"
}
inputs = {
  namespace = dependency.namespace.outputs.namespace
}

Expected behavior

Similar result as run tofu validate.

Nice to haves

• Terminal output
• Screenshots

Versions

• Terragrunt version: v0.68.17
• OpenTofu version: v1.8.5
• Environment details (Ubuntu 20.04, Windows 10, etc.): MacOS 15.1.1

[yhakbar]

Hey @kamontat ,

Does that dependency have any outputs? Has it been applied yet?

If not, you may need to mock those outputs so that the relevant cty values are available for HCL parsing at this phase.

Let me know if any of that doesn't make sense!

[kamontat]

@yhakbar the resource has been applied. I can run terragrunt run-all validate without any problem. The problem occurred only when I run terragrunt hclvalidate. For mock, which command should I specific to use mock?

[yhakbar]

Hmmm... what you're saying makes sense. I'm not sure that there is a way to have the cty values available for HCL parsing here. I know that the hclvalidate command was introduced specifically to provide more support for pre-emptively validating HCL configurations like this, though.

To avoid a drawn out back and forth on what's causing the issue here, let's do this:

1. Fork this repository.
2. Add a fixture that reproduces your issue here in your fork.
3. Create a pull request to this repository.

If hclvalidate is working as expected, this test should still work. If not, we might need to update some logic, and we already have a fixture that will reliably reproduce the issue. If you have Go installed locally, you can run the test and see if it fails how you expect.

If it doesn't work, we might need to write some Go to adjust the behavior of hclvalidate and/or adjust the test. If you're comfortable with Go, you might want to consider taking a stab at adjusting that logic. If you're not, you might need to wait for one of the maintainers here to help you out.

When creating the fixture, avoid using any configurations that rely on AWS access, etc unless necessary.

[yhakbar]

Hey @kamontat , do you think you'll have any time to provide that fixture for us to test against? As it stands, we don't have enough information to tackle this issue.

[kamontat]

@yhakbar Unlikely, I'm very busy until ~Jan 2025.