https://github.com/grpc/grpc/pull/41309 caused timeout because a full
build is too expensive.
This PR changes the new bazel command to use the --nobuild option. This
triggers bazel's "static" dependency analysis without compiling C++
code. This test does NOT detect issues caused by module
incompatibilities (e.g. some package doesn't build with new version of
absl).
---------
Co-authored-by: Mark D. Roth <roth@google.com>
I added this in anticipation of wanting to use it, but that hasn't transpired... and we're seeing flaky tests. Removing for now.
Closes#40933
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40933 from ctiller:tdigest-- ba911bfe96cba57e0bfc97e13f0132c68dd67e64
PiperOrigin-RevId: 858731635
What happened:
* An upgrade of envoy_api was introduced https://github.com/grpc/grpc/pull/41242
* Bazel now pick googleapis@0.0.0-20251003-2193a2bf because envoy_api requested it.
* googleapis has gone through a refactor somewhere in between 0.0.0-20240819-fe8ba054a and googleapis@0.0.0-20251003-2193a2bf. As a result `switched_rules` became completely broken for bzlmod. The new recommended approach for bzlmod is to use `googleapis-{cc,python,grpc-cc}`
* v1.78.0-pre1 BCR release is blocked, I had to add an overlay [patch](https://github.com/bazelbuild/bazel-central-registry/blob/main/modules/grpc/1.78.0-pre1/patches/add_deps_for_googleapis_switched_rules.patch) to unblock release.
* This PR is created to integrate the change to master.
Related discussion:
https://github.com/bazelbuild/bazel-central-registry/issues/3941
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#41363
PiperOrigin-RevId: 856792330
Pin versions for riegeli so fuzztests can properly compile with bzlmod.
Caveat: in workspace we use fuzztest from 2023-05-16 but in bzlmod we use fuzztest@20241028.0. The reason is likely that BCR doesn't have older version of fuzztest, and it might cause some behavioral difference between our workspace and bzlmod settings.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#41309
PiperOrigin-RevId: 856401926
This includes two major changes:
1. An additional credentials option `sni_override` with the type `optional<string>`. If `nullopt`, it has no effect, and if set to the empty string it disables sending SNI entirely. Otherwise, the specified string will be sent.
2. The implementation of [gRFC A101](https://github.com/grpc/proposal/blob/master/A101-SNI-setting-and-SNI-SAN-validation.md) using that new option. This includes options to set SNI and to validate SAN values against the set SNI value.
Closes#41051
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41051 from murgatroid99:xds_sni_support 6a1f8667dedc19947532720495b2932889236a12
PiperOrigin-RevId: 855765736
Building RBE tests require `custom_exec_properties` which can only be used from WORKSPACE. This PR introduces a wrapper module extension for `bazel_toolchains` so they can be used from MODULE.bazel.
See also:
https://bazel.build/external/extensionhttps://github.com/bazelbuild/bazel-toolchains/blob/master/rules/exec_properties/README.md
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#41252
PiperOrigin-RevId: 854383508
This temporarily disables the bzlmod version consistency check, because the new version of the xDS protos winds up pulling in a lot of upgraded dependencies that will take some work to get working.
Closes#41242
PiperOrigin-RevId: 852345420
Bzlmod uses Minimal Version Selection algorithm for building dependency graph (see https://bazel.build/external/module#version-selection) which can cause resolved version number to be higher than requested versions. This may lead to nuanced bugs and hide behavioral differences between WORKSPACE and MODULE.bazel settings.
This PR does a few things:
* explicitly turn on --check_direct_dependencies=error for bzlmod tests, so version mismatch will now be an error
* Bump versions in MODULE.bazel to fix tests in `tools/bazelify_tests/test/bazel_build_with_bzlmod_linux.sh`.
* update bzl extensions accordingly to minimize the difference between workspace and bzlmod settings.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#41244
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41244 from yuanweiz:direct_deps dd43d3007e8c88be1fc59cc895d832e430421d97
PiperOrigin-RevId: 848257936
Change was **not** created by the release automation script, because it doesn't handle a +2 version bump. See go/grpc-release
Closes#41291
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41291 from murgatroid99:v1.79.0-dev_bump 9a9bf54e5a891459390792dc9d547bdc17b7dd4d
PiperOrigin-RevId: 848168598
Change was created by the release automation script. See go/grpc-release.
Closes#41288
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41288 from murgatroid99:bump_core_version_202512220753 e8273425781ce92dbded8b295f3f0e438b3dbccc
PiperOrigin-RevId: 847898275
- Regen requirements.bazel.lock with Python 3.9
- bump isort to 6.0.1 (except in pylint, which needs to be updated separately)
- fix python version specifiers for black, isort and pylint, typeguard
- fix default ignore patterns for isort and pylint
- consistent debug info: python version, pip list
- consistent virtualenv naming: `.venv-ci-*`
- bazel: bump typeguard to 4.4.2
- bazel: bumped gevent to `25.9.1`, greenlet to `3.2.4` to support Python 3.13, closes#40685
- bazel: bump pyyaml for python 3.14 support
- bazel: take care of temporary pins to support 3.8-based CIs
Bazel RBE CIs upgraded in the following changelists, and currently run Python 3.10:
- cl/845778848
- cl/845816768
Relevant testing was done in #41239.
Closes#40323
PiperOrigin-RevId: 846423001
Target `//tools/bazelify_tests/test:cpp_distribtest_cmake_aarch64_cross_linux` seems to go over Bazel's `--test_timeout` limit from time to time.
Bazel `--test_timeout` flag was initially introduced in #38123 and set to 30 minutes below Kokoro's job `timeout_mins`. Since then, we've increased Kokoro's timeout several times without making corresponding changes to bazel's `test_timeout`.
This PR updates Bazel's test timeout to aligned with Kokoro's job timeout, and adds a reminder to keep those in sync. In addition, I've broken `BAZEL_FLAGS` in multiple lines for better readability, proto text format spec [allows it](https://protobuf.dev/reference/protobuf/textformat-spec/#string).
Closes#41231
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41231 from sergiitk:fix/ci/rbe-nonbazel-bazel-test-timeout 22970a18ce2768693292f566f31dd765916fbca0
PiperOrigin-RevId: 843999341
Fixes "Bazel RBE Non-Bazel Tests" job timeouts. This affects:
-
[`grpc/core/master/linux/bazel_rbe/grpc_bazel_rbe_nonbazel`](https://btx.cloud.google.com/invocations;p=830293263384?q=JOB_NAME:grpc%2Fcore%2Fmaster%2Flinux%2Fbazel_rbe%2Fgrpc_bazel_rbe_nonbazel)
-
[`grpc/core/pull_request/linux/bazel_rbe/grpc_bazel_rbe_nonbazel`](https://btx.cloud.google.com/invocations;p=830293263384?q=JOB_NAME:grpc%2Fcore%2Fpull_request%2Flinux%2Fbazel_rbe%2Fgrpc_bazel_rbe_nonbazel)
The issue is with the
`//tools/bazelify_tests/test:runtests_cpp_linux_dbg_gcc_8_build_only`
target, which is a part of the portability suite
(`//tools/bazelify_tests/test:portability_tests_linux`). With gcc-8,
building `buildtests_cxx` make target either times out, or fails with
`collect2: fatal error: ld terminated with signal 9`.
I've investigated this as an OOM issue (a common cause of `collect2:
fatal error: ld terminated`), but increasing memory limits does not
help. I've updated RBE stack from `n1-standard-16` (60 GB RAM) to
`e2-standard-32` (128 GB RAM) with no effect. Increasing various job
timeouts (kokoro, bazel, target, etc) didn't help either. See PR #41028
for more details and other attempts at root-causing.
The most important part of portability tests is to verify that gRPC can
be built with all supported compilers. Since we are having a problem
with building the tests with gcc-8, we've decided to stop covering the
tests for that compiler..
Specifically, this PR changes `runtests_c*_linux_dbg_gcc_8_build_only`
bazel target to skip building test make targets (via
`--cmake_configure_extra_args=-DgRPC_BUILD_TESTS=OFF`), and only build
`grpc++` make target. See `build_cxx.sh`:
cb2db8fc21/tools/run_tests/helper_scripts/build_cxx.sh (L49-L55)
Notes and observations:
- Only gcc-8 and only cpp version is affected:
- Portability tests for other gcc versions have no problems building
`buildtests_cxx` of their corresponding
`runtests_c*_linux_dbg_gcc_*_build_only`.
- The C version of gcc-8 portability test
(`runtests_c_linux_dbg_gcc_8_build_only`) has not issues building tests
([sample run with full target
log](https://btx.cloud.google.com/invocations/0b3d41e7-3cf2-4ff8-b6d5-2bc0d52179cd/targets/%2F%2Ftools%2Fbazelify_tests%2Ftest:runtests_c_linux_dbg_gcc_8_build_only;config=815e4ca9071c7e1d8ca72b9c87c1347399a51eb1246eb9c49dd54d9a24ef5cba/tests)).
- However, unfortunately, this change skips the test targets for
`runtests_c_linux_dbg_gcc_8_build_only` too.
- We already had the logic to skip tests for gcc-7, but for a different
reason: #37257
Also mark the test as non-polling, so we don't run it multiple times.
Closes#41198
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41198 from markdroth:validation_errors_no_dups 2ebe0f9846e9199a9ec1a3bfceeab58b7d3b65f9
PiperOrigin-RevId: 841792148
Add a new config to enable active call inspection with channelz, disabled by default. Plumb through promise_based_filter, call-v3.
PiperOrigin-RevId: 837614415
Python Bazel tests have been failing since yesterday after layering check was enabled in grpcio_tools build in commit: 756389e9e7
Temporarily disabling it after discussing IRL with @rishesh007
Closes#41142
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41142 from sreenithi:temp_fix_python_bazel_test 751c420bf3a27066d6cdd912e0e08e9c0acaebb8
PiperOrigin-RevId: 837494537
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#41090
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41090 from athomas:patch-1 b691ea897456c182a4d0385b8b46fb85c24c0928
PiperOrigin-RevId: 834474588
Allow servers to set max outstanding streams limit per server. This pull request only adds the BUILD changes required for this. The core logic will follow in a later PR.
Closes#41076
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41076 from siddharthnohria:max_outstanding_streams 392d962fc78be66c075952977bc3a28f2298b7ce
PiperOrigin-RevId: 833196338
This solves the issue with with copt cache dropped between `bazel build` and `bazel test`:
```
WARNING: Build option --copt has changed, discarding analysis cache.
```
This issue was introduced in #39945, which added `--copt=-DGRPC_POSTMORTEM_CHECKS` unconditionally to all `basel test`, but not `build`:
1d6841f7d8/tools/bazel.rc (L155-L156)
This PR moves the macro to a separate bazel profile config called `postmortem`, which is not enabled by default.
Instead, this config will be enabled in all remote CIs via tools/remote_build/include/test_config_common.bazelrc: ba4984e8a0/tools/remote_build/include/test_config_common.bazelrc (L26-L27)
For the list of affected CI jobs, see my comment on this PR.
Closes#41038
PiperOrigin-RevId: 832339240
[PH2][BUILD] Adding new file for IncomingMetadataTracker
Closes#41058
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41058 from tanvi-jagtap:new_files 6c0da18b7c8980d6ab133cb8e543e6ad13e5d69d
PiperOrigin-RevId: 832130354
This refactors the call buffering code for the v1 stack, which avoids some repetition between the resolver queue and the LB pick queue. This code will also be used in the future in the subchannel as part of implementing the MAX_CONCURRENT_STREAMS design.
As part of this, I also eliminated the subclassing in the v1 client channel implementation, which has not been necessary since the v2 code was removed.
Closes#40945
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40945 from markdroth:call_buffer_v1_refactoring 0a471be6ed862c3cc3225644fb2a3e1456e60fbf
PiperOrigin-RevId: 829566551
This PR removes some additional files that were included in the grpcio_tools package wheels after migrating to pyproject.toml build system in #40833Closes#40999
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40999 from sreenithi:fix_grpc_tools_wheels_2 a261b2160e3ddd34a5c0b74e6d84b2f8c1bda1cd
PiperOrigin-RevId: 827755815
The newly migrated pyproject.toml build system (in #40833) seems to have much slower build times compared to the previous setup.py builds. This difference has also been noted by few users ([Ref1](https://github.com/pypa/pip/issues/7294), [Ref2](https://zameermanji.com/blog/2021/6/14/building-wheels-with-pip-is-getting-slower/)) most likely due to the overhead of creating isolated build environments for each build.
Some new runtimes for each variant target noted from different recent runs below:
```
2025-11-01 10:19:02,937 PASSED: build_artifact.python_musllinux_1_2_x86_cp312-cp312 [time=4267.1sec, retries=0:0]
2025-11-01 10:19:05,501 PASSED: build_artifact.python_musllinux_1_2_x86_cp311-cp311 [time=4269.7sec, retries=0:0]
2025-11-01 10:19:07,152 PASSED: build_artifact.python_musllinux_1_2_x86_cp310-cp310 [time=4287.0sec, retries=0:0]
2025-11-01 11:43:22,269 PASSED: build_artifact.python_manylinux2014_x86_cp312-cp312 [time=4644.4sec, retries=0:0]
2025-11-01 11:43:37,257 PASSED: build_artifact.python_manylinux2014_x86_cp314-cp314 [time=4659.4sec, retries=0:0]
2025-11-01 11:43:37,525 PASSED: build_artifact.python_manylinux2014_x86_cp311-cp311 [time=4659.7sec, retries=0:0]
2025-11-01 11:43:40,671 PASSED: build_artifact.python_manylinux2014_x86_cp310-cp310 [time=4662.8sec, retries=0:0]
2025-11-01 11:43:51,663 PASSED: build_artifact.python_manylinux2014_x86_cp39-cp39 [time=4673.8sec, retries=0:0]
2025-11-01 11:43:51,708 PASSED: build_artifact.python_manylinux2014_x86_cp313-cp313 [time=4673.8sec, retries=0:0]
2025-11-01 04:59:11,117 PASSED: build_artifact.python_linux_extra_armv7_cp311-cp311 [time=5172.2sec, retries=0:0]
2025-11-01 04:59:31,002 PASSED: build_artifact.python_linux_extra_armv7_cp314-cp314 [time=5157.0sec, retries=0:0]
2025-11-01 04:59:53,485 PASSED: build_artifact.python_linux_extra_armv7_cp39-cp39 [time=5221.7sec, retries=0:0]
```
The builds take anywhere between 70-90 minutes for each target. We have a total of 30 targets currently and 12 targets are built parallelly in a batch. So for about 3 batches of 12 targets each and a worst case time of 90 minutes per batch, the `build_artifact` phase itself should take about 4.5 hours to complete, followed by the remaining `package` and `distribtest` phases which should be comparatively shorter.
So, I believe about 7 hours should be enough, but just keeping an extra buffer and increasing the timeout to 8 hours.
Closes#41000
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/41000 from sreenithi:increase_distribtests_timeout 44c94b0ffd83469856d9a62f8edcee8e69fa252a
PiperOrigin-RevId: 827672050
Python version not updated because the image build is broken by a runtime dependency issue. The fix#40959 can't be backported retroactively to the tag.
Closes#40975
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40975 from sergiitk:interop-1.76.0 cd18cfff23e61f9d0d643c41ee149bf2e8334aaf
PiperOrigin-RevId: 826173165
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#40968
PiperOrigin-RevId: 825567114
- The python code generators are deleted
- In a future PR, the sanitize script will be updated to use the C++ experiments code generator and the python script will also be deleted
Closes#40906
PiperOrigin-RevId: 825223102
Pip released [v25.3](https://pip.pypa.io/en/stable/news/#v25-3) a few days back which doesn't support `setup.py` builds anymore, while we are yet to migrate to use the `pyproject.toml` build system in #40833.
Hence some of our Python tests using the most recent versions of pip for the build have started to fail with errors like:
```
ERROR: Failed building wheel for grpcio
Failed to build grpcio
error: failed-wheel-build-for-install
× Failed to build installable wheels for some pyproject.toml based projects
```
This PR hence pins the pip version to 25.2 which still supports setup.py build until #40833 is submitted.
Closes#40959
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/40959 from sreenithi:pin_pip_version d72e0563ce0f00a962bd03ddd279cf587494fd3e
PiperOrigin-RevId: 824584176
This PR updates the minimum version of `setuptools` package required across different Python setup files to v77.0.1. This version contains Python 3.14 support as well as deprecates a format for defining project license in `pyproject.toml` files ([Reference](https://setuptools.pypa.io/en/stable/history.html#id71)) which is a prerequisite for #40833Closes#40931
PiperOrigin-RevId: 823008815
