Since 4369e8cd the --include-build just opens us up to trouble with
accidentally building the protoc plugin. Since we're going to do a
./gradlew install anyway, let's just wait until after that point for
building cronet.
This sort of problem was experienced while developing #4369.
They were removed in 137c74d1 since it was believed they were unnecessary.
However, since they are in a macro and not a rule, they are relative to the
caller, not their definition.
Added building the examples to the kokoro CI. Note that this means the examples
are built twice: once in grpc-java's build and once in their own (because it
has a WORKSPACE). Given that the Bazel build is our fastest build, this
slowdown won't probably be an issue.
We always build the artifacts, but only store them in placer via
kokoro if MVN_ARTIFACTS is set to a non empty value.
The 32 bit script runs tests as well as builds artifacts.
The 64 bit script only builds artifacts.
This is a greatly simplified Docker container compared to that in
compiler/. We really want the docker image to just be a build
environment, and build the specific versions of dependencies as part of
our normal build (not docker build).
It also includes a helper script that lets you easily do build actions
with the docker environment, but into a checkout on the host. This can
dramatically reduce the pain in building from the docker container as
the source doesn't need to be checked out and only caches are lost
between invocations.
Otherwise when an exception is thrown powershell will still exit with 0.
This is similar to set -e, except exceptions wouldn't have a status code
of their own.
Another option would have been -ErrorAction Stop, but this need to be
passed to each command inside the powershell script, so would be
functionally similar to our "|| exit" style in the .bat.
There's no 'set -e' in BAT, so we get to do it manually. Wee!
Note that we need to use 'exit /b' instead of 'exit' in the scripts, as
otherwise it exits more than just the current script.
This adds back functionality that was accidentally dropped when
porting from travis:
- make sure generating protos will not lead to any uncomitted changes
- actually run the unit tests
Kokoro already has cmake installed, so it's not necessary in that
environment. We still keep the old code around because it's helpful for
setting up new Windows environments in general.
This avoids needing to build all of grpc as well as avoids having to
manually track which dependencies are necessary.
This cuts 1.5 minutes off the Cronet build time (to 3.5 minutes). But it
also reduces the amount being downloaded which should help with #3284.
Also removed warnings about protoc version matching runtime, since this
is no longer supposed to be a problem (starting with 3.0.0-beta-4) and
all our tests ran fine when using protoc 3.0.2 with protobuf runtime
3.1.0.
Fixes#2316
protoc no longer builds in 3.0.0 because auto-download of the gmock zip
now fails. 3.0.2 has a fix to autogen:
bba446bbf2
All that was strictly necessary was to update .travis.yml and
buildscripts/, but it helps our sanity to keep the rest of the protobuf
versions in sync. Lite is left on its existing version, because it did
not see a bump of neither the java library nor the protoc plugin.
If there are multiple versions available, cmake won't choose the Visual
Studio version selected by vsvars. So we have to explicitly specify the
generator to use.
This allows grpc-java to run on the shared Windows workers instead of
its own specialized instance.
zpencer
Carl Mastrangelo
Eric Gribkoff
Eric Anderson
Kun Zhang
Matt Kwong