Ah, I knew this would happen sooner or later. The go fmt tool changed some output styles, so the way we are enforcing it will not work across go versions.

I think the solution is to not enforce it, but maybe still warn about it in the future, or just stop being sticklers about it maybe. Any suggestions?

@captncraig We have never tried to support previous version of go (nor do I really want to?). We should just switch to 1.10 and fix the fmt errors when we do I think.

I just forsee people using 1.9 locally and having prs fail because of silly go fmt stuff. Wondering if its really worth the effort. But yeah, we could upgrade the travis thing, and then update the tag in https://github.com/bosun-monitor/bosun/blob/master/_version/requireGo16.go to require 1.10.

Don't get me wrong, its a nice tool. I love the tool. But to fight the build system so much to enforce it makes me wonder if we are being too pedantic about it. Also, from 1.10 release:

Note that these kinds of minor updates to gofmt are expected from time to time. In general, we recommend against building systems that check that source code matches the output of a specific version of gofmt. For example, a continuous integration test that fails if any code already checked into a repository is not “properly formatted” is inherently fragile and not recommended.

How about an auto-format bot that makes gofmt prs for us? I kinda wanna make that now.

@captncraig I guess I don't care as long as we always notice if a PR has not had go fmt run. A warning with the diff would probably suffice I guess.

Time is probably better spent on the backlog of PRs we have right now.

Closed by #2319.