Bring manifest consumption in CI process in-line with user documentation
while we're building single manifest for generic deployments our test script wants to dynamically modify namespace and deploy there... one way to do it would be to return kustomize edit ... statement that modifies namespace, another is to setup tests as kustomized manifests of what's already produced. That also means we'll need to carefully save manifests and ship them around and use kustomize just like our customers would (which I think is the goal anyway).
Currently we produce manifest "on-the-fly" for tests - i.e. we're not using the same methodology we offer to our users with kubectl apply -f https://... what needs to be done:
-
we need a separate
kustomizedirectory for the tests (.build/kustomize?)- under
.build/kustomizecreate dynamicallykustomization.yamlthat uses.build/operator.yamlas a base layer and overrides "namespace" into which tests will be deployed.
- under
-
refactor pipeline so that
.build/operator.yamlis generated once with "generic" values and we consume that same artifact across entire pipeline rather than re-generating it
Product of this work could be used to outline for users how deployment of default published Operator manifest can be customized to their environment (change namespace or adjust names with prefixes/suffixes)