Version commit hash

[ehearneRedHat]

What:

Added version commit hash implementation similar to authorino and limitador-operator

How:

• Check Dirty script checks to see if branch has uncomitted changes and reports dirty if so .
• Target level vars for specific targets that require ldflags in Makefile.
• Dockerfile and workflow now reference new vars

Verify:

• make build (requires kind create cluster be ran first)
• make docker-build (load image into cluster)
• make run (requires kind create cluster be ran first)

Specified make targets should run fine with new information in their logs when checked such as the version, whether the branch had changes (i.e. dirty) and also the commit hash. Below is an example of what that may look like.

2024-07-22T13:48:24+01:00       INFO    setup   dns-operator 0.4.0-dev (96475e401ed30c233419dc31632e2ed6729f708a)

Workflow runs successfully --> https://github.com/Kuadrant/dns-operator/actions/runs/10055959082

Image, bundle image and catalog image from workflow install fine and image/bundle image displays new changes.

[mikenairn]

Adding version info the the dns operator and exposing it in the runtime logs is a good idea and something we intended to do at some point, so thanks for starting that.

However, I'm looking through the other repos and issues you linked and nothing about the way we are doing it in each repo is aligned, each is doing it differently still from what i can gather. Looks like we are also in each PR changing it based on whatever feedback your are getting on each PR which won't really work if we are trying to go for a common approach across all repos. Do you have a repo that has been updated with the changes we intend to make in them all?

Would it be worth picking a repo, implementing version info changes in it(on a branch), and getting agreement that all four main golang based operator repos follow the same setup? I agree in most part with what is said here, but i would expect to see automation in place that ensures that version file is as expected on each branch.

The dirty flag also, while i can see the need for it, doesn't really make much sense in a semantic version string. I prefer how this operator has done it making it explicitly about the state of the git repo which it is https://github.com/hashicorp/vault-secrets-operator/blob/dcfee8e513e198aafad467ae71ec5cdd39269282/scripts/ldflags-version.sh#L51-L53

[ehearneRedHat]

Do you have a repo that has been updated with the changes we intend to make in them all?

No, there isn't a particular repo in which a universal implementation is made. As you mentioned, I have been implementing each one by one.

Would it be worth picking a repo, implementing version info changes in it(on a branch), and getting agreement that all four main golang based operator repos follow the same setup?

That makes sense. That way, the implementation can remain the same.

The dirty flag also, while i can see the need for it, doesn't really make much sense in a semantic version string. I prefer how this operator has done it making it explicitly about the state of the git repo which it is

I can see where you're coming from... I anticipate some changes will be needed for this implementation to be universal.

Okay, so your suggestions are to determine a universal implementation strategy across all four operators, to be done through a PR so that anyone who make suggestions can so that we can come to an agreement, and then within that agreement, ensure the suggestion of how the aformentioned operator repo implemented "dirty" ? Also, to have a separate version file for version.

[eguzki]

Adding version info the the dns operator and exposing it in the runtime logs is a good idea and something we intended to do at some point, so thanks for starting that.

However, I'm looking through the other repos and issues you linked and nothing about the way we are doing it in each repo is aligned, each is doing it differently still from what i can gather. Looks like we are also in each PR changing it based on whatever feedback your are getting on each PR which won't really work if we are trying to go for a common approach across all repos. Do you have a repo that has been updated with the changes we intend to make in them all?

Would it be worth picking a repo, implementing version info changes in it(on a branch), and getting agreement that all four main golang based operator repos follow the same setup? I agree in most part with what is said here, but i would expect to see automation in place that ensures that version file is as expected on each branch.

The dirty flag also, while i can see the need for it, doesn't really make much sense in a semantic version string. I prefer how this operator has done it making it explicitly about the state of the git repo which it is https://github.com/hashicorp/vault-secrets-operator/blob/dcfee8e513e198aafad467ae71ec5cdd39269282/scripts/ldflags-version.sh#L51-L53

I also wish we had the same implementation in all the operators. But each operator has it's owners and preferences. It's been hard to have a common implementation. Fortunately, even though the how differs (slightly), the what (what matters) is pretty much the same.. specified in here. And TBH, that is good enough for me. All operators will log a line with the versioning based on version, commitID and dirtyness.

Operators and CLI based components differ in the sense that CLI have a version or help command where this information is made available. Whereas the controllers only have the log line at boot time.

I am happy if we do a second iteration on all four operators, kuadrant, authorino, limitador and dns and converge on implementation details.

[eguzki]

some changes pointed out

[ehearneRedHat]

@mikenairn pinging for review since @eguzki is on PTO for 3 weeks. 😄

[ehearneRedHat]

@mikenairn sorry for taking a while to get back to this PR... I was PTO last week and have been catching up with another PR previous .

I've amended changes where there wasn't any questions I had for the suggestions. As for the rest, I'll await your response first :)

[eguzki]

overall LGTM

I left one nit, though

[mikenairn]

Changes look fine. As discussed offline, consider looking into using rebase to bring your dev branch up to date with the base(main) to avoid unnecessary merge commits.

I'll force a squash merge on this one.