Pinning go version 1.20 which is the same used to release

[camilamacedo86]

Note that we are using go 1.20 to do the release (https://github.com/foundriesio/fioctl/blob/main/.github/workflows/release.yml#L21) but all other places still pinning go 1.19.
So, this PR ensure that we are using go 1.20 across all places

Tests made locally

• build
• login with oauth URL to fioed
• list waves for a facotry

Signed-off-by: Camila Macedo [email protected]

[vkhoroz]

@camilamacedo86 There are 2 different things:

• What compiler version to use.
• What runtime version to use.

So, the GitHub action only tells to use Golang version 1.20 compiler; which supports quite a few lower version runtimes (and associated libraries).
The current runtime version we use is Golang 1.19; which is properly represented across the board.

Golang runtime version 1.20 had specific problems in the past with cryptography functions we use.
They seem to be resolved in the latest 1.20 version; but there is no warranty that there are no other problems.

Given the above, the fact that Golang 1.20 does not bring us apparent added value, and the fact that we have no resource for full regression testing...
...I advice to not pursue this effort until better times.

[camilamacedo86]

Hi @vkhoroz,

That's fine. If a full regression test is necessary, it might be more efficient to directly aim for version 1.22. This way, we'd invest our efforts only once.

I'm curious, though - why are we compiling with version 1.20 while conducting tests and other tasks with version 1.19? I didn't quite catch the rationale behind this approach. Is that to try address CVEs?

Just to share: I attempted to build with version 1.21 and encountered an issue: undefined: cobra.EnableTraverseRunHooks. It seems we might already be facing some inconsistencies with future versions.

Anyway I am closing this one

[vkhoroz]

why are we compiling with version 1.20

I have no idea about that; looks like some kind of innocent slippery when adding the GitHub Action.
When building, Golang always honors a version specified in go.mod, as long as it is the same or lower than a compiler version.

I don't think we need to worry about that as long as it works.

[vkhoroz]

@camilamacedo86 grepping history releaved this: 26d8ecd.

So, it is not unintentional, bug rather @doanac was fixing a weird compiler bug.
Anyway, my claims that the runtime version used is 1.19 still stay; thus all places where we don't see that bug need to stick to that.