When installing go we always checked if GIMME_GO_VERSION (default installed version in docker 1.19.x) does not equal installGoVersion (users version from GO_VERSION or default 1.19.x).
If they do not equal we would resolve installGoVersion and install it by calling gimme.
Otherwise we would install the version from GIMME_GO_VERSION.
Checking the history GIMME_GO_VERSION was always identical to the default installGoVersion unless the user changed it, but in #870 both default value were changed to be 1.19.x. Two problems with that:
We tried to source the env file with GIMME_GO_VERSION (the unresolved version), but gimme always resolves before installing, so there is no env file for 1.19.x (this seems to have been broken since #870)
Now that 1.19.4 was released, 1.19.x resolves to it, but in the build-image we have 1.19.3 installed.
The change simplifies the code and always checks if the actual resolved version from installGoVersion is already installed or not. GIMME_GO_VERSION is not used anymore as it really does not matter, either the requested go version is installed or not.
This has one downside though: we always call gimme --resolve which goes to network for .x versions, but caches known versions for 3 hours by default, I changed that to 7 days, but that is debatable. That means that when 1.19.5 is released it might take up to a week before users with a go version of 1.19.x will get that new version. (The actual check in gimme uses the file creation time, so I do hope our caching preserves file creation times)
What I did not understand what gimme | bash was supposed to do? It installs GIMME_GO_VERSION by default, but why the pipe to bash? gimme returns a bash script, so the source call we had in the script did source the script a second time.
The alternative is to simply revert all the default versions from 1.19.x to 1.19.4, BUT bitballon currently freezes 1.19.x to new user accounts, so in any way the builds would get a installGoVersion of 1.19.x
For us to review and ship your PR efficiently, please perform the following steps:
[ ] Open a bug/issue before writing your code 🧑💻. This ensures we can discuss the changes and get feedback from everyone that should be involved. If you`re fixing a typo or something that`s on fire 🔥 (e.g. incident related), you can skip this step.
[ ] Read the contribution guidelines 📖. This ensures your code follows our style guide and passes our tests.
[ ] Update or add tests (if any source code was changed or added) 🧪
Summary
Fixes https://github.com/netlify/pillar-workflow/issues/1025
When installing go we always checked if
GIMME_GO_VERSION(default installed version in docker1.19.x) does not equalinstallGoVersion(users version fromGO_VERSIONor default 1.19.x).If they do not equal we would resolve
installGoVersionand install it by calling gimme.Otherwise we would install the version from
GIMME_GO_VERSION.Checking the history
GIMME_GO_VERSIONwas always identical to the defaultinstallGoVersionunless the user changed it, but in #870 both default value were changed to be1.19.x. Two problems with that:GIMME_GO_VERSION(the unresolved version), but gimme always resolves before installing, so there is no env file for 1.19.x (this seems to have been broken since #870)The change simplifies the code and always checks if the actual resolved version from
installGoVersionis already installed or not. GIMME_GO_VERSION is not used anymore as it really does not matter, either the requested go version is installed or not.This has one downside though: we always call
gimme --resolvewhich goes to network for.xversions, but caches known versions for 3 hours by default, I changed that to 7 days, but that is debatable. That means that when1.19.5is released it might take up to a week before users with a go version of1.19.xwill get that new version. (The actual check in gimme uses the file creation time, so I do hope our caching preserves file creation times)What I did not understand whatgimme returns a bash script, so thegimme | bashwas supposed to do? It installs GIMME_GO_VERSION by default, but why the pipe to bash?sourcecall we had in the script did source the script a second time.The alternative is to simply revert all the default versions from 1.19.x to 1.19.4, BUT bitballon currently freezes 1.19.x to new user accounts, so in any way the builds would get a
installGoVersionof 1.19.xFor us to review and ship your PR efficiently, please perform the following steps:
A picture of a cute animal (not mandatory, but encouraged)