-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Golang 1.13.8, start testing on Go 1.14 #2239
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). |
env: | ||
- RUNC_USE_SYSTEMD=1 | ||
script: | ||
- 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.11.x | ||
- 1.12.x | ||
- 1.13.x | ||
- 1.14.x | ||
- tip |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we already have tip
to test on the latest version, no need to have 1.x
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.14
I 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also filed travis-ci/gimme#185.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is finally allegedly fixed, so #2538
superseded by 3147c32 |
Follow up to #2234