jx
jx copied to clipboard
jx version may show incorrect golang version
jx version may show incorrect golang versions. We hard code it to a value: https://github.com/jenkins-x/jx/blob/366fb476158989cf1f12d9cbe6f722bca635cda6/.github/workflows/jenkins-x/upload-binaries.sh#L16 It should instead derive the value from the image it's using to run the goreleaser step in the release pipeline.
Locally we get it from the environment: https://github.com/jenkins-x/jx/blob/366fb476158989cf1f12d9cbe6f722bca635cda6/Makefile#L16
As an additional issue, I think we should enforce some sort of conditon so that the go version in the dev machine matches the version in the catalog.
The benefit is that we can change this value in a PR and trigger a new jx build when the go version in the catalog changes. We actually do this for most of the repos (we really need to have similar set up in all repos, this non-standard thing will make things harder to debug and maintain)
/assign @osamamagdy
It should instead derive the value from the image it's using to run the goreleaser step in the release pipeline.
So it's basically should be export GOVERSION=$(go version | sed -e 's/^[^0-9.]*\([0-9.]*\).*/\1/')
in jx/.github/workflows/jenkins-x/upload-binaries.sh
As an additional issue, I think we should enforce some sort of condition so that the go version in the dev machine matches the version in the catalog.
We actually do this for most of the repos
@ankitm123 Can you provide one repo with this?
https://github.com/jenkins-x-plugins/jx-pipeline/blob/d9dea25fa3c8afc88bede2bfbb22fefb7dc8d3da/Makefile#L16 -> But this only solves part of the problem. This does not mean that the version is actually being used to build the binary. For example I can set GO_VERSION to 1.23.5 (not a real version), and run make build
, and it wont complain ...