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.
This allows us to play with zero-copy and proto3 support for lite.
Unfortunately, it introduced some warnings, so deprecated warnings are
now ignored for benchmarks and interop-testing.
It doesn't appear that OS X is saving its cache yet, so this may not be
needed in the future, but for now we need OS X to avoid attempting to
use the Linux binaries.
The previous download link only worked for the most recent version. The
new form only works for old versions. That will encourage us not to use
the latest version, but for tests that's probably not a big deal.
We haven't noticed the breakage sooner because the build results are
cached.
Without the attributes, fc loses its mind a bit when comparing the
codegen output against the golden; the golden would have DOS newlines
(assuming default git configuration) and the generated code would have
Unix newlines.
The jenkins-pre script just reduces the amount of code is backed into
the jenkins project.