Repository navigation
Package sources and conflicting file names for raw templates #667
Description
In the following scenario you would end up with two VPC stacks. Is there way to force a certain raw package to be used when defining template_path?
package_sources:
git:
- uri: git@github.com:SomeUser/vpc.git
- uri: git@github.com:SomeUser/config.git
stacks:
- name: vpc
template_path: cloudformation.yaml
- name: config
template_path: cloudformation.yaml
Activity
kddejong commentedon Oct 10, 2018
I would add I tried to work around this a little bit by using a master git repo with git submodules but it doesn't look like the clone handles submodules
phobologic commentedon Oct 23, 2018
@troyready any comments on this? I haven't dug into the package_sources stuff in a while.
troyready commentedon Oct 23, 2018
Unhelpful background to start: the template_path is modeled after the class_path behavior: first one matching/found is used. If the paths aren't specific enough in either scenario, it'll be unpredictable and not great.
Since python packages are a little more particular in directory traversal (if the first matching directory in sys.path matches the directory specified for class_path, then it won't fall back to other directories if that first directory doesn't have the expected module), I just recommend making the paths more specific.
kddejong commentedon Oct 23, 2018
I was kind of thinking that would be the response but wanted to ask anyways.
I was hoping for one of two solutions. One was where I could specify the package source when specifying the template name the other would be an error when duplicates are found.
The scenario I am thinking of is when we build out an AWS account I may have 10-15 templates that are used to setup all the different components, networks, security, roles, etc. If someone adds a new repo with a template name that matches another then we could have some disastrous results.
While I haven't tried if I could do a pre-build step to verify this myself. As long as pre-build runs after the packages are collected.
troyready commentedon Oct 23, 2018
A colleague of mine had similar designs to associate the template_path (or class_path) with a particular package_source. Some sort of metadata on the package_source that could be referenced in the stacks/hooks.
I chose not to implement it for the current template_path option for simplicity (and fear of adding yet_another_config_option), but wouldn't be opposed to having it.
For now, because you can store templates in subdirectories (and further restrict what templates are searched using the paths option, I think it's possible to be specific enough to make the template sourcing predictable.
phobologic commentedon Oct 23, 2018
Ok, changed the labels in case this is a feature that someone wants to take on. Thanks @troyready !