-
Notifications
You must be signed in to change notification settings - Fork 31
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
Feature Request: Support from-module
parameter
#8
Comments
I am all for this. I'm even thinking of a generalised approach, i.e.: within each E.g.:
Then you get access to all the underlying Terraform flags. For example, one could increase parallelism for all apply commands by doing:
Only consideration there is that users could potentially cause an issue by changing something astro doesn't expect under the hood. I can't see any catastrophic cases of that right now but it could become a problem. |
This is an important feature for greater levels of composition and versioning of infrastructure. Would love to see this implemented or help in the implementation. If you could init from a module, would it negate the need for the "path" attribute? Initially when I looked at the project, I was under the impression that the "path" attribute would act like the -from-import functionality of terraform. |
First of all, I love the direction of this utility. It's a generalized approach to orchestrated complex, multi-phased applies for terraform. It's a nice alternative to terragrunt that's less opinionated. We use a similar tool designed for
helm
that's calledhelmfile
.what
init.from-module
directive for each module.why
init
supports-from-module=SOURCE
when initializing a moduleterragrunt
uses) and would make it easier to dropterragrunt
and useastro
insteadexample
This example would copy the
/aws/app
module tocore/app
and then invoke the commands accordinglyThe text was updated successfully, but these errors were encountered: