Describe the solution you'd like
There are cases where certain variables are needed across the entire repo, and oftentimes the default value is the same. E.g., in our architecture catalog, the AWSAccount, IsEnvCommon, IncludeCommonVars, etc.
Right now, boilerplate requires that each of these variables be defined in every single boilerplate template config if they need to be set with a default. This can lead to a lot of duplication.
Describe alternatives you've considered
The only workaround I can think of is to have a default varfile when invoking boilerplate. This takes advantage of the fact that boilerplate variable definitions are not strict (as in, you can pass in and reference variables that are not defined in boilerplate.yml).
So you can do this by convention: essentially, you have a file that defines the global variables that all boilerplate templates can reference by convention.
The downsides of this approach are:
You have to make sure that the variables are passed in when invoking boilerplate.
Since it's by convention, it can be difficult to orient oneself as there is room for many different projects to adopt different ways of achieving this.
Additional context
Originally requested by a customer.
Describe the solution you'd like There are cases where certain variables are needed across the entire repo, and oftentimes the default value is the same. E.g., in our architecture catalog, the
AWSAccount,IsEnvCommon,IncludeCommonVars, etc.Right now, boilerplate requires that each of these variables be defined in every single boilerplate template config if they need to be set with a default. This can lead to a lot of duplication.
Describe alternatives you've considered
The only workaround I can think of is to have a default varfile when invoking boilerplate. This takes advantage of the fact that boilerplate variable definitions are not strict (as in, you can pass in and reference variables that are not defined in
boilerplate.yml).So you can do this by convention: essentially, you have a file that defines the global variables that all boilerplate templates can reference by convention.
The downsides of this approach are:
Additional context Originally requested by a customer.
Also see https://github.com/gruntwork-io/boilerplate/pull/65 for past discussion on a similar feature.