[Bug]: `option --coverage is ambiguous` in CI worker. #1030

Closed ElteHupkes closed 7 months ago

What Happened

My issue is very similar to #94 , except it happens GitLab CI, and the suggested fix doesn't apply (because the command doesn't include --no-scripts in the first place). This is the relevant CI entry:

test_api:
  stage: test
  coverage: /^\s*Cov:\s*\d+\.\d+?%$/
  variables:
    XDEBUG_MODE: "coverage"
    APP_ENV: "testing"
  cache:
    key: "${CI_JOB_NAME}-build"
    paths:
      - vendor
  artifacts:
    reports:
      junit: report.xml
    expire_in: 3 days
  only:
    - merge_requests
    - develop
    - staging
  script:
    - php -m
    - cp .env.gitlab-ci .env.testing
    - composer install
    - php artisan key:generate
    - php artisan optimize
    - vendor/bin/pest \
      --coverage \
      --log-junit report.xml \
      --colors=never \
      tests \
      --configuration phpunit.xml --colors=never --stop-on-failure

And the output:

....
$ vendor/bin/pest --coverage --log-junit report.xml --colors=never tests --configuration phpunit.xml --colors=never --stop-on-failure
   INFO  Option "--coverage" is ambiguous.
....

This started happening after upgrading to Laravel 10 / Pest 2 (latest version on both). Previously I had --coverage-text in the command, but while it runs with that, it doesn't give me any coverage output. Locally the command runs without any issues.

I added cat vendor/pest-plugins.json to the command list at some point to see if the autoloader ran, and that file is present and contains all the plugins. Still, the error implies that the Coverage plugin isn't invoked, because from what I can tell it would replace the --coverage option internally if it were.

If anybody has an insight into why this is happening, I'm all ears.

How to Reproduce

This is happening on all projects I've tried to upgrade so far, they're all set up with a CI setup similar to what's mentioned above. They all use the php:8.1.6-fpm-bullseye image with composer installed with:

curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/bin/ --filename=composer

Sample Repository

No response

Pest Version

2.28.0

PHP Version

8.1.6

Operation System

Linux

Notes

No response

After writing a script that (desperately) injected some debugging code into several Pest functions before running, I noticed that I was getting the following argument array in PHP:

0 => 'vendor/bin/pest',
  1 => ' --coverage',
  3 => ' --log-junit',
  4 => 'report.xml',
  5 => ' --colors=never',
  6 => ' tests',
  7 => ' --configuration',
  8 => 'phpunit.xml',
  9 => '--colors=never',
  10 => '--stop-on-failure',
  11 => '--cache-directory=/builds/novacair/config-service/vendor/pestphp/pest/.temp',
  12 => '--cache-result',

So there is, in fact, a space in front of all the arguments I supplied myself. Looking more carefully at what GitLab actually ran, it seems that the back slashes I'm using in the command list to escape newlines get misplaced to actually escape a space in front of each argument.

This doesn't seem to be an issue for any of the other arguments (I guess the command parser handles trimming them further down the line), but since Coverage::handleArguments() compares the literal arg with the space in front of it, this falls on its face.

I'm considering this 99% a freak configuration issue and 1% something that's worthy of your time to fix, so I'm going to close this issue. If anybody encounters this in the future though: try if putting your entire command on one line fixes the issue.

Hello,

I get the same error even if the gitlab CI script command is in one line:

script:
    - vendor/bin/pest --coverage --colors=never --coverage-cobertura coverage-cobertura.xml --log-junit junit-report.xml

I also tried vertical aligned parameters, but the problem persists.

  script:
    - vendor/bin/pest
      --coverage
      --colors=never
      --coverage-cobertura coverage-cobertura.xml
      --coverage-html coverage.html
      --log-junit junit-report.xml

Is there any solution to avoid this problem?

@moranda Sorry, I have no idea, I solved my problem the way I described it. I can't offer any advice other than monkey patching Pest inside your build script to print out some internals and figure out what's happening.

pestphp / pest