Fix for image failing to build due do gomega requiring golang 1.16 in 3.0.0

[edcdavid]

Fix image build in previous versions.
Seems like gomega is requiring go 1.16 now...: the build script failed in 3.0.0 when building gomega.
To resolve this issue and similar ones in the future:

• even when building older branch always checkout the latest build scripts and Makefile
• checkout the latest dockerfile
• When modifying the Makefile, github workflow, Dockerfile, consider that it will be used bu all release so it has to be backward compatible.

[javierpena]

Looking at the build logs, I see gomega v1.16.0 is installed first, but then it is upgraded to v.1.17.0. Why would that happen in the 3.0.x branch, if it requires 1.16.0?

[javierpena]

After some more thought, I see the issue happens when we run "make install-tools" in the container build.

That does a "go get github.com/onsi/gomega/..." which downloads the latest version of gomega (1.16.5) instead of the one specified in go.mod (1.16.4), and even updates go.mod to include the latest version. This is a bad idea in a stable branch, is there a way we can instruct go get to use the exact version in go.mod and not update?

[sebrandon1]

@javierpena According to the Go docs, go install is supposed to default to the version listed in the go.mod however in practice, that's not what we were experiencing when we attempted to tackle this before. It seems more like a bug in Go than anything.

[javierpena]

@javierpena According to the Go docs, go install is supposed to default to the version listed in the go.mod however in practice, that's not what we were experiencing when we attempted to tackle this before. It seems more like a bug in Go than anything.

Actually, "go install" seems to do the right thing in this case, while "go get" tries to update go.mod. Maybe that's all we should do?

[javierpena]

IMHO, this is creating a complex mix of the stable and main branches when building the container image, and it can bite us in the future. We already have a similar pattern when checking out the create-version-files.sh and get-git-latest-release.sh scripts from main.

I think it might be easier to add a commit that fixes the Makefile to the 3.0.x branch, and then add a v3.0.1 tag including it. The GitHub action would then pick the new tag and use it to build the container, without the issues we are seeing today.

I see that using Dockerfile from the main branch also pulls new Go and OC client versions. If that is what we want, we can also cherry-pick those changes to the 3.0.x branch.

[edcdavid]

Will be solved in 4.0