-
-
Notifications
You must be signed in to change notification settings - Fork 140
Description
Describe the Feature
This is a similar idea to what Terragrunt does with their "Remote Terraform Configurations" feature: https://terragrunt.gruntwork.io/docs/features/keep-your-terraform-code-dry/#remote-terraform-configurations
The idea would be that you could provide a URL to a given root module and use that to create a component instance instead of having that component available locally in the atmos project repo.
The benefit here is that you don't need to vendor in the code for that root module. Vendoring is great when you're going to make changes to a configuration, BUT if you're not making any changes then it just creates large PRs that are hard to review and doesn't provide much value.
Another benefit: I have team members that strongly dislike creating root modules that are simply slim wrappers of a single child module because then we're in the game of maintaining a very slim wrapper. @kevcube can speak to that if there is interest to understand more there.
Expected Behavior
Today all non-custom root module usage is done through vendoring in Atmos, so no similar expected behavior AFAIK.
Use Case
Help avoid vendoring in code that you're not changing and therefore not polluting the atmos project with additional code that is unchanged.
Describe Ideal Solution
I'm envisioning this would work like the following with the $COMPONENT_NAME.metadata.url being the only change to the schema. Maybe we also need a version attribute as well, but TBD.
components:
terraform:
s3-bucket:
metadata:
url: https://github.com/cloudposse/terraform-aws-components/tree/1.431.0/modules/s3-bucket
vars:
...Running atmos against this configuration would result in atmos cloning that root module down to the local in a temporary cache and then using that cloned root module as the source to run terraform or tofu against.
Alternatives Considered
None.
Additional Context
None.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status