Show distribution name in flux version and flux check

[stefanprodan]

To determine the Flux version running on a cluster, we can look for the app.kubernetes.io/part-of and app.kubernetes.io/version labels on the gitrepositories.source.toolkit.fluxcd.io CRD. If the CRD exists and has these labels, we should display the distribution name and version like so:

$ flux version
flux: v2.1.1 <2.1.2 (new CLI version is available, please upgrade)
distribution: flux-v2.0.0
helm-controller: v0.35.0
kustomize-controller: v1.0.0
notification-controller: v1.0.0
source-controller: v1.0.0

We should also display if Flux was bootstrapped in the flux check output:

$ flux check 
► checking prerequisites
✗ flux 2.1.1 <2.1.2 (new CLI version is available, please upgrade)
✔ Kubernetes 1.27.3 >=1.25.0-0
► checking version
distribution: flux-v2.0.0
bootstrapped: true
► checking controllers
....

[makkes]

Since we're at it already I suggest we change the first line from

flux: v2.1.1 <2.1.2 (new version is available, please upgrade)

to

flux CLI: v2.1.1 <2.1.2 (new version is available, please upgrade)

This line has confused people in the past because they were led to believe the line indicated the Flux version running on the cluster.

[stefanprodan]

flux CLI is a breaking change, it would also fail since the output is YAML or JSON, both don't access spaces in the key names.

[makkes]

flux CLI is a breaking change, it would also fail since the output is YAML or JSON, both don't access spaces in the key names.

I'm not particularly attached to the key's name but rather to the fact that it should somehow emphasize the fact that this is the CLI version, not the cluster version.

I know we changed the output of other commands in the past without calling this a breaking change. Would you mind elaborating on why you think this is a breaking change? Do we know of tooling that uses the output in automation?

[hiddeco]

The reason we need to be extra cautious here is because version commands are often used to programmatically detect which version a CLI is on, while the --json indicates there is some sort of stable document structure which can be easily digested.

This does not apply to many other commands, as they do not offer an -o yaml|json flag.

[hiddeco]

Do we know of tooling that uses the output in automation?

Tools are not our primary or only concern here, users their potential CI environments are. Which we have no sight on.

[makkes]

Yeah I know. That's why I was asking whether we already know of any automation out there that uses it. But I guess we wouldn't know about ops scripts running on users' infrastructure, anyway. So it seems there's no way we can ever change the output without going through a transition phase.

[hiddeco]

Here is one public example: https://github.com/equinor/radix-platform/blob/66b1901b39770415bf70a1a813d5b0e41687365b/scripts/flux/bootstrap.sh#L133

[stefanprodan]

We can change the warning to (new CLI version is available, please upgrade)

[stefanprodan]

I know we changed the output of other commands in the past without calling this a breaking change.

That was before GA, the flux version command is GA, it doesn't have the note like others commands:

⚠️  Please note that this command is in preview and under development.
While we try our best to not introduce breaking changes, they may occur when
we adapt to new features and/or find better ways to facilitate what it does.

Do we know of tooling that uses the output in automation?

I've seen CI workflows in large Flux deployments who rely on the json output to extract the version and perform automated upgrades of Flux across many clusters. Changing the key from flux to something else, would break them.