Use Go 1.12 for docker builds

[glyn]

An alternative would be to bump quay.io/deis/lightweight-docker-go to use a
later version of Go, but it's probably safer to get out of that game and use
the more widely supported golang image instead.

Fixes #773

[silvin-lubecki]

@glyn I think there's an issue with the vendoring test. Is there any reason why you had to bump kubernetes dependencies ?

[glyn]

@glyn I think there's an issue with the vendoring test. Is there any reason why you had to bump kubernetes dependencies ?

The vendoring test does dep check and so I issued dep ensure thinking this was supposed to ensure the vendored code matches Gopkg.lock.

[silvin-lubecki]

@glyn would it be possible to split this PR in 2? One to move to golang:1.12 image, and the other to bump the dependencies? Or at least in 2 separated commits? It's hard to see why this bump was needed 🤔

[glyn]

@glyn would it be possible to split this PR in 2? One to move to golang:1.12 image, and the other to bump the dependencies? Or at least in 2 separated commits?

I've split it into two commits. I don't think I could get CI to pass without both commits.

It's hard to see why this bump was needed 🤔

Try running SKIP_DOCKER=true make verify-vendored-code at master. I'd settle for another way of making this check pass if you'd like to suggest one. :-)

[carolynvs]

Let me take a look at what's up with our makefile / dep testing code because my gut says that we shouldn't have to bump dependencies for this.

[carolynvs]

@glyn The build for master is broken and isn't running on each push to master (but it is still triggering for PRs which is why you are getting hit with these problems). I am fixing master now and have @vdice getting the CI build running again. Once we are done, then you'll be able to rebase and just have the proper changes in your PR again.

[glyn]

@glyn The build for master is broken and isn't running on each push to master (but it is still triggering for PRs which is why you are getting hit with these problems). I am fixing master now and have @vdice getting the CI build running again. Once we are done, then you'll be able to rebase and just have the proper changes in your PR again.

Thanks @carolynvs. I'm a little puzzled though. The sole purpose of this PR is to fix the build. I'll look forward to comparing your PR...

[glyn]

Let me take a look at what's up with our makefile / dep testing code because my gut says that we shouldn't have to bump dependencies for this.

I suspect the problem is that the two commits 4dccb95 and bf4df3a conflicted logically, but not in a way that git would detect, so the PR for the second commit didn't have its checks re-run after the first commit was merged.

[technosophos]

It took me a while to realize that this is actually a fix for broken master, not just a switch to Go 1.12. So now I guess we have two PRs that are trying to fix #773. I don't actually have a strong preference for one or the other.

[jeremyrickard]

Hey @glyn there was some chat in the slack channel and the consensus was to merge #775 to fix the build. Can you rebase this to just handle the upgrade to 1.12? That's a more involved change (i.e. consumers will also need to bump to 1.12).

[glyn]

Hey @glyn there was some chat in the slack channel and the consensus was to merge #775 to fix the build. Can you rebase this to just handle the upgrade to 1.12? That's a more involved change (i.e. consumers will also need to bump to 1.12).

I'll look into it. Actually, the only consumers who will be affected are those who specify SKIP_DOCKER=true when building, and they should know what they are doing.

Closing in favour of #777 which has a more appropriate branch name.