Use `dockcross/manylinux2014-aarch64` for aarch64 artifact docker images to improve portability. Also existing docker images are updated to use the latest instead of pinned image.
Closes#38084
PiperOrigin-RevId: 694241161
This change upgrades the sanity test to use Clang 19, including clang-format and clang-tidy. (It's a partial implementation of the changes proposed in #38038)
Key updates:
- Docker images now utilize Clang 19.
- Code has been reformatted using the updated clang-format.
- Resolved `readability-math-missing-parentheses` warnings raised by clang-tidy.
Note that the other part of the clang-19 upgrade, "using clang-19 for C++ test" will be done once opentelemetry-cpp fixes the clang-19 build error.
Closes#38070
PiperOrigin-RevId: 693833548
This reverts commit 574b19ec31.
<!--
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#38074
PiperOrigin-RevId: 693803071
This might not be needed? (From https://github.com/grpc/grpc/issues/37976)
- Boringssl commit requiring -msse2: 56d3ad9d23 (diff-f628d148f94bbab9e22a1ad426ccd94311f1fb87bbe5cc533cb85aee18b07a20R248)
- gRPC change to add -msse2 https://github.com/grpc/grpc/pull/36089
---
Answer to the quesiton above is yes; The -msse2 option remains necessary for gRPC on i686 due to BoringSSL's requirements. However, the existing CMake condition for this option was too broad, potentially including ARM architectures where SSE2 isn't supported, leading to compilation errors. I've refined the condition to specifically target 32-bit x86 architectures.
Furthermore, to ensure accurate architecture detection within our dockerized tests, I've configured x86 tests to utilize the linux32 command. This ensures that uname -a correctly reports i686, allowing gRPC's CMake to identify the architecture and apply the -msse2 option as needed.
It's important to note that RBE overrides the default entrypoint, so RBE-based tests must explicitly invoke linux32 even if the Docker image already has it set.
Fixes https://github.com/grpc/grpc/issues/37976Closes#38024
PiperOrigin-RevId: 693026079
This aims to resolve segfaults encountered when rebuilding ARM64 PHP Docker images. This segfaults came from gcc during ARM64 builds using QEMU. To workaround this problem, the PHP Docker images have been restructured to use apt-get for installation, thereby avoiding the use of gcc. This also needed to upgrade Debian and PHP to their latest versions, aligning with our minimum supported PHP 8.
Closes#37895
PiperOrigin-RevId: 686162640
With the CL-first approach, the docker test configs for Binder need to be deleted before the Binder code and tests themselves can be deleted in the next step. Sanity checks fail otherwise.
Closes#37862
PiperOrigin-RevId: 683691175
This PR adds templating for Python versions and updates the maximum supported Python version to 3.13. The following major changes related to templating are added:
- Minimum supported Python version and list of supported versions in `setup.py` are fetched using new template generated files called `python_version.py`
- Dockerfiles for the different Python Linux builds are now template generated.
- The "Supported Python Versions" section from READMEs of ancillary and main packages have been removed
Note: All the `python_version.py` files and Linux build `Dockerfiles` except `tools/dockerfile/grpc_artifact_python_linux_armv7/Dockerfile` in the PR are generated from the respective templates.
Further non-templated additions to add support for Python 3.13:
- install scripts and artifacts for windows, macos and linux are added manually. Later, these can be templated as well.
- updated cython bounds to 3.x
- updated twine version to solve [cgi module import error](https://github.com/pypa/twine/issues/1046)
- the twine update introduces a dependency on cryptography>=2.0. But the cryptography package doesn't support 32-bit Linux images and hence `twine check` has been disabled for x86 manylinux and x86 musllinux artifacts.
Closes#37643
PiperOrigin-RevId: 678954495
Passing manual build: https://btx.cloud.google.com/invocations/9adb3cd8-628c-42e5-a7a3-c2ba1ab6127f
<!--
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#37723
PiperOrigin-RevId: 677900305
<!--
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#37572
PiperOrigin-RevId: 670631284
gcc 7 and 8 docker images are based on Debian 10 with older cmake than gRPC needs. Since it's not easy to change the base Debian image for these docker images, let's install a newer cmake instead. This is a left-over from https://github.com/grpc/grpc/pull/37547.
Closes#37571
PiperOrigin-RevId: 668560102
Centos7 reached EOL on June 30th
The test was still working until google-protobuf released 3.25.4 a ~week ago, which seems to no longer compile on centos 7 b/c it needs a new header, `stdatomic.h`
Closes#37401
PiperOrigin-RevId: 659992748
The oldest gcc version that gRPC supports as of today is gcc 7 but gcc 7 has an issue with template supports that gRPC already picked up. Recently we managed to fix it in gRPC library code but we still have some in our test code. Given that it's not easy to fix since it requires many trial error approach to find a way to satisfy gcc 7 and eventually gcc 7 will be dropped from our supported compilers, let's have this mitigation where just main grpc++ target is being tested for gcc 7 so that users can use grpc with it without having to fix this hairy issue.
Fixes https://github.com/grpc/grpc/issues/36751Closes#37257
PiperOrigin-RevId: 654076384
<!--
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.
-->
Similar to https://github.com/grpc/grpc/pull/36755, this PR updates the image used by Go for interop tests that run against master.
Closes#36917
PiperOrigin-RevId: 644024756
Use the latest golang base image for Go interop tests. Presently the latest image points to Go 1.22.
<!--
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.
-->
## Commands run
To render the Dockerfile from its template
```sh
$ tools/buildgen/generate_projects.sh
```
To build and upload the base docker image.
```sh
$ tools/dockerfile/push_testing_images.sh
```
To build and upload the interop docker image for grpc-go 1.64.0
```sh
$ tools/interop_matrix/create_matrix_images.py --git_checkout --release=v1.64.0 --upload_images --language go
```
To verify the image is uploaded
```sh
$ gcloud container images list-tags gcr.io/grpc-testing/grpc_interop_go1.x
DIGEST TAGS TIMESTAMP
b36be4961ec4 infrastructure-public-image-v1.64.0,v1.64.0 2024-06-03T22:26:48
```
Verify the backward compatability tests pass
```sh
$ export docker_image=gcr.io/grpc-testing/grpc_interop_go1.x:v1.64.0
$ tools/interop_matrix/testcases/go__master
Testing gcr.io/grpc-testing/grpc_interop_go1.x:v1.64.0
```
Fixes: https://github.com/grpc/grpc/issues/36060Closes#36755
PiperOrigin-RevId: 641272572
All clang docker images here are based on Debian 11 (Bullseye) but now we're moving to Debian 12 (Bookworm) primarily to use the recent versions of Cmake >= 3.20 to use CXX_STANDARD=23 for some tests ([doc](https://cmake.org/cmake/help/latest/prop_tgt/CXX_STANDARD.html))
Closes#36810
PiperOrigin-RevId: 640688681
GCC 7 was disabled due to its gcc internal error while building protobuf C++. But we still need to support gcc7 and there appear to be issues causing gcc 7 to not build grpc so let's reintroduce gcc 7 test.
Closes#36565
PiperOrigin-RevId: 631947203
This is the same change as in #36556, but the change was committed without the second commit that existed in the PR (due to a very wide wait-for-CI-before-syncing race).
The sha here is what's currently in testing-images-public. I don't know where it came from but it has the proper update.
Closes#36562
PiperOrigin-RevId: 631871629
The last time it was rebuilt, the base image (dart:stable) seems not to have been updated. grpc-dart is now requiring newer dart version and is currently failing: https://github.com/grpc/grpc-dart/issues/705Closes#36556
PiperOrigin-RevId: 631850210
Updated `push_testing_images.sh` to add an additional tag, `infrastructure-public-image-HASH` to a new image to be excluded from the GCP Vulnerability scanner.
To reviewer:
- Only `tools/dockerfile/push_testing_images.sh` has an interesting change (adding a new tag)
- Clang 6 and 17 don't have an actual change other than clean-up which is to test if the script is working.
Closes#36341
PiperOrigin-RevId: 623944712
Typo introduced in: https://github.com/grpc/grpc/pull/34450
<!--
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.
-->
### NOTE
* We shouldn't merge this PR until GCP cloud functions drops support for Python 3.7 ([Currently scheduled for GCF](https://cloud.google.com/functions/docs/runtime-support#python))
As part of supporting Python 3.12, we're now officially drop support for Python 3.7.
This PR:
* Changed supported Python version from 3.7 to 3.8 in README.
* Replaced distribution test image from `debian:buster` to `debian:bullseye` since the default Python version in buster is 3.7.
<!--
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#34450
PiperOrigin-RevId: 622899511
This commit does the following 3 things for Android bazel rules, which depends on each other
1. Update NDK to 26.2.11394342 (and a few other Android things)
2. Use rules_android_ndk instead of builtin `native.android_ndk_repository`
* `third_party/android/android_configure.bzl` was a workaround for users who don't set `$ANDROID_NDK_HOME` env var. Now with rules_android_ndk, we can declare repo without registering the toolchain. Instead users who need NDK toolchain should use `--extra_toolchains` to manually register the toolchain, as shown in README.md.
3. Migrate to platforms. See https://bazel.build/concepts/platforms
* Currently we declares android platforms that is needed for binder transport APK. Later gRPC repo can gradually migrate to platforms for other platforms.
* The value of `crosstool_top` will still be `//external:android/crosstool` (which is the default value), so existings android `config_settings` will still work. We should migrate them to match with `@platforms//os:android` constraint later.
The platforms migration needs Bazel 7.0 to work so we also override bazel version in testing scripts.
Closes#36116
PiperOrigin-RevId: 617244655
Refactored android-ndk docker image to have
- Replaced a full Android SDK with a Android command line tool (generally good for docker usage) and bumped its version to the latest among ones that support JDK 11
- Upgraded Debian from 10 to 11
- Upgraded Java SDK 8 to 11
- Upgraded Google CLI to the latest
Closes#36091
PiperOrigin-RevId: 615088973
Fix the docker image for C# distribution tests - csharp_ubuntu2204_x64
The package that installed the .NET 7.0 SDK is missing setting up links and thus the `dotnet` command cannot find the SDK. Setting this links has been added to the dockerfile.
**NOTE**: I'm unable to update `tools/dockerfile/distribtest/csharp_ubuntu2204_x64.current_version` as I don't have access to the artifact registry.
Closes#36019
PiperOrigin-RevId: 611590679
The current .NET SDK in these tests is EOL, and we've been seeing strange SSL errors transiently.
Update to a supported version and remove cruft in the docker image that was there to install the older version.
TODO: submitting first with the ubuntu 22.04 image test skipped, need to follow-up with a fix and unskip the test
Closes#35955
PiperOrigin-RevId: 610798209
- Dropped Ruby 2.7 test (Ruby 2.7 hit EOL 1 year ago)
- Upgraded the base image of Ruby docker images from Debian:10 to Debian:11 (Debian:10 hit EOL)
Closes#35911
PiperOrigin-RevId: 607088383
rebuilt `tools/dockerfile/distribtest/csharp_ubuntu2204_x64/Dockerfile` (without actually changing anything in the docker instructions) in an attempt to fix `The SSL connection could not be established, see inner exception.` errors happening in `dotnet restore` commands in distrib tests using this image.
Closes#35674
PiperOrigin-RevId: 601856906
Esun Kim
Kannan J
AJ Heller
Arjan Singh Bal
Sreenithi Sridharan
Yijie Ma
Eugene Ostroukhov
Nathan Baulch
apolcyn
Yash Tibrewal
Eric Anderson
Xuan Wang
Ming-Chuan
tony