Update test image to always use go version 1.8

[tscolari]

We noticed that the travis output can be a bit misleading because it
says that it's running the tests against go 1.9 but the actual version
inside the docker image is 1.7.

Signed-off-by: Danail Branekov [email protected]

[mtrmac]

Yeah, it’s reporting the Go version outside the container, not inside.

Updating from 1.7 to 1.8 is fine with me, though I worry a little about using what seems to be someone’s unofficial project, and about always using the latest version. We do want the library to work on common distributions (at least RHEL in my case) and always updating to the latest version might let us commit something which can’t be built on the targets platforms.

@runcom ?

[Or maybe we just need to use a centos image with 1.8 😎 ]

[tscolari]

That makes a lot of sense.
I've updated the PR to use go version 1.8, and install it through the official golang release tar.

Centos is also a good option ^^, but I leave that for you to decide haha

[runcom]

LGTM if Travis is happy

[tscolari]

So, I had to change the PATH configuration.
Because travis runs as an unknown user, we can't set the PATH on the Dockerfile, but linking the go binary works fine.

[mtrmac]

The logs report gofmt: command not found. Would it be easy enough to cleanly override PATH in the Dockerfile?

[tscolari]

Setting the PATH works only for the running container user of the Dockerfile (root as default).
Because on .travis.yml this is set: --user $(id -u):$(id -g) that user won't have the PATH, unless that ui/gid is predictable and then it's possible to set it as USER in the DockerFile.

Is there any reason to run the tests as $(id -u):$(id -g)?

[mtrmac]

👍

This was added when converting the tests from non-containerized to containerized, so I guess the goal was to not change this aspect at that time.

Anyway, you’re right that setting PATH would be more hassle. Could you rebase this one last time, please?

[tscolari]

done 👍

[mtrmac]

Thanks!