Previously the android projects were separate from the main build and
each other. For quite a while now they have been integrated in the main
project. There's no longer any need to build each separately.
Adds CI coverage for building example/android/strictmode and examples/example-jwt-auth. Also cleans up existing Gradle and Maven build command in the CIs.
Re-sort packages, now that the tabs aren't skewing the sorting.
I'm quite confident I had fixed this already, but I had multiple copies
of this file on multiple machines and must have fixed the wrong copy.
CentOS 6 is dead and no longer has update servers. CentOS 7 is older
than Debian 9 (oldstable), so binaries hopefully work on both. More
testing is necessary, but everything's broken now, so this is better
than nothing.
We stop using protoc-artifacts because now the container is
straight-forward enough that we can just use our own. Previously the
"devtoolset" stuff made us want to share the container.
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 mainly avoids protoc from 3.7.0 which has a dependency on libatomic. Most
of our systems have libatomic, so it mostly works, but the interop docker
container does not, so building fails. Version 3.7.1 was rebuilt to avoid
needing the libatomic shared library.
This has the added benefit that Bazel is now on the same version as Gradle, as
3.7.1 included fixes for Bazel.
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.
Currently only protos in alts, grpclb, and services are synced. Once
some java_package options are "upstreamed", benchmarks and
interop-testing could also be synced.
- 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.
We previously passed a custom variable to the checkstyle configuration.
In Gradle 4.0 config_loc was added for the same purpose. The default
configDir is $projectDir/config/checkstyle which is different for each
project; we need to override it to always point to the root project.
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
These scripts set up the jobs needed to do one click releases.
List of changes:
Do not put files in mvn-artifacts/$ARCH. This makes the view uniform
across unix and windows and is easier to sign and upload.
A working curl is needed to build protobuf from source, so run yum
update.
run_in_docker.sh: use chmod to fix permisisons, do not set up user
linux_artifact builds 32 and 64 artifacts using unix.sh
add upload_artifacts cfg and script
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.
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.
Jan Tattermusch