Update .travis.yml for latest conventions, use fast_finish, test with -race.

[dmitshur]

Please consider these changes to .travis.yml that follow #277:

• Update to use latest conventions as documented at https://docs.travis-ci.com/user/languages/go#Specifying-a-Go-version-to-use. Specifically, use master instead of tip to refer to latest (unreleased) version of Go.

• Use .x to target latest patch releases of each point release of Go.

• Use fast_finish to speed up build reporting with no semantic change. It's documented at https://blog.travis-ci.com/2013-11-27-fast-finishing-builds/.

• Use race detector when running tests. It should be a good idea to do this.

• Do not require sudo access, since it's not required. This allows Travis to use container-based infrastructure.

I'm happy to receive feedback on the changes and discuss them. I wanted to contribute these improvements because this is a visible project, and I want its .travis.yml file to serve a better role model for people learning how they can structure their .travis.yml file for their Go repositories.

[dsnet]

Thanks for the improvements. What's the difference between tip and master then?

[dmitshur]

I've updated the PR with a3a7dd9, see its commit message for rationale.

Thanks for the improvements.

No problem!

What's the difference between tip and master then?

There is no functional difference, they are equivalent aliases. The only difference is that tip was the old name, and it has been renamed to master more recently (sometime within the last 6 months). tip is no longer documented to do anything (but in practice, it still works for now).

[dmitshur]

Some observations from the Travis build that ran on this PR.

You can see the effect of fast_finish on this screenshot. The build is reported as successful as soon as the 2 mandatory environments have finished (successfully), even though the allowed failure environment hadn't finished running. Without fast_finish, the PR would still be marked as "build in progress".

Second, the container-based builds for 1.8.x and 1.7.x took around 40 seconds, while the previous ones took 30 seconds. See this screenshot. However, master was faster at 1 min 40 seconds vs 2 min 30 seconds previously. But there's likely enough variability in build times, that a single run isn't very representative of average speed.

Edit: Actually, I forgot that the tests now run with -race flag, which is going to be slower than without. So 40 seconds vs 30 seconds is reasonable.

[dsnet]

Thanks for the explanations; it's improving my knowledge of how travis works.

It would be nice if there was someway for failures on master to automatically notify the core Go developers of regression failures. It would go a huge way if every open source project took part in regression testing in a distributed fashion.

/cc @bradfitz with regard to travis tip testing.

[dmitshur]

It would be nice if there was someway for failures on master to automatically notify the core Go developers of regression failures. It would go a huge way if every open source project took part in regression testing in a distributed fashion.

The main barrier of automating this efficiently, IMO, is the chance for false positives.

The current situation, as far as I know, is that open source project maintainers typically glance at the master build status occasionally, and if they notice a failure on master, they can investigate it. If their investigation leads to a real issue on Go tip (rather than their own code doing something that's no longer valid in next version of Go), they'd probably need to check if it's already been reported, and do so if not.

It might not be the most effective solution, but it does work to some degree. I think improving upon that is quite non-trivial. But it's certainly worth looking for ways to do better.

[dmitshur]

@dsnet, an example of what I described above that I recently ran into follows:

I spotted a Go master-only failure recently in go-github repository. I investigated and made a fix PR (not to be merged right away, but for discussion) at google/go-github#568, found a relevant issue in the Go project and made a reference there.