Skip to content
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

Merged
merged 2 commits into from
Apr 15, 2020
Merged

Fix #1124 #1134

merged 2 commits into from
Apr 15, 2020

Conversation

yorinasub17
Copy link
Contributor

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.

@yorinasub17 yorinasub17 requested a review from brikis98 as a code owner April 10, 2020 17:41
@yorinasub17 yorinasub17 force-pushed the yori-fix-1124 branch 2 times, most recently from a8bbdbe to e39bdad Compare April 10, 2020 17:45
@yorinasub17
Copy link
Contributor Author

NOTE: As a test to ensure the regression test is actually testing the bug, see the failure on e39bdad where the new test fails without any changes, and then it passes in c960eca without any modifications to the test.

@@ -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.
Copy link
Member

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:

  1. If you run terragrunt apply --terragrunt-source /foo/bar in folder yyy, as of now, the only thing it does is override the source URL in yyy/terragrunt.hcl to the exact value /foo/bar. However, if you run terragrunt apply-all --terragrunt-source /foo/bar in folder yyy, it overrides the source value of each child module within yyy/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?
  2. 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 an apply-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 😁

Copy link
Contributor Author

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?

Copy link
Member

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.

Copy link
Contributor Author

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!

@yorinasub17
Copy link
Contributor Author

Thanks for the review! Merging this in as a bugfix for the reporter, since right now it breaks usage of --terragrunt-source with dependencies without any workaround. This at least enables a path forward.

@yorinasub17 yorinasub17 merged commit 706b641 into master Apr 15, 2020
@yorinasub17 yorinasub17 deleted the yori-fix-1124 branch April 15, 2020 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants