GopherCI was a project to help you maintain high-quality Go projects, by checking each GitHub Pull Request, for backward incompatible changes, and a suite of other third party static analysis tools.
If a package doesn't build, tools will often echo the exact same error.
logger.With("error", err).Error("SQLDB cleanup outputs error")
gosimple: invalid operation: logger (variable of type github.com/bradleyfalzon/gopherci/vendor/github.com/docker/docker/daemon/logger.Logger) has no field or method With
staticcheck: invalid operation: logger (variable of type github.com/bradleyfalzon/gopherci/vendor/github.com/docker/docker/daemon/logger.Logger) has no field or method With
unused: invalid operation: logger (variable of type github.com/bradleyfalzon/gopherci/vendor/github.com/docker/docker/daemon/logger.Logger) has no field or method With
unparam: invalid operation: logger (variable of type github.com/bradleyfalzon/gopherci/vendor/github.com/docker/docker/daemon/logger.Logger) has no field or method With
This isn't useful at all, and should be handled more gracefully, perhaps:
Once we support tests #9 , only run linters if tests pass (this could be a configuration option). But our goal should be to provide the user with as many useful errors as possible, and a test failing doesn't mean tools output won't be useful.
We could deduplicate the message, which may already be happening, but because we're currently hardcoding the tool in the message, tools don't deduplicate their own messages.
We could try and build the package before running the tool, or after the tool has ran and contains errors, potentially running go list ./..., then checking each package to ensure they can build.
If a package doesn't build, tools will often echo the exact same error.
This isn't useful at all, and should be handled more gracefully, perhaps:
go list ./..., then checking each package to ensure they can build.