Terragrunt: How to inherit parent terragrunt.hcl file's inputs block

Created on 21 Jan 2020  ยท  4Comments  ยท  Source: gruntwork-io/terragrunt

In my top-level parent terragrunt.hcl, I have the following block. Taken directly from the terragrunt example repo:

inputs = merge(
  yamldecode(
    file("${get_terragrunt_dir()}/${find_in_parent_folders("region.yaml", local.default_yaml_path)}"),
  ),
  yamldecode(
    file("${get_terragrunt_dir()}/${find_in_parent_folders("env.yaml", local.default_yaml_path)}"),
  ),
  {
    aws_profile = "prod"
  },
)

How can I inherit env, region, and aws_profile in my child terragrunt.hcl file and use them as variables?

$ tree
.
โ”œโ”€โ”€ terragrunt.hcl
โ””โ”€โ”€ us-west-2
    โ”œโ”€โ”€ region.yaml
    โ””โ”€โ”€ staging
        โ”œโ”€โ”€ dynamodb
        โ”‚   โ”œโ”€โ”€ backend.tf
        โ”‚   โ””โ”€โ”€ terragrunt.hcl
        โ””โ”€โ”€ env.yaml
question

Most helpful comment

Unfortunately, you can't reference other variables in other config yet. See https://github.com/gruntwork-io/terragrunt/issues/814 for the thread on this topic.

As a workaround, you will have to do the merge in terraform. E.g you might add a variable name_suffix and environment, and then set environment to staging in env.yaml. Then, you will construct the name in terraform (NOT terragrunt.hcl) as "/ctx-${var.environment}${var.name_suffix}".

Also, side question: I can't seem to use data.terraform_remote_state here as I can't add a data block to terragrunt.hcl. How do people usually reference other modules' output?

Terragrunt is not terraform code, so it does not support all the resources and data sources. I am currently working on reference docs to make it easier to discover all the supported features of terragrunt configuration, but in the meantime, you will have to go through the feature list in the doc site to find what you need. For this use case, see this section.

All 4 comments

inputs from the parent are automatically merged to the child when you add the following block to the child's terragrunt.hcl:

include {
  path = find_in_parent_folders()
}

You can read more about the inheritance properties of terragrunt here: https://terragrunt.gruntwork.io/use-cases/keep-your-remote-state-configuration-dry/#filling-in-remote-state-settings-with-terragrunt

Thanks for the prompt response! Let's say my child terragrunt.hcl file looks like this:

terraform {
  source = "git::https://github.com/cloudposse/terraform-aws-ssm-parameter-store?ref=0.1.5"
}

include {
  path = find_in_parent_folders()
}

inputs = {
  parameter_write = [
    {
      name        = "/ctx-staging/dynamodb/tables"    // <----- I want to replace staging with a variable
      value       = data.terraform_remote_state.dynamodb.outputs.arn
      type        = "String"
      overwrite   = "true"
      description = "DynamoDB book table ARN"
    }
  ]
}

Is there a way to replace staging somehow with the environment variable merged into the child?

Also, side question: I can't seem to use data.terraform_remote_state here as I can't add a data block to terragrunt.hcl. How do people usually reference other modules' output?

Unfortunately, you can't reference other variables in other config yet. See https://github.com/gruntwork-io/terragrunt/issues/814 for the thread on this topic.

As a workaround, you will have to do the merge in terraform. E.g you might add a variable name_suffix and environment, and then set environment to staging in env.yaml. Then, you will construct the name in terraform (NOT terragrunt.hcl) as "/ctx-${var.environment}${var.name_suffix}".

Also, side question: I can't seem to use data.terraform_remote_state here as I can't add a data block to terragrunt.hcl. How do people usually reference other modules' output?

Terragrunt is not terraform code, so it does not support all the resources and data sources. I am currently working on reference docs to make it easier to discover all the supported features of terragrunt configuration, but in the meantime, you will have to go through the feature list in the doc site to find what you need. For this use case, see this section.

I wrote up an RFC that introduces import blocks. This has the potential to address the use case described here, so would love feedback from those following this issue to see if it makes sense.

Was this page helpful?
0 / 5 - 0 ratings