NG: development tools, style

[dmp42]

We need to get further gofmt.

@dmcgowan suggested we use https://github.com/golang/lint

Also, should we go with travis or circleci or ...?

I would like to minimize the ceremony around running tests / validation tools - also want to have a way to run only specific tests suites, list them, etc.

Are there any standard tools to do that? Or should we go with some (basic, please!) shell scripting?

[wking]

On Tue, Oct 28, 2014 at 02:15:55PM -0700, Olivier Gambier wrote:

I would like to minimize the ceremony around running tests / validation tools - also want to have a way to run only specific tests suites, list them, etc.

Are there any standard tools to do that? Or should we go with some (basic, please!) shell scripting?

TAP is nice [1,2,3]. Personally, I'd like the API specs and associated test suites in one place, and implementations with any unit tests the maintainers want in another. Then it's easy to test alternative implementations for compliance.

[bacongobbler]

At deis/deis we use very common tooling for our Go packages. Go gets the job done quite nicely for 99% of our use cases. This is a synopsis of our current infrastructure:

• go fmt formats the code nicely, style guide is pretty loose otherwise: https://golang.org/doc/effective_go.html#formatting
• godoc.org for package documentation (example)
• if official documentation is necessary (API endpoint docs, provisioning, reference guides etc.), mkdocs or sphinx seem to be the popular documentation tools used in other OSS projects in tandem with https://readthedocs.org/. Docker uses mkdocs with the assets hosted on S3 (I think) so it may make more sense to use mkdocs here
• go test -v -cover ./... for testing the entire package as well as code coverage, go test -v -cover ./packagename for package-specific tests
  • Makefiles are ridiculously useful here (example)
• go vet for general code inspection: http://godoc.org/code.google.com/p/go.tools/cmd/vet
• golint as our linter: https://github.com/golang/lint
• For CI/CD pipelines, people either use TravisCI or they roll their own for integration tests
  • We use Jenkins but others like dokku use TravisCI w/ a microservice for integration tests. We use Jenkins because we need to deploy and distribute docker images of each component when we cut a release, which Travis did not support at the time (and that may still be true to this day). We also need to run end-to-end integration tests using a CoreOS cluster via Vagrant, which TravisCI does not support either (and for good reason)

I'm not saying you have to use these tools, but this is our workflow and it has treated us very well. You can also write benchmark tests etc. with Go tests, which is another huge plus: http://golang.org/pkg/testing/

Hope this helps!

[dmp42]

ping @dmcgowan @jlhawn @BrianBland

[dmp42]

@bacongobbler @wking thanks a lot for the tips!

We want something like swagger on top of that. The rest sounds good to me.

[visualphoenix]

+1 for @bacongobbler 's recommendation.

[dmp42]

Now using drone, along with golint, go fmt, go vet, go test + goverage. Documentation will be handled separately, so I believe this can be closed!