Allow flux build kustomization --recursive and replacing all sourceRef GitRepository

[cep21]

If the output of flux build kustomization also includes kustomize.toolkit.fluxcd.io/v1beta1 objects of type Kustomization, then expand and build those as well. Similarly, if they include HelmRelease objects recursively build those.

Rather than take a --path option, take an option to specify the sourceRef GitRepository as the current (or another) git repository (or some other base).

In my case, I want to preview what a release will look like inside CI/CD. We could --path, but there are lots of paths. The real thing I want is to just say "Pretend sourceRef X is my current git repository`. With that, it should be able to infer the correct paths (other source refs can remain the same) and the expected final state.

This could be expanded to include the diff subcommand as well.

This is similar to #2434 and #820, but we're expanding it to all flux native types and allowing recursive expansion.

[souleb]

Hi,

The flux build kustomizationand flux diff kustomization replicate the kustomize-controller behavior, which does not recursively render Kustomization custom resources. Also I find it impractical. For example, if you include an object of type kustomization which depends on a resource being applied at the same time (e.g. a namespace), when the kustomization is applied, the dependet object does not exist as we merely do a dry-run. What would the build/diff` output then?

Specifying a non-local source is a good idea, but we need to take into account credentials, we cannot assume that we have locally access to the secret used by the in-cluster gitrepository cr.

[cep21]

we need to take into account credentials

For CI/CD I just need to specify my current checkout.

What would the build/diff output then?

I agree that flux2 seems to work best with minimal flux Kustomize objects. I think it's fine if at the start, it just doesn't render these namespace objects. The more important situation for our CI/CD is breaking existing namespaces (since that's getting production traffic) rather than breaking new namespaces (since new namespaces are obviously not yet serving production traffic).

[banschikovde]

@souleb
We have a similar need in our clusters running Flux2

If the output of flux build kustomization also includes kustomize.toolkit.fluxcd.io/v1beta1 objects of type Kustomization, then expand and build those as well. Similarly, if they include HelmRelease objects recursively build those.

Rather than take a --path option, take an option to specify the sourceRef GitRepository as the current (or another) git repository (or some other base).

In my case, I want to preview what a release will look like inside CI/CD. We could --path, but there are lots of paths. The real thing I want is to just say "Pretend sourceRef X is my current git repository`. With that, it should be able to infer the correct paths (other source refs can remain the same) and the expected final state.

This could be expanded to include the diff subcommand as well.

This is similar to #2434 and #820, but we're expanding it to all flux native types and allowing recursive expansion.