Adding basic support for Imports (template composing) #4
Conversation
|
Not sure. I think the mental burden on users may be a little much if people start spreading root-level stage definitions all over the place. Would like to see how this initial set of capabilities works for people, and if it is truly necessary and not unreasonable, we could revisit. |
| become ignored: | ||
|
|
||
| * `source`: Imports cannot inherit from other templates or other Imports. | ||
| * `imports`: Imports cannot include other Imports. |
There was a problem hiding this comment.
I'm curious about why this wouldn't be allowed (not sure if it would be a good idea, but I'm imagining someone might want to put together a module that's composed of other modules).
There was a problem hiding this comment.
No technical reason except limiting scope of the feature. Definitely some niceities in allowing recursive imports, though.
|
|
||
| Imports can be included into a Template or Configuration using the Template | ||
| Loader syntax. The Partials and Modules contained in an Import are automatically | ||
| namespaced onced imported as `{{importId}}.{{partialId|moduleId}}` |
There was a problem hiding this comment.
I wonder if you should be able to define some sort of aliasing of your imported modules/partials. I'm envisioning a case where you want to use a parent template, but you want to override a module/partial that it uses with an imported module/partial.
As mentioned, some pipeline templates can get really long. This is a first pass at offering the ability for people to breakup templates into multiple files.
@spinnaker/reviewers PTAL