Actually, this is CI and not build, build is done by promu. Reading https://github.com/golang/go/milestone/53 right now.

You mean "build" in the PR / commit title? The CI does build and push though, too :) Well, I can rename it.

Reading the go1.8.1 milestone, I can't say for sure some the bugs won't affect us though ...

Yeah, hard to tell, and some of the problems reported in those issues seem to be older than 1.8 even (breaking commits from last year). I think it's worth the risk, as 1.8 might even be better overall in terms of bugs.

You can use 1.8.x to build with latest patch release without bumping version manually.

@AlekSi Interesting! I wonder if we want that. It would make it less explicit which version of Go we're building with.

go version command is explicitly invoked by Travis itself (example).
You can also add master Go version to build matrix. This will help Go team to identify problems in Go itself before release. You can also allow master build to fail.
I can make a PR if you are interested.

@AlekSi Yeah, for the Travis tests, that sounds ok. If we additionally add the master Go version, the Travis tests will run twice as long though, right?

The CircleCI one that builds the release images I would think we'd like to keep at a deterministic version that doesn't change without us doing anything.

If we additionally add the master Go version, the Travis tests will run twice as long though, right?

They will run in parallel.

Why you use both Travis and Circle CI?

@AlekSi I have no idea anymore, but there were surely some initial reasons :) Maybe @sdurrheimer knows the current reasoning...

It is possible to configure Travis to build master Prometheus against both 1.8.x and master (previously known as tip) Go and not change the whole status to Failed for that particular combination. Those two builds will run concurrently, there is no slowdown. And it will help to uncover bugs in Go.

Yes, it's configurable and emails are enabled by default.
I will send a PR then.

Well, I tried it. Email is not sent if allow_failures job fails. See travis-ci/travis-ci#6773. What we can do:

1. Do not test with master, change nothing. Go project will not benefit from periodic builds of large Go project with master version.
2. Do test with master, check job fails by hands. Travis CI UI is not really suitable for this.
3. Do test with master, setup custom webhook notifications. Does it worth it? I would say yes, but I'm not a maintainer.

WDYT?

@AlekSi Thanks for all the testing! Hm, since Prometheus's primary purpose is not to test new Go releases and this is looking more and more complicated, I would tend towards 1. With option 2, nobody would realistically ever look at the outcome. And maintaining an extra webhook for option 3 also seems unideal. But I don't feel strongly, if others have different opinions.

See #2568.