-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Fix #1124 #1134
Fix #1124 #1134
Conversation
a8bbdbe
to
e39bdad
Compare
… be updated for dependency
@@ -353,6 +354,30 @@ func cloneTerragruntOptionsForDependencyOutput(terragruntOptions *options.Terrag | |||
targetOptions.DownloadDir = downloadDir | |||
} | |||
|
|||
// If the Source is set, then we need to recompute it in the context of the target config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to make sure I understand here... If terragrunt.hcl
has, say:
terraform {
source = "github.com/org/modules.git//module-a"
}
dependency "b" {
path = "../module-b"
}
And module-b/terragrunt.hcl
contains:
terraform {
source = "github.com/org/modules.git//module-b"
}
You're saying that if someone runs terragrunt apply --terragrunt-source /local/path/to/modules
, then we are overriding the source
parameter in both the terragrunt.hcl
of module-a
and of module-b
?
If so, then this highlights two issues with the --terragrunt-source
design:
- If you run
terragrunt apply --terragrunt-source /foo/bar
in folderyyy
, as of now, the only thing it does is override thesource
URL inyyy/terragrunt.hcl
to the exact value/foo/bar
. However, if you runterragrunt apply-all --terragrunt-source /foo/bar
in folderyyy
, it overrides thesource
value of each child module withinyyy/sub/path
to something like/foo/bar/sub/path
. The inconsistency between these two behaviors is being highlighted in this PR. Would it make sense to always use the latter behavior? That is--terragrunt-source
should always be set to the root of your modules repo? - This also highlights a limitation of
--terragrunt-source
: it assumes all your modules are coming from the same root repo. You won't be able to do anapply-all
if you're pulling from multiple repos (e.g., your own infra modules, Terraform Registry, Gruntwork repos, etc).
Perhaps a better solution to this is to support some sort of mapping?
terragrunt apply --terragrunt-source-map source:dest
The --terragrunt-source-map
param would replace any source
URL that starts with source
to instead start with dest
.
For example:
terragrunt apply --terragrunt-source-map github.com/org/modules.git:/local/path/to/modules
The above would replace source = "github.com/org/modules.git//xxx"
with /local/path/to/modules//xxx
regardless of whether you were running apply
, or apply-all
, or using a dependency
. This would give us a consistent behavior across all command and support mapping multiple repos by specifying the param multiple times:
terragrunt apply \
--terragrunt-source-map github.com/org/modules.git:/local/path/to/modules \
--terragrunt-source-map github.com/org/another-repo.git:/local/path/to/another-repo
We could also consider allowing users to specify this mapping in a file:
terragrunt apply --terragrunt-source-map mapping.hcl
Where mapping.hcl
contains:
mappings = {
"github.com/org/modules.git" = "/local/path/to/modules"
"github.com/org/another-repo.git" = "/local/path/to/another-repo"
}
Note, I realize the above is a bigger change, so it could also be filed as an issue and done in a separate PR 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #1138
By the way, are you suggesting we close this PR in favor of solving for the mapping case, or are you ok with the band-aid fix here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Filed #1138
Thanks! I just updated it with the more detailed description above.
By the way, are you suggesting we close this PR in favor of solving for the mapping case, or are you ok with the band-aid fix here?
Your call! I'm OK with either approach. Fixing #1138 would be great, but definitely isn't a high priority, so a band-aid fix for now would be fine too. #1138 might make for a good trial project in the future, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. +1 to #1138 being a good trial project. Thanks for the sanity check!
Thanks for the review! Merging this in as a bugfix for the reporter, since right now it breaks usage of |
This fixes the bug reported in #1124. The main issue is that the
Source
attribute isn't updated in the context of the target config when retrieving the dependency, which causes it to continue to use the source value of the dependent config.To fix this, we recompute the
Source
on the target config when it is set. Note that I had to shuffle the functions around to avoid a circular dependency.