Well, in this particular case it was hard. The used version of one our internal libraries didn't support Go 1.13, so we bumped its version, and that required some more dependencies brought in and updated, and then it turned out that the container with Go 1.13 was misconfigured so it literally had no access to that internal library, at all (something with Gitlab deploy keys...), so in a hurry we tried to vendor this internal library wholesale, and then there were some problems with gomod-ed libs and those without go.mod, and some linters had to be explicitly told to skip the 'vendor' directory (wtf), and...
And at this point, I just stopped digging down that rabbit hole and instead added
before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems.
Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?
Joker_vD|5 years ago
And at this point, I just stopped digging down that rabbit hole and instead added
and before 'go install' in the build script, and ran it in the container with Go 1.10. This change took 5 minutes to make and worked without any problems.Isn't the one of the reasons we use semver in the first place so that after you do some small change to the current application you're working on, you don't suddenly find yourself having to update 2/3 of your the environment just to compile it?
Spivak|5 years ago