Add a flag for customizing PROJECT file location

[porridge]

What do you want to happen?

Feature

Add a --project-file flag to allow overriding the hardcoded PROJECT path.

Motivation

Temporarily using modified project configuration, without dirtying the project git repo.

My use case

Note: I specifically need this just for the helm/v2-alpha plugin, but it seems that the most straightforward way to add this is on the top level.

The description below is basically condensing of the related slack discussion.

My project needs to build two flavors of the helm chart (upstream vs. downstream) where the primary difference is the project name (which prefixes most/all resource names). The whole project has a notion of branding all the way to its web UI, so we don't need to use separate git repos for the two flavors.

For the plain YAML installer and OLM-related manifests we achieve the distinction by using parallel kustomization directories, one is selected at build time via an env variable.

However the helm/v2-alpha plugin depends on the project name which is hardcoded in the PROJECT file, the config is loaded here, then injected here and used for example here by the plugin. Specifically, value for the chart name unconditionally depends on the project name from the config. So it's not possible to customize it using kustomize.

The path to the PROJECT file in turn is the currently hardcoded.

Possible solutions

Option 1

My current workaround is to temporarily sed -e 's,^projectName: flavor1,projectName: flavor2,' PROJECT and restore it afterwards. Ugly, and temporarily dirties the git repo, which has ripple effects, which we need to work around using another kludge on top. 🤮

Option 2

Create a small, private, special-purpose binary that uses kubebuilder as a Go library, that allows for overriding the path. However it looks like I would need a custom version of the preRunEFunc helper that allows overriding the path unlike the upstream one which loads it from the hardcoded path at the moment. That in turn probably also means a custom applySubcommandHooks, all in all duplicating a lot of existing code 😟

Option 4

Introduce a --project-file flag. Doing it on the root level, instead of only for the helm/v2-alpha plugin means that changes can be limited to the pkg/cli package.

Option 5

Introduce a --project-name flag in kubebuilder. This would meet my specific use case, but:

• it seems the plumbing would be a bit more involved than option 4, and
• less future-proof. I mean: --project-file allows killing more (future) birds with one stone, without introducing additional flags in case someone needs to override yet another thing defined in PROJECT

Extra Labels

No response