Hardcoded source dependencies to Gruntwork Github repositories #667
LuigiClemente-Awin
started this conversation in
Feedback
Replies: 1 comment
-
Hi @LuigiClemente-Awin, Thank you for the feedback. We are aware of this drawback as described here. Currently we advise automating the following process and running it daily.
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi all
I read in your documentation (https://docs.gruntwork.io/guides/working-with-code/forking/):
The Gruntwork Terms of Service give you permissions to fork the code from the Gruntwork Infrastructure as Code Library into your own repos. This is useful if your company does not allow external dependencies (e.g., you have a company policy that requires all source code to be pulled from an internal GitHub Enterprise or BitBucket server) or if you need to make modifications to the Infrastructure as Code Library that you do not wish to contribute back to Gruntwork.
We noticed that you have a hardcoded source dependency from the vpc module to the security module:
https://github.com/gruntwork-io/terraform-aws-vpc/blob/1e95d1ec622fa9686122055770b7062e3e28848b/modules/vpc-flow-logs/main.tf#L128
source = "git::[email protected]:gruntwork-io/terraform-aws-security.git//modules/private-s3-bucket?ref=v0.65.10"
This breaks the idea of forking for companies that require all code pulled from an internal repo.
You can of course change the code, but then you lose the benefit of easy updates and complicates code management.
I am not sure there is an easy technical solution to external dependencies, since you can't use variables inside the source attribute, short of duplicating the bucket module inside the vpc module.
What are your thoughts on this? Were you aware?
Best regards,
Luigi
Tracked in ticket #109909
Beta Was this translation helpful? Give feedback.
All reactions