Perform additional checks in Travis CI.

[dmitshur]

@dsnet, in #9 (comment), I asked if you wanted a PR that adds a gofmt check to Travis CI, and you said "that would be great". So I sent #12 for that.

However, I'd like to propose performing additional checks in CI. After years of iterating on it, I've arrived at the following .travis.yml script, which I generate for all my Go repositories:

sudo: false
language: go
go:
  - 1.x
  - master
matrix:
  allow_failures:
    - go: master
  fast_finish: true
install:
  - # Do nothing. This is needed to prevent default install action "go get -t -v ./..." from happening here (we want it to happen inside script step).
script:
  - go get -t -v ./...
  - diff -u <(echo -n) <(gofmt -d -s .)
  - go tool vet .
  - go test -v -race ./...

Here's an explanation of its features over the minimal .travis.yml change I sent in #12 that adds the gofmt only:

• Use -s flag with gofmt to ensure code simplifications are made.
• Use -race flag with go test to enable race detector.
• Run go vet on the directory to catch vet issues.
• Run a fast-finish allowed failure build on Go tip version. Allowed failure means a temporary issue in Go tip won't fail the build, but one can still manually see if there are some real failures in that version by manually checking Travis builds occasionally. Fast-finish just means the overall build status is computed faster, without waiting for allowed failure steps (I'm not really sure why it's an option instead of just being a default). See more info about it at https://blog.travis-ci.com/2013-11-27-fast-finishing-builds/.
• Move go get -t -v ./... step from install step to script. This one is very minor and more of a personal preference, but it makes it so that if there's a build failure in any of the dependencies, the build appears as a red "failure", rather than a gray "error".

@dsnet Let me know if you'd like any or all of the above enhancements, I'm happy to send a followup PR.

[dmitshur]

For reference, I've sent a similar change to .travis.yml to github.com/gorilla/mux in 2015 and it was accepted there, see gorilla/mux#134.

[dsnet]

Suggested script LGTM, but avoid the go get step for now. It is intended for this package to have no dependencies other than the standard library. We can add that in if this ever changes.

Unrelated to this repo, it would be really cool if there was a way to setup travis to send failures on master to some dashboard that the core Go developers could look at it. This would be a great form of distributed regression testing. As it stand, we rely heavily on users manually reporting issues.

[dmitshur]

Suggested script LGTM, but avoid the go get step for now. It is intended for this package to have no dependencies other than the standard library. We can add that in if this ever changes.

SGTM, I'll do that.

Unrelated to this repo, it would be really cool if there was a way to setup travis to send failures on master to some dashboard that the core Go developers could look at it. This would be a great form of distributed regression testing. As it stand, we rely heavily on users manually reporting issues.

This is an interesting idea. I have seen it suggested in the past, and we discussed what it would take to make that possible. Unfortunately, after spending 15~ mins I couldn't find where that discussion took place. :( IIRC, the general conclusion was that there are many false positives, and as a result, it ends up being quite optimal to rely on people manually peeking at the tip failures of their own projects from time to time, investigating the root cause, and reporting a detailed and helpful bug report upstream to Go only when the problem is indeed in the toolchain, rather than elsewhere.

[dmitshur]

Ohhh, I found it! @dsnet, you were the person who made the suggestion. 😆

See golang/lint#279 (comment).

[dsnet]

Ha... I often forget the very words I say :)