At what stage are locals evaluated, when are locals in scope for generate blocks

[sophie-warner-annalise-ai]

Context

This is my desired dir structure

.
├── root.hcl
├── region/
│   ├── aws/
│   │   └── vpc/
│   │       └── terragrunt.hcl
│   ├── gcp
│   ├── azure
│   └── ..
└── providers/
    ├── aws.hcl
    ├── gcp.hcl
    └── azure.hcl

I'd like to generate the provider based on where the unit sits within the directory structure.

# root.hcl
locals {
  path_split    = split("/", path_relative_to_include())
  region        = local.path_split[0]
  profile       = "account-name-${local.region}"
  provider_name = local.path_split[1]

  provider = read_terragrunt_config("${get_repo_root()}/providers/${local.provider_name}.hcl")
}

generate = local.provider.generate

# providers/aws.hcl
generate "provider" {
    path      = "provider.tf"
    if_exists = "overwrite"
    contents  = <<EOF
provider "aws" {
  profile = ${local.profile}
  default_tags {
    tags = merge(
      {
        Terraform = "infrastructure-live/${get_path_from_repo_root()}",
      },
      local.default_tags
    )
  }
}
EOF
}

I'm getting local.profile is null in providers/aws.hcl.

Question

In what order are each of the locals in root.hcl computed?

If they are evaluated from top to bottom then I would of thought that local.provider would of evaluated to this

locals {
  provider = generate "provider" {
    contents = <<EOF
  profile = ${local.profile}
  EOF
  }
  ...
}

at which point local.profile would be in scope.

[yhakbar]

Hey @sophie-warner-annalise-ai ,

I recommend going through the steps here and running them locally:
https://terragrunt.gruntwork.io/docs/getting-started/overview/

You're trying to do some things like assign configuration blocks to attributes, which won't work.

The solution you're looking for is either to include a provider.hcl file in all your units, and to have one provider.hcl each directory that maps to a cloud provider or one generate block in your root.hcl, and content populated by a combination of find_in_parent_folders and read_terragrunt_config.

If you need more help, consider asking in Discord too.

[sophie-warner-annalise-ai]

Hey thanks for your quick reply.

I'm trying to dynamically assign the generate block similar to the last example here: https://terragrunt.gruntwork.io/docs/reference/config-blocks-and-attributes/#generate

Yeah the second option I also tried but got a similar issue where the root locals were null.

# root.hcl
generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents = file("${get_repo_root()}/providers/${local.provider}.tf")
}

# providers/aws.tf
provider "aws" {
  profile = "${local.profile}"
  ...
}

I'll follow up in the discord

[yhakbar]

To be honest, I had no idea Terragrunt could do that.

I don't think I've ever seen anyone do that before.

[sophie-warner-annalise-ai]

In relation to my original question, you can see from running terragrunt with --terragrunt-log-level debug that it

1. Evaluates the locals in the unit terragrunt.hcl
2. Evaluates the locals in any included *.hcl
3. Copies the module and generated config into the terragrunt cache

As the reading of the file happens after from the locals have populated it looks like they aren't in scope at that time.

[sophie-warner-annalise-ai]

If wanting to generate providers based on where a unit sits in a directory hierarchy, but define them in a single place. You can do this:

# root.hcl
locals {
  path_split   = split("/", path_relative_to_include())
  region       = local.path_split[0]
  provider     = local.path_split[1]
  profile      = "account-name-${local.region}"
  provider_options = { aws : <<EOF
provider "aws" {
  profile = "${local.profile}"
}
EOF
  }
}

generate "provider" {
  path      = "provider.tf"
  if_exists = "overwrite_terragrunt"
  contents  = local.provider_options[local.provider]
}

Haven't figured out how to do it from an external files though