search

go-gl / gl

Go bindings for OpenGL (generated via glow)
MIT License
1.07k stars 74 forks source link

Travis: Update Go versions. #73

Closed dmitshur closed 7 years ago

dmitshur commented 7 years ago

Travis now refers to "tip" as "master".

Reference: https://docs.travis-ci.com/user/languages/go/#Specifying-a-Go-version-to-use.

errcw commented 7 years ago

LGTM, merge pending Travis

dmitshur commented 7 years ago

It seems to succeed on 1.8 and master, but fails on 1.5 though 1.7 with errors like:

go build github.com/go-gl/gl/v4.4-compatibility/gl: /home/travis/.gimme/versions/go1.5.4.linux.amd64/pkg/tool/linux_amd64/compile: signal: killed
# github.com/go-gl/gl/v3.2-compatibility/gl
compile: writing output: write $WORK/github.com/go-gl/gl/v3.2-compatibility/gl.a: cannot allocate memory
go build github.com/go-gl/gl/v4.5-compatibility/gl: /home/travis/.gimme/versions/go1.6.4.linux.amd64/pkg/tool/linux_amd64/compile: signal: killed
go build github.com/go-gl/gl/v4.4-compatibility/gl: /home/travis/.gimme/versions/go1.7.5.linux.amd64/pkg/tool/linux_amd64/compile: signal: killed

It looks like a Travis issue, like not having enough RAM to compile/test these large Go packages?

I'll try restarting the failed jobs, it might work on second try.

dmitshur commented 7 years ago

According to https://docs.travis-ci.com/user/ci-environment/#Virtualization-environments, the container-based environments (which we're using) should have 4 GB memory max. That should be enough.

dmitshur commented 7 years ago

I don't know what to do about this, other than remove all older versions than 1.8.

I've tried restarting builds many, many times, and they consistently keep failing each time. It feels like the VMs are out of memory, but I can't understand why it's only happening for Go 1.7 and older, but not 1.8 and master.

I couldn't find a good explanation in the Travis docs either.

Any suggestions?

I'll try adding a call to free -h to see if that tells us anything.

dmitshur commented 7 years ago

According to free, there's no difference in available memory depending on Go version specified. Although I'm not sure how accurate it is, it might be reporting memory available on the machine rather than in the container.

My guess is that Go 1.8 is more efficient in terms of memory use than 1.5~1.7, which happen to just go over the limit.

This definitely seems like a https://docs.travis-ci.com/user/common-build-problems/#My-build-script-is-killed-without-any-error type of issue.

dmitshur commented 7 years ago

Hah, looks like my theory that Go 1.5~1.7 consume more memory during compilation and run out of it, but Go 1.4 (being the latest version of Go compiler still written in C) is more memory efficient and succeeds.

So, one possible workaround to this issue is to test with Go 1.4 and 1.8 (and latest master). Testing with 1.4 should hopefully give enough coverage to know that we didn't mess up older versions of Go, and we're testing with all the latest.

Since I don't see other great workarounds, that's my best runner up idea now. Does it SGTU, @errcw?

dmitshur commented 7 years ago

Going to try this option and see if it helps:

image

dmitshur commented 7 years ago

No luck with limiting concurrent jobs to 1. It still fails on 1.5~1.7, just (much) more slowly.

errcw commented 7 years ago

I'm OK with testing 1.4 and 1.8; testing with the latest is arguably most important, and I generally expect the sort of failures we'd get to be ones that manifest across all versions.