Add config to run additional PHP tests per PR#23321
Add config to run additional PHP tests per PR#23321stanley-cheung wants to merge 1 commit intogrpc:masterfrom
Conversation
3ea9a54 to
3a81a81
Compare
|
So this should be ready to be reviewed. Here's an adhoc run (on I also try to run this against the
|
b5c9c7f to
5ac186e
Compare
5ac186e to
cae209d
Compare
|
While I appreciate the attempt to add more test coverage for things that got broken in the past, I think we need a better and more organized approach than adding a new kokoro job each time something breaks (because the kokoro jobs get unmanageable pretty soon and we already have a lot of them - and every "special" job makes things harder to maintain). |
|
I also just realized that there are already tests executing this build path for PHP in the This test suite has been broken since #21941 is merged. Looks like some Python distribtests are failing too. |
|
So is this PR safe to close? |
|
Yes closing this. |
For #23307
In #21941 , there was a core change related to
upb, and later we discovered (via the xDS tests breakage) that that change broke thepecl installbuild of the PHP extension. That breakage wasn't discovered early primarily because we build the PHP extension slightly differently in the PR tests vs in the xDS tests, which are only run inmaster. In the PR tests, c-core was compiled and installed first and then the PHP extension was built in a 'thin' way. See here. But in the xDS tests, the pecl extension was built fully as if an end user would have used it (i.e. tgz archive, and thenpecl install). See here.So in order to make sure we test this
pecl installway, in PR, I'd like to have a new entry point Kokoro config to run additional tests for PHP. This PR adds the config and entry point script for it. There's a corresponding internal CL to add the corresponding Kokoro config.We already have a series of docker images here that will build the grpc PHP extension the
pecl installway and test our grpc PHP extension against a variety of different PHP runtimes. So I'd like to hook those up to be run every pull request.The concern (why that script was never hooked up before) was that right now we have 9 such PHP docker images and the script wasn't optimized much at all so the script takes an hour or so to run. In order to not draw too much resources to each PR test run, I only run 2 such docker images for now, which would finish around 5-10 minutes, and still should be able to catch a class of errors/breakages as the c-core is being updated.
In the future, there are probably a few things we can do to
tools/internal_ci/linux/grpc_php_run_extratests.shto run the rest of the docker images. And as a follow up I can see how to hook up the proper log file, etc.