Separate go version for build and go version for compatibility

[bnevis-i]

🚀 Feature Request

Relevant Package [REQUIRED]

N/A

Description [REQUIRED]

EdgeX does this wierd thing that other go packages don't do. We parse go.mod for the go version, and then feed that into our BUILDER_BASE to figure out what version of the compiler we are going to use.

What we should be doing is using go.mod to declare what go version our code is COMPATIBLE WITH (i.e. language features) and keep the version that we compile with separate. If one reads the spec for the go directive https://go.dev/ref/mod#go-mod-file-go one can see that this is what was intended.

Describe the solution you'd like

Have a .go-version file that specifies the go version that we want to COMPILE WITH. Leave go.mod specify the go version we are COMPATIBLE WITH.

[lenny-goodell]

@ernestojeda, FYI

[ernestojeda]

Yeah, I am OK with this. This really only applies to optimizing local builds. During the CI process, Jenkins always set it's ownBUILDER_BASE.

[lenny-goodell]

@ernestojeda, How does this apply to local builds?
I thought the go version in the go.mod was used by CI to determine which to use in the pipeline. I.e. if rebuilding Jakarta it will use the go version we set for Jakarta.

[ernestojeda]

The GO_VERSION variable was added to the Makefile specifically to support optimizing local builds, used to determine the Dockerfile from the ci-build-images repository. This behavior is not used for Jenkins builds.

However, you are correct about LTS builds (like Jakarta), we use the go.mod file to determine what version of Go to use (using the getGoModVersion() function) for the build so we make sure we build with a consistent version. For all the rest of the Jenkins builds, we set the Go version for all projects here.

[lenny-goodell]

The GO_VERSION variable was added to the Makefile specifically to support optimizing local builds, used to determine the Dockerfile from the ci-build-images repository. This behavior is not used for Jenkins builds.

Ahh, ok wasn't aware of this as it is only in edgex-go and for docker builds. THX!

[cloudxxx8]

move to DevOps WG
@ernestojeda please help see if we want to continue to discuss this issue or just close it. thanks.

[ernestojeda]

@cloudxxx8 Up to @bnevis-i on this one. We can proceed with his suggestion about adding a new file to the repository. After that is complete, DevOps can update the build process to use this new file.

[bnevis-i]

I think it is in our long-term best interest to go forward with this (otherwise I wouldn't have proposed it).

For example, the SPIRE project has logic in their Makefile to check the go version, and if it doesn't match what it expected, it will download the correct version of the go compiler and compile against it.

I am not necessarily suggesting that we do what SPIRE does (e.g. we could just warn), but the big change is that it will eliminate a superfluous change in go.mod that causes large cascading effects to downstream consumers of the modules.

(P.S. When building our version of SPIRE, we just overwrite .go_version with the version that we are currently standardized on.)