What’s the recommended method for centralizing the draft create process to be able to orthogonalize the application logic from the infra logic?
To illustrate what I’m getting at here, notice how in https://github.com/Azure/draft/tree/master/packs, many of the packs have very similar or identical pieces inside their charts/* directories. Wouldn’t it be nice if that chart could be commoditized and overlaid on top of an arbitrary application repository, provided their Dockerfile builds and runs?
Or even better (but this would be exceeding expectations) if draft could point to a chart that is externally packaged somewhere (eg. github) rather than necessarily having to be located inside the application repository. In these cases, among other more substantial considerations, we’re hit with the limitation of the chart having to live in a directory with the same name as the chart (until helm v3).
What’s the recommended method for centralizing the
draft create
process to be able to orthogonalize the application logic from the infra logic?To illustrate what I’m getting at here, notice how in https://github.com/Azure/draft/tree/master/packs, many of the packs have very similar or identical pieces inside their
charts/*
directories. Wouldn’t it be nice if that chart could be commoditized and overlaid on top of an arbitrary application repository, provided theirDockerfile
builds and runs?Or even better (but this would be exceeding expectations) if draft could point to a chart that is externally packaged somewhere (eg. github) rather than necessarily having to be located inside the application repository. In these cases, among other more substantial considerations, we’re hit with the limitation of the chart having to live in a directory with the same name as the chart (until helm v3).