search

yannh / kubeconform

A FAST Kubernetes manifests validator, with support for Custom Resources!
Apache License 2.0
2.07k stars 116 forks source link

Update go version in go.mod #269

Closed yannh closed 2 months ago

yannh commented 2 months ago

Follow up to https://github.com/yannh/kubeconform/pull/268

nbarrientos commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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 commented 1 month ago

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 commented 1 month ago

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.