Update go version in go.mod

[yannh]

Follow up to #268

[nbarrientos]

Hi @yannh !

Just for my own education so I understand how the project moves forward, may I ask why is Go 1.22 required? Leaving 1.21 behind breaks compatibility with platforms where Go 1.21 is only available, like RHEL9.

Thanks.

[yannh]

Hi @nbarrientos ! It's not required, I just bump the go version regularly in master to stay ahead of security issues and benefit from go performance improvement. It should build using an older version of Go with no problem - are you rebuilding from sources for RHEL? If yes you might need a small sed/patch for the go.mod to change the version.

[nbarrientos]

Hi!

Thanks for your message! Go 1.21 should be receiving security updates until 1.23 is released so in that front you should be covered.

Yes, I'm building it by calling go install. It'd be nice though if kubeconform could be built vanilla in a reasonable modern Linux distribution like RHEL 9.4 without having to hack go.mod in a pre-build step :) It's okay for me as well to use an older release which is what I'm doing at the moment but at some point this approach might no be viable anymore.

Up to you, I was just curious about the recently Go 1.22 enforcement.

[bitti]

I have the same problem, but I think I found a solution for RHEL 9 without patching go.mod. Just install 1.22 as a package:

go install -v golang.org/dl/go1.22.3@latest \
   && ~/go/bin/go1.22.3 download \
   && ~/go/bin/go1.22.3 install github.com/yannh/kubeconform/cmd/kubeconform@latest \
   && install -o root -g root -m 0755 ~/go/bin/kubeconform /usr/local/bin/

Also works in RHEL 8 btw.

[nbarrientos]

Yup, that's indeed an option. In our case though it'd not be applicable because we try to always avoid "artificially" changing the version of development tooling shipped by the distribution so when we work on a given system we know always what version of Libc, Go, Python, etc to expect.

[bitti]

Yup, that's indeed an option. In our case though it'd not be applicable because we try to always avoid "artificially" changing the version of development tooling shipped by the distribution so when we work on a given system we know always what version of Libc, Go, Python, etc to expect.

The beauty of my proposed solution is that the alternative Go version gets only installed locally at ~/go/bin/go1.22.3. The distributed version doesn't change.