PHPUnit fails due to unknown output.

[安永 大輝]

Hello,

I am having trouble running PHPUnit in Pipeline.
Running PHPUnit locally will be successful.

PHPUnit 6.5.9 by Sebastian Bergmann and contributors.

.
.............................................................. 63 / 544 ( 11%)
............................................................... 126 / 544 ( 23%)
............................................................... 189 / 544 ( 34%)
............................................................... 252 / 544 ( 46%)
............................................................... 315 / 544 ( 57%)
............................................................... 378 / 544 ( 69%)
............................................................... 441 / 544 ( 81%)
............................................................... 504 / 544 ( 92%)
........................................ 544 / 544 (100%)

Time: 8.51 minutes, Memory: 128.25MB

OK (544 tests, 6301 assertions)

But pipeline fails with unknown output.

PHPUnit 6.5.9 by Sebastian Bergmann and contributors.
.
.............................................................. 63 / 544 ( 11%)
............................................................... 126 / 544 ( 23%)
............................................................... 189 / 544 ( 34%)
............................................................... 252 / 544 ( 46%)
............................................................... 315 / 544 ( 57%)
............................................................... 378 / 544 ( 69%)
............................................................... 441 / 544 ( 81%)
............................................................... 504 / 544 ( 92%)
2020-09-03T07:31:02.15869381Z stdout P ............................

I don't know why the timestamp is being output.
Please give me some advice.

[安永 大輝 · Accepted solution]

Resolved.

The following option was successful.

- vendor/bin/phpunit -d memory_limit=512M

[ktomk]

@安永 大輝 just some background information that might also help others: Please check the PHP image in use and especially the memory_limit configuration.

While normally the PHP CLI (Command Line Interface) binary comes by default with no memory limit (as for the command line, memory_limit value is -1 which means unlimited), the official PHP docker images in the CLI flavors have a memory limit configured, e.g.:

• php:7.4-cli - memory_limit => 128M => 128M
• php:7.4-alpine - memory_limit => 128M => 128M

(command: `$ docker run --rm php:7.4-cli -i | grep memory_limit`)

For PHPUnit this can be configured in the phpunit.xml configuration file (ini entry) which does override the memory_limit setting then. Using the Phpunit configuration file for this ensures to have the memory_limit setting configured within the project, e.g. it is automatically set to the same value locally as well as running in containers.

If more PHP based tools are part of the tool-chain and Composer is used to manage project dependencies, it is also possible to create script entries within composer.json and make use of the "@php" notation to refer to the PHP binary with the a setting like `-d memory_limit=512M` and even others that might not be able to be set via `ini_set()` (which is how it is done for phpunit.xml AFAIK).

This has the additional benefit that with low values like 128M for memory_limit, they become automatically upgraded to 1536M as composer raises the memory_limit if considered too low for command line operations:

{
  "scripts": {
    "phpunit": [
      "@php -d phar.readonly=0 -f vendor/bin/phpunit -- -v"
    ]
  }
}

Command:

- composer phpunit

(test with Composer version 1.10.1)

This requires to have composer within the step image/container however, so requires more integration. It can however help in shared PHP projects which are managed by Composer as all these scripts are available after clone/checkout and `composer install`, which for Composer managed PHP projects is likely to happen within pipeline/build steps, too.

This has the additional benefit that Composer will make non-zero exit status more visible as well, which is often useful to trouble-shoot issues like these.

HTH.

[安永 大輝]

@ktomk 
Thank you!
I'll try that method.