Make flux bootstrap commit messages descriptive

[hiddeco]

At present, running flux bootstrap will always commit with the same commit message: Add manifests. This does not tell the user much about the change in the commit when they are inspecting the Git repository using e.g. git log.

The commit message should be changed to something that includes the version, or maybe even include if it was an install or an upgrade.

In addition, we may want to list the versions of all (changed) controllers in the long commit message.

[kingdonb]

Do you think #904 went far enough, or should we go further and add the versions of which controllers have been changed to the commit message?

[kingdonb]

I think there is another enhancement that would be nice, somewhat unrelated, (but if I'm picking this issue up I can maybe handle both) -- flux version tells you what version of CLI you are running and what version of controllers are on the cluster, but it does not tell you about any diff. It should at least tell users if flux bootstrap to upgrade would provide new versions of any controllers.

[stefanprodan]

flux version tells you what version of CLI you are running and what version of controllers are on the cluster, but it does not tell you about any diff.

Nor does kubectl version or any other CLI that I've used so far. The flux check command is where we show a "diff", currently only for the CLI version.

[kingdonb]

As a suite of microservices, I think there are some enhancements that Flux could offer that wouldn't have made sense in other monolithic services like Kubernetes proper. The flux check command came up too. It would be great if either or both of these commands did a little more with the data that they collect, since many users won't know or want to know which kustomize-controller release was in the latest flux release, and tying this information together can be a manual process for users who don't have custom-built platform support or their own mechanisms for keeping environment/platform up to date and in sync.

Since there are some annotations on the namespace that we could check, it would be easy (sounds like I'm volunteering...) to make flux version tell about the diff between cluster bootstrapped version and CLI version:

https://github.com/kingdonb/bootstrap-repo/blob/467474374b4b3b6876f896dd05edff668cef3657/clusters/moo-cluster/flux-system/gotk-components.yaml#L11

kubectl version is a good example too, but I think it's not doing as much as it could. The kubectl command does present the server version next to the client version, but does not attempt to perform any diff or tell you if it might be time for an upgrade.

The kubectl CLI however does warn on every command if your CLI has a version skew that is outside of the compatible range, for example when the server is on 1.20.x and client is on 1.22.x. If we are using that as a model, then flux CLI will become very annoying to use when the versions don't match exactly, (or if we don't find any match inside of the same minor release?) I don't think we have a version skew policy, I think users are expected to use a matching version everywhere. Maybe we can warn them like kubectl CLI does.

Fortunately when it comes to diffing version numbers, we also don't have to contend with the same mess of version numbers that are in kubectl version for Flux:

Client Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:41:28Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"22", GitVersion:"v1.22.3", GitCommit:"c92036820499fedefec0f847e2054d824aea6cd1", GitTreeState:"clean", BuildDate:"2021-10-27T18:35:25Z", GoVersion:"go1.16.9", Compiler:"gc", Platform:"linux/amd64"}

That is about as clean as it gets, for diffing...

Server Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.5-gke.1302", GitCommit:"639f3a74abf258418493e9b75f2f98a08da29733", GitTreeState:"clean", BuildDate:"2021-10-21T21:35:48Z", GoVersion:"go1.16.7b7", Compiler:"gc", Platform:"linux/amd64"}

Things like GitVersion above. (I've also seen + metadata on OpenShift clusters.) If vendors started distributing non-conforming versions of Flux, then it would make comparisons difficult, but again I think that's also not a problem for us to deal with.

Anyway, this will have to be a separate issue since it has practically nothing to do with the original request to make flux bootstrap commit messages more descriptive.