Using 8.2-dev-4.50.0 (gRPC extension) causes PHPCS to hang if --parallel is used
#102
Comments
|
comment was moved into issue summary above |
mbomb007
changed the title
mbomb007
changed the title
|
After trying a couple more things, I found that either removing |
mbomb007
changed the title
--parallel is used.
mbomb007
changed the title
--parallel is used.--parallel is used and >= 2
|
My guess the difference is Alpine version and maybe phpcs depended on some packages that were missing or updated in 3.19. Could you try |
|
I tried just now and the newer stability tag didn't fix the problem. The only dependencies PHPCS needs are: "require": {
"php": ">=5.4.0",
"ext-simplexml": "*",
"ext-tokenizer": "*",
"ext-xmlwriter": "*"
}, |
|
I found the cause of the issue. grpc/grpc#20250 (comment) Debug code# Check php.ini values.
test=$(php -r "echo ini_get('pcre.jit');")
echo "pcre.jit: $test"
# Can PCRE JIT be disabled? PHPCS does this in its code.
test=$(php -r "ini_set('pcre.jit', false);echo ini_get('pcre.jit');")
echo "pcre.jit: $test"
test=$(php -r "echo ini_get('grpc.enable_fork_support');")
echo "grpc.enable_fork_support: $test"
test=$(php -r "echo ini_get('grpc.poll_strategy');")
echo "grpc.poll_strategy: $test"
# Will it work if grpc values are set properly?
echo "grpc.enable_fork_support = 1" >> /usr/local/etc/php/conf.d/docker-php-ext-grpc.ini
echo "grpc.poll_strategy = epoll1" >> /usr/local/etc/php/conf.d/docker-php-ext-grpc.ini
test=$(php -r "echo ini_get('grpc.enable_fork_support');")
echo "grpc.enable_fork_support: $test"
test=$(php -r "echo ini_get('grpc.poll_strategy');")
echo "grpc.poll_strategy: $test"Output:ExplanationFrom my tests, PHPCS should be able to disable If the gRPC extension is enabled, then these options must be set for parallel to work: grpc.enable_fork_support = 1
grpc.poll_strategy = epoll1They aren't set, though. The initial/default values are as follows, which causes the parallel execution to fail: grpc.enable_fork_support = 0
grpc.poll_strategy = Further explanation of why it causes it to fail is here. Setting them to the necessary values from Bash prior to running PHPCS led the commands to succeed again. Could these values be set in the Dockerfile, similar to what was done here? |
|
While I have an issue open for PHPCS to hopefully set the ini values in its code, it would still be ideal if they could be set in the Dockerfile for this project (or wodby/php upstream) as well. |
mbomb007
changed the title
--parallel is used and >= 2--parallel is used
|
Hi, please try 4.53.0, it now has env vars to configure GRPC extension and updated default values (fork support and poll strategy) https://github.com/wodby/php/blob/master/8/templates/docker-php-ext-grpc.ini.tmpl |
|
Yes, that fixed it. Thanks. |
For some reason, using
wodby/drupal-php:8.2-dev-4.49.0works, but images withwodby/drupal-php:8.2-dev-4.50.0or newer cause PHPCS to hang, but only if PHPCS is run without verbose flag, or with the single-level verbosity-v. If PHPCS is run with-vvor-vvv, PHPCS runs successfully. The same problem occurs if I use PHP 8.3 instead of 8.2 and use the newest image and stability tag.Further debugging revealed that this is because extra-verbose output means that sniffs cannot be run in parallel. Removing the
--paralleloption or setting--parallel=1will also fix the hanging issue. Using a new image along with the--paralleloption greater than1is what causes execution to hang.My goal is to be able to use 4.51.0 or higher, since PHP 8.3 support was added.
Debugging Details and Steps to Reproduce
Click to view
The PHPCS command:
custom_ruleset.xml
composer.json
{ "require-dev": { "dealerdirect/phpcodesniffer-composer-installer": "^1.0", "drupal/coder": "^8.3", "phpcompatibility/php-compatibility": "^9", "roave/security-advisories": "dev-latest", "squizlabs/php_codesniffer": "^3.8.1" }, "prefer-stable": true, "scripts": { "install-codestandards": [ "PHPCSStandards\\Composer\\Plugin\\Installers\\PHPCodeSniffer\\Plugin::run" ], "post-install-cmd": [ "@install-codestandards" ], "post-update-cmd": [ "@install-codestandards" ] }, "config": { "sort-packages": true, "allow-plugins": { "dealerdirect/phpcodesniffer-composer-installer": true } } }The output when running hangs and the PHPCS command adds the first level of verbosity with
-v:Then the output hangs.
web_modules_custom.zip
This is almost the exact contents of the folder PHPCS is being run on. I excluded a composer.json file and changed a module's name.
If I run on an image with stability tag 4.49.0 or earlier, the same PHPCS command and composer.json runs successfully, regardless of the verbosity
-vflag level included. This is the expected output:Debugging Update & Workaround
After trying a couple more things, I found that either removing
--parallelfrom the PHPCS command, or setting its value to1, will fix issue on the newer images. This also makes sense with the verbosity flags since, I assume, when verbose is enabled at a high level then sniffing cannot be parallelized.So, this means that the newer images break parallel execution of sniffs for some reason. Removing the
--paralleloption isn't ideal, obviously, as this increases the execution time. So hopefully this information can point towards the cause of the issue and a fix to follow.The text was updated successfully, but these errors were encountered: