-
-
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
Implement feature to allow hidden files in local copy #1935
Conversation
@@ -0,0 +1,444 @@ | |||
package test |
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.
NOTE: This file is a refactoring of integration_test.go
to make that main test file smaller. The only new test introduced here is TestLocalDownloadWithAllowedHiddenFiles
- all other test functions are a straight copy.
Thanks for review! Prior to merge, I want one sanity check from @brikis98 on the terminology of the new feature: does |
@@ -63,6 +63,11 @@ The `terraform` block supports the following arguments: | |||
registry]({{site.baseurl}}/docs/getting-started/quick-start#a-note-about-using-modules-from-the-registry) for more | |||
information about using modules from the Terraform Registry with Terragrunt. | |||
|
|||
- `include_in_copy` (attribute): When using local file path sources, this specifies a list of glob patterns (e.g., |
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.
Is this purely additive to Terragrunt's default behavior? Or does it allow you to have Terragrunt not copy some items? I'm guessing by the name it's the former... But I worry that the minute we add this, users will also request the latter. I suppose we could add an exclude_in_copy
feature in the future...
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.
- `include_in_copy` (attribute): When using local file path sources, this specifies a list of glob patterns (e.g., | |
- `include_in_copy` (attribute): When using local file path sources, this specifies a list of glob patterns (e.g., |
Is this really the proper context on this feature? It might be worth adding some context like:
When you use the source
param in your Terragrunt config and run terragrunt <command>
, Terragrunt will download the code specified at source
into a scratch folder (.terragrunt-cache
, by default), copy the code in your current working directory into the same scratch folder, and then run terraform <command>
in that scratch folder. By default, Terragrunt excludes hidden files and folders during the copy step. This feature allows you to specify glob patterns ...
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.
Sorry for the delay in responding.
Is this purely additive to Terragrunt's default behavior? Or does it allow you to have Terragrunt not copy some items? I'm guessing by the name it's the former...
Yes this is purely additive.
But I worry that the minute we add this, users will also request the latter. I suppose we could add an exclude_in_copy feature in the future...
I'm actually not as concerned about this, primarily because there is limited use case for exclusion in the context of terragrunt
. I think in practice, it isn't practical to rely on terragrunt to exclude files using a lookup table, and instead should rely on other means (like moving the files to a different folder above levels, or use something like git
). I think we can wait to add exclude_in_copy
if someone asks for it.
Is this really the proper context on this feature?
Ah good catch about mentioning the terragrunt working dir. Updated this section! 83c60b1
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.
LGTM!
Thanks for review! I'm going to merge this in now, and open a follow up PR with the suggested changes from @rhoboat (to avoid another review cycle). |
Fixes #394