Add a goreleaser configuration file that builds binaries for Linux,
MacOS and Windows, for 32bit (x86/386) and 64bit (x64/amd64). The
binaries will be archived into a tar.gz/zip file along with the LICENSE
file.
The `dist/` directory will be written to by goreleaser with the binaries
during the build process, so it's also been added to .gitignore.
Goreleaser can be installed with:
go get github.com/goreleaser/goreleaser
Or other methods for install can be found at:
https://goreleaser.com
To build all the binaries and release them to GitHub:
1. Tag the release. e.g. `git tag -a v1.0.0 -m 'First release'`
2. Generate a GitHub Personal Access Token. See https://github.com/settings/tokens.
3. Push the release to GitHub. e.g. `git push origin v1.0.0`
4. Run goreleaser. e.g. `GITHUB_TOKEN=xxxxxxx... goreleaser`
Go releaser will build the binaries, and upload the binaries to the
GitHub project's release page for the release that was tagged.
* support go modules
- use Go 1.11 (with and without module support) in CI
- add go.mod and go.sum files
- with modules in Go 1.11, can't rely on GOPATH directory layout, so just copy test.proto into this repo
Service reflection has very poor SEO and unfortunately not great discoverability. Since this package is an entry-point for service reflection, this helps make the process of finding this information easier.
* add more control over request metadata between reflection calls and main RPC invocation
* add flag to print a message template (when describing message types)
* relax some command-line argument issues to warnings
I have not been able to figure out the severe flakiness in Go 1.6. And I'm tired of digging for it. Go 1.6 is two years old now, so I suppose it's not valuable to support it. (I had added to the matrix originally just to match the actual grpc-go project, which also supports Go 1.6.)
It's always the same issue: `TestPlainText` in `tls_settings_test.go`. And the behavior appears to be as if the server keeps closing the connection. But it doesn't plague any other test case, which is very mysterious. It's as if the server were configured for TLS and closes the connection when it sees the HTTP/2 preface (which doesn't look like a TLS handshake). But I just don't see how that could be possible, so it must be something else going awry.
Leigh McCulloch