search

gruntwork-io / terragrunt

Terragrunt is a flexible orchestration tool that allows Infrastructure as Code written in OpenTofu/Terraform to scale.
https://terragrunt.gruntwork.io/
MIT License
8.04k stars 975 forks source link

Show an error for duplicate generate blocks #1457

Closed jrsmith17 closed 3 years ago

jrsmith17 commented 3 years ago

As the title states, Terragrunt has stopped overwriting one of my variables.tf files even though if_exists = "overwrite" is set on the module. This feature in conjunction with templates was the entire reason I am using Terragrunt, so you can imagine my distress. To make this even more unhelpfully confounding, this behavior has been consistent across all my modules, even the ones I wasn't working on at the time when the failure started.

An extra wrinkle to this bug might be my setup. Terra* didn't really meet my work project's requirements so I had to write a bash script to make the functionality do as I want. I can't share my exact setup, since it's work, but here's the gist of what I do.

base/ variables/ (per aws account variables in json files, that get exported by bash and should be picked up by Terragrunt's get_env, but that suddenly stopped working) deploy.sh (the bash script in question) modules/ moduleA/ submoduleA/ variables.tf and friends terragrunt.hcl

My current solution is to manually place variables from the JSON files into the variables file. This obviously is suboptimal, so I hope someone has a clue as to what caused the sudden shift.

brikis98 commented 3 years ago

Hard to guess without being able to see your code! Perhaps you can share a reproducible case?

jrsmith17 commented 3 years ago

I actually managed to figure it out from looking at my code and the source code for Terragrunt. I accidentally forgot to rename generate "FilenameA" to generate "FilenameB" when copy pasting for the new template.

Would you accept a PR around making this a little obvious in the output? I'd be happy to put in a little work to make it a bit more obvious for others and future me.

brikis98 commented 3 years ago

Glad to hear you got it sorted. Anything that helps with error handling or usability sounds great! What did you have in mind?

jrsmith17 commented 3 years ago

I was thinking something along the lines of catching the case where a generate name was already used, print out a warning saying something like "Name foo has already been used in File A Line 17. Name foo in File A Line 37 conflicts with that. Only the later name will generate."

brikis98 commented 3 years ago

Just to clarify something... If your code has:

generate "<NAME>" {
  path = "<PATH>"
}

Is the issue you saw with a duplicate <NAME> or <PATH>?

jrsmith17 commented 3 years ago

I had a duplicate <NAME>.

brikis98 commented 3 years ago

Oh... Hm, it seems like a duplicated <NAME> should be an error. I can't think of a use case where allowing that would be desirable. @yorinasub17 WDYT?

yorinasub17 commented 3 years ago

Ah yup that should definitely be an error!

jrsmith17 commented 3 years ago

Just now getting to this after work. Should I move forward (probably this weekend) with working on a PR? Would you rather handle it internally?

brikis98 commented 3 years ago

A PR to make this an error is very welcome!

brikis98 commented 3 years ago

@denis256 could you look into this one?