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:

  1. we need a separate kustomize directory for the tests (.build/kustomize ?)

    • under .build/kustomize create dynamically kustomization.yaml that uses .build/operator.yaml as a base layer and overrides "namespace" into which tests will be deployed.
  2. refactor pipeline so that .build/operator.yaml is 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)

Edited by Dmytro Makovey