Update Golang 1.13.8, start testing on Go 1.14#2239
Update Golang 1.13.8, start testing on Go 1.14#2239thaJeztah wants to merge 6 commits intoopencontainers:masterfrom
Conversation
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Move adding the source code to the end, so that the busybox rootfs doesn't have to be fetched again on each code change. Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
|
This is very much needed, because despite having a bunch of versions in .travis.yml we only test on golang 1.12 (and do it many times, unnecessarily overloading travis). |
| - make BUILDTAGS="${BUILDTAGS}" all | ||
| - sudo PATH="$PATH" make localintegration RUNC_USE_SYSTEMD=1 | ||
| - go: 1.12.x | ||
| - go: 1.13.x |
There was a problem hiding this comment.
One thing I don't understand here (maybe just because it's slow Saturday) is why there is only a single versoin of go (such as go: 1.13.x) in this matrix.
| - 1.12.x | ||
| - 1.13.x | ||
| - 1.14.x | ||
| - tip |
There was a problem hiding this comment.
To avoid having to update this every time, we should have a 1.x entry so we're always testing the latest release.
There was a problem hiding this comment.
Not sure. That way we wouldn't be testing "latest - 1", would that be an issue? (go supports last two versions, and not everyone may be on latest on day 1)
Also it would mean CI "silently" switching to a new Go version, which could be confusing why things all of a sudden start to fail
There was a problem hiding this comment.
we already have tip to test on the latest version, no need to have 1.x.
There was a problem hiding this comment.
tip tests the latest build of Go master, not the latest released version. This would be like testing against nightly in the Rust world (useful, but not as useful as testing against the latest release).
I wasn't saying to remove the latest - 1 line (annoyingly Travis doesn't support this concept), I was just saying we should add 1.x.
There was a problem hiding this comment.
I wasn't saying to remove the latest - 1 line (annoyingly Travis doesn't support this concept)
I just found they actually do! Travis is using gimme (https://github.com/travis-ci/gimme) for installing go versions, and this is what it gives to me
[kir@kir-rhat runc]$ gimme -r oldstable
1.13.8
[kir@kir-rhat runc]$ gimme -r stable
1.14
[kir@kir-rhat runc]$ gimme -r 1.x
1.14I also learned that tip means "get go it from git and compile" and I am not sure we want it.
So, since golang supports two versions, we can use stable and oldstable and catch the problems early. I think @thaJeztah would say that specifying versions explicitly is always better because we know what we use, and it won't break suddenly because of golang 1.23 (or whatever) is released. To that, I'd say (1) we have to support supported go releases, and if something breaks we need to take care ASAP (2) it is not ideal, but better than the current situation then we test everything on two unsupported go releases.
There was a problem hiding this comment.
👍 to using oldstable and stable.
I also learned that tip means "get go it from git and compile" and I am not sure we want it.
Yup, that was what I was trying to say earlier.
There was a problem hiding this comment.
OK, the bad news is for some reason oldstable is not working for Travis CI (which uses the very same version of gimme that I did above so I'm not sure why).
Reported earlier (perhaps to a wrong place)
travis-ci/gimme#179
I have reported it as well (hopefully to the right place)
https://travis-ci.community/t/cant-specify-oldstable-as-go-version-in-travis-yml/7670
|
superseded by 3147c32 |
4 participants
Follow up to #2234