protobuf-go/regenerate.bash

#!/bin/bash
# Copyright 2018 The Go Authors. All rights reserved.
# Use of this source code is governed by a BSD-style
# license that can be found in the LICENSE file.

cd "$(git rev-parse --show-toplevel)"
go test -v -mod=vendor -timeout=60m -count=1 integration_test.go "$@" -regenerate
exit $?
test.bash: rewrite the integration test in Go This CL switches the integration test to be written in Go instead of bash. The benefits are: * The logic for setting up the dependencies is more robust and handles better a situation where the dependency failed to initialize (due to network trouble, FS permission problems, etc). * The logic does a better job at cleaning up stale dependencies. For example, my .cache folder has go1.9.4, go1.9.5, go1.10.5, and go1.10.6 folders even though we don't use them anymore. * Being able to run only a subset of the integration test since you can pass "-run" to the script. * A signifcant amount of complexity in the test.bash script was running the tests in parallel. This is trivial to do in Go. The major detriment is that Go is more verbose as a "scripting" language. Change-Id: Id7e5b303fb305fdbc0368bdf809dbf29fca1d983 Reviewed-on: https://go-review.googlesource.com/c/164861 Reviewed-by: Herbie Ong <herbie@google.com> 2019-03-01 12:50:52 -08:00			`#!/bin/bash`
			`# Copyright 2018 The Go Authors. All rights reserved.`
			`# Use of this source code is governed by a BSD-style`
			`# license that can be found in the LICENSE file.`

			`cd "$(git rev-parse --show-toplevel)"`
internal/cmd/generate-protos: generate test for testdata Running "go build ./..." does not descend into testdata directories. However, the testdata in this repository is source code that is intended to build properly. We could rename the directory, but that does not test whether the generated packages can initialize properly. Thus, we generate a trivial test that simply blank imports all packages. Doing this reveals that some of the generated files have incorrect imports, leading to registration conflicts. To avoid introducing a dependency on gRPC from our go.mod file, we put the testdata directories in their own module. Also, we avoid running internal/testprotos through the grpc plugin because the servie and method definitions in that directory are more for testing proto file initialization rather than testing grpc generation. Change-Id: Iaa6a06449787a085200e31bc7606e3ac904d3180 Reviewed-on: https://go-review.googlesource.com/c/protobuf/+/164917 Reviewed-by: Damien Neil <dneil@google.com> 2019-03-01 18:11:42 -08:00			`go test -v -mod=vendor -timeout=60m -count=1 integration_test.go "$@" -regenerate`
test.bash: rewrite the integration test in Go This CL switches the integration test to be written in Go instead of bash. The benefits are: * The logic for setting up the dependencies is more robust and handles better a situation where the dependency failed to initialize (due to network trouble, FS permission problems, etc). * The logic does a better job at cleaning up stale dependencies. For example, my .cache folder has go1.9.4, go1.9.5, go1.10.5, and go1.10.6 folders even though we don't use them anymore. * Being able to run only a subset of the integration test since you can pass "-run" to the script. * A signifcant amount of complexity in the test.bash script was running the tests in parallel. This is trivial to do in Go. The major detriment is that Go is more verbose as a "scripting" language. Change-Id: Id7e5b303fb305fdbc0368bdf809dbf29fca1d983 Reviewed-on: https://go-review.googlesource.com/c/164861 Reviewed-by: Herbie Ong <herbie@google.com> 2019-03-01 12:50:52 -08:00			`exit $?`