If I didn't upgrade X there is probably a reason, but worst-case the
reason was "I was lazy." I did the easy stuff, so if upgrading caused
problems of any real sort I skipped it and moved on. The main other
reason is there's some stuff we're more conservative about upgrading,
but you can't distinguish one from the other in this commit.
* buildscripts: Fix Xmx JVM flag propagation in GRADLE_OPTS
* buildscripts: double Java memory allocation pool
To reduce periodic OOMs of the "GitHub Actions Linux Testing / tests (11) (pull_request)" job.
* istio-interop-testing: create a separate project and add istio echo server code
after removing from the grpc-interop-testing project
* add jib support
* use imported echo.proto from istio repo
* use context to propagate values from interceptor so the service's echo method has all values required to compose EchoResponse
Both Netty and OkHttp had local and remote windows flipped. Also, the
comment in OkHttp about "not tracked" wasn't true, so make it more
accurate and provide a _hint_ of what the window may be instead of just
-1.
all: Update netty to 4.1.77.Final and netty_tcnative to 2.0.53.Final
Also switches to a non-release version of rules_jvm_external to allow Bazel build to work with artifact classifiers.
Half of the text was copied from NameResolver.getServiceAuthority().
However, that method can't perform I/O (which would block) so more text
was appropriate here to mention the implications of having a remote
service provide the authority.
I noticed the text was lacking while discussing #9266.
This seems like a poorly thought-out feature for maven_install in a
world where the dependency list is being combined from multiple
repositories, as it means all Bazel-aware dependencies must subscribe to
the idea this is good and useful. It also loses effectiveness as
transitive dependencies are likely to be included directly in
maven_install; users of gRPC can use netty, guava, and other
dependencies without explicitly defining them even with
strict_visibility=True. Given maven_install still complains
about "Found duplicate artifact versions", it isn't too surprising it
doesn't make sense in a multi-repo world.
This isn't a bad feature for gRPC as we are pretty low-level and it can
be helpful when making bazel dependency versions match gradle dependency
versions. But it doesn't necessarily seem like something we need to be
too worried about making sure we use. Similarly, don't use it in the
example as it seems low-value for our users.
Fixes#9288
This Addresses the issue with skips not working due to the
missing/inconsistent `--testing_version` flag, ref b/235688697.
1. Uses the new `TESTING_VERSION` variable populated in the shared
grpc_xds_k8s_install_test_driver.sh - new approach for detecting
versions applicable to all languages.
2. Use `TESTING_VERSION` in all build files in `--testing_version` and
when tagging docker images. This will be backported to all active
test branches. Build Scripts in all other languages will be updated
as well.
Corresponding grpc core change: https://github.com/grpc/grpc/pull/30027
If the failure is before the NameResolver has returned the first time,
RPCs would be queued waiting for service config. We don't want to use
the ConfigSelector, as we are trying to circumvent the NameResolver and
LoadBalancer.
Fixes#9257
This moves our depedencies into a plain file that can be read and
updated by tooling. While the current tooling is not particularly better
than just using gradle-versions-plugin, it should put us on better
footing. gradle-versions-plugin is actually pretty nice, but will be
incompatible with Gradle 8, so we need to wait a bit to see what the
future holds.
Left libraries as an alias for libs to reduce the commit size and make
it easier to revert if we don't end up liking this approach.
We're using Gradle 7.3.3 where it was an incubating fetaure. But in
Gradle 7.4 is became stable.
Internal build failed with
```
grpc/api/src/test/java/io/grpc/GlobalInterceptorsTest.java:28: error:
[JUnit4RunWithMissing] Test class may not be run because it is missing a @RunWith annotation
public class GlobalInterceptorsTest {
^
Did you mean '@RunWith(JUnit4.class)' or 'public abstract class GlobalInterceptorsTest {'?
```
This allows using GrpcCleanupRule with JUnit 5 when combined with
ExternalResourceSupport. We don't really lose anything important when
running with JUnit 4 and this eases migration to JUnit 5.
ExternalResource is now responsible for combining exceptions. after()
cannot throw checked exceptions, so we must now wrap the
InterruptedException. When used with JUnit 5 we are unable to detect the
test failed; we accept that for now but it may be fair to create a new
class for JUnit 5 to be used with `@RegisterExtension` that implements
BeforeEachCallback and AfterTestExecutionCallback to restore the JUnit 4
behavior.
See #5331
Eric Anderson
Sergii Tkachenko
Larry Safran
sanjaypujare
yifeizhuang
apolcyn
Adil Ansari
yifeizhuang
Terry Wilson
lllu30
amirhadadi
Wenlong Zhang
sumitd2
Sergii Tkachenko
Kurt Alfred Kluever
DNVindhya
Feng Li