Updated protobuf gradle plugin version to 0.8.13. Fixed Android Kokoro's memory issue by forcing to use a new Gradle daemon for building the previous commit.
Starting in Gradle 6.0 maven-publish began including sha256 and sha512
checksums, in addition to the previous md5 and sha1 checksums. We don't want
.sha256.asc and .sha512.asc files, as they serve no purpose.
The previous 'git ls-remote' was returning the tag-referenced commits via
vF.O.O^{} which was confusing the version check (as v1.30.0 would not match
v1.30.0^{}). Passing --refs filters those ^{} tags.
There was also a missing 'v' in the version check. It was added explicitly to
generate the list but not to check the result.
Add grpc-android into main build. grpc-android will be built if Gradle option skipAndroid is false. This change also migrates deprecated Robolectric methods to androidx.test methods.
maven_install is strongly superior to previous forms of grabbing dependencies
from Maven as it computes the appropriate versions to use from the full
transitive dependencies of all libraries used by an application. It also has
much less boilerplate and includes dependencies with generated targets.
In the future we will drop the jvm_maven_import_external usages and require
maven_install, at which point we can swap to using the `@maven' repository and
no longer depend on compat_repositories.
Fixes#5359
com.github.dcendents:android-maven-gradle-plugin is incompatible with
Gradle 5 and the project hasn't seen any activity in over a year, so it
seems unlikely to get fixed.
We want to use maven-publish anyway, since that's what we use elsewhere.
This resolves#5523
While bumping `com.android.tools.build:gradle:3.1.2` to `3.3.0`, some other plugins/artifacts/maven repo/buildscripts have to be updated:
- gradle (wrapper) need to upgrade to 4.10.x
- protobuf gradle plugin need to bump a version compatible with gradle version.
- need add `google()` and `jcenter()` repos for android (otherwise `com.android.tools.build:aapt2:3.3.0x` and `trove4j` will not be found resp.)
- need to accept license for Android "build-tools;28.0.3" in kokoro env.
For Bazel, we upgrade to protobuf 3.6.1.2 and javalite HEAD to fix
incompatibilities in newer Bazel releases.
compiler/Dockerfile is unused, so it was removed instead of being updated.
protoc no longer includes codegen for nano, so we remain on the older protoc
any time nano is used.
Protobuf now requires C++11 when compiling, so windows was swapped to
VC 14.
We've had a long run of test timeout failures on Mac with timeouts in
the seconds. Multiple of these haven't seemed like races, but simply
that the Mac machines were too slow. The most recent case for this is a
set of timeouts for
OkHttpTransportTest.earlyServerClose_serverFailure_withClientCancelOnListenerClosed
where it took over a second for a server stream to be created ("Timed
out waiting for server stream").
This commit reduces the number of workers to reduce the overall load,
hoping this lets tests complete within a reasonable amount of time.
- Only cat /VERSION if it exists
- The host name is used as the version name, and if running locally
the versions no longer necessarily start with 'kokoro'. Update the
clean up command.
Only the dummy-default version should ever be promoted. Test versions
should have no traffic routed to it, so that deletions are
simpler. Versions receiving traffic can not be deleted in GAE.
The buildscript was updated to pull in a fix to protoc-artifacts to
support TLS 1.2 (google/protobuf#4879), which was the only remaining
reason to have our own container.
Docker container building was split out into a separate build_docker.sh
so that people can call it blindly and get the container necessary for
run_in_docker.sh.
We always want to use a consistent version of protobuf; avoid the need
for the caller (which may be a person running the script) to specify the
version.
We must not include signatures for maven-metadata.xml*, as the file is
a server-maintained index. Avoiding signing the .md5 and .sha1 avoids
signing unnecessary files (which double-excludes some
maven-metadata.xml* files).
We also swap to using ASCII armored output instead of the binary output,
as that's what is appropriate for "asc" files.
Fixes#4574