search

edbizarro / gitlab-ci-pipeline-php

:coffee: Docker images for test PHP applications with Gitlab CI (or any other CI platform!)
https://hub.docker.com/r/edbizarro/gitlab-ci-pipeline-php
MIT License
528 stars 166 forks source link

xdebug configuration change - breaks coverage reports #105

Open robertdeboer opened 3 years ago

robertdeboer commented 3 years ago

We use this image for running PHPUnit test in as part of our GitLab CI process for projects. Today I have noticed that running PHP Unit configurations with clover reports for coverage no longer creates these reports.

In order to verify if it was something within the docker environment,I have gone to other another project that uses the same image and push a small text file to trigger the CI and confirmed the coverage report is not being created. Looking at past CI pipelines, my last successful run was 1 month ago

image

The next job - ran a week or so after that is when I first see this issue pop up:

image

Using the latest PHPUnit produces the following: image

When I grep XDebug settings as a pre-script action, I see the following:

/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini,
xdebug
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
xdebug.auto_trace => no value => no value
xdebug.cli_color => 0 => 0
xdebug.client_discovery_header => no value => no value
xdebug.client_host => localhost => localhost
xdebug.client_port => 9003 => 9003
xdebug.cloud_id => no value => no value
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => no value => no value
xdebug.collect_params => no value => no value
xdebug.collect_return => Off => Off
xdebug.collect_vars => no value => no value
xdebug.connect_timeout_ms => 200 => 200
xdebug.coverage_enable => no value => no value
xdebug.default_enable => no value => no value
xdebug.discover_client_host => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => no value => no value
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => no value => no value
xdebug.gc_stats_output_dir => no value => no value
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => no value => no value
xdebug.log => no value => no value
xdebug.log_level => 7 => 7
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.mode => develop => develop
xdebug.output_dir => /tmp => /tmp
xdebug.overload_var_dump => no value => no value
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => no value => no value
xdebug.profiler_enable_trigger => no value => no value
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => no value => no value
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_autostart => no value => no value
xdebug.remote_connect_back => no value => no value
xdebug.remote_enable => no value => no value
xdebug.remote_handler => no value => no value
xdebug.remote_host => no value => no value
xdebug.remote_log => no value => no value
xdebug.remote_log_level => no value => no value
xdebug.remote_mode => no value => no value
xdebug.remote_port => no value => no value
xdebug.remote_timeout => no value => no value
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => no value => no value
xdebug.start_upon_error => default => default
xdebug.start_with_request => default => default
xdebug.trace_enable_trigger => no value => no value
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => no value => no value
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trigger_value => no value => no value
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3

Here is the GitLab CI file for the project

stages:
  - test
  - quality
  - deploy

phpunit:
  stage: test
  image: edbizarro/gitlab-ci-pipeline-php:7.4
  before_script:
    - composer install
    - cp .env.example .env
    - php artisan key:generate
  script:
    - ./vendor/bin/phpunit --testdox --verbose --configuration phpunit.xml
  artifacts:
    reports:
      junit: tests/coverage/junit.xml
    paths:
      - tests/coverage/clover.xml
      - tests/coverage/junit.xml
    expire_in: 1 days
  variables:
    GIT_DEPTH: 0
  only:
    - develop
    - master
    - merge_request

To me this looks like a dependency changed it's setup or configuration that the docker image uses, thus changing the environment by accident.

robertdeboer commented 3 years ago

If it helps any, I cleared out our runner docker image cache around 2 weeks ago to get room on the runner and to clear out unused image. So it would of have to pulled the latest image and re-ran the docker scripts after that.

robertdeboer commented 3 years ago

A possible solution would be to add some configs as is done for OpCache

{ \
    echo 'xdebug.coverage_enable=1'; \

} > /usr/local/etc/php/conf.d/20-xdebug.ini
stephane-poirier-umrsu commented 3 years ago

I just encountered a similar issue. Tests on Gitlab CI were running fine last week (using XDebug v2.9.8) and started failing today (using Xdebug v3.0.0beta1). Code hasn't changed much. The most likely cause seems to be the XDebug upgrade, or another change in the docker image.

My error message is different, though. I get a Segmentation fault (core dumped) / error code 139.

Here a the relevant logs:

Pulling docker image edbizarro/gitlab-ci-pipeline-php:7.3 ...

$ php -v
PHP 7.3.23 (cli) (built: Oct 13 2020 10:26:06) ( NTS )
[...]
Zend Engine v3.3.23, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.23, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v3.0.0beta1, Copyright (c) 2002-2020, by Derick Rethans

> phpunit -c phpunit.dev.xml --colors=never --stderr --log-junit phpunit-report.xml --coverage-text
PHPUnit 9.3.2 by Sebastian Bergmann and contributors.
Warning:       xdebug.mode=coverage has to be set in php.ini
...............................................................  63 / 125 ( 50%)
....................................................Segmentation fault (core dumped)
Script phpunit -c phpunit.dev.xml --colors=never --stderr --log-junit phpunit-report.xml --coverage-text handling the coverage-ci event returned with error code 139
chiiya commented 3 years ago

Experiencing the same issue (Segmentation fault) in all of our pipelines. Any plans to merge the attempted fix?

Edit: Segmentation fault only occurs for the 7.3 image. 7.4 works, but throws the xdebug.coverage_enable=On has to be set in php.ini Error.

MatusBoa commented 3 years ago

Same for me

Error: xdebug.coverage_enable=On has to be set in php.ini

Using 7.4 version

bu4ak commented 3 years ago

Same issue for 7.4

7.4-alpine works fine

edbizarro commented 3 years ago

I change xdebug back to 2.9.8 until PHP 8 release, i believe that everything should work now

rocksfrow commented 3 years ago

@edbizarro we're seeing segfaults in CI (using 7.3 image) -- I see xdebug 3.0.2 instead of 2.x again.

did you change your mind on keeping xdebug frozen at 2.x until php 8? based on the commit referenced above I'm guessing maybe this was an upstream change? thoughts?

Our latest failing CI:

PHPUnit 8.5.13 by Sebastian Bergmann and contributors.
Runtime:       PHP 7.3.26 with Xdebug 3.0.2

...../bin/bash: line 132:  1150 Segmentation fault

Our latest passing CI:

PHPUnit 8.5.13 by Sebastian Bergmann and contributors.
Runtime:       PHP 7.3.24 with Xdebug 2.9.8
rocksfrow commented 3 years ago

This works for now:

before_script:
    - sudo pecl uninstall xdebug && sudo pecl install xdebug-2.9.8
edbizarro commented 3 years ago

hi @rocksfrow with the release of PHP 8 I think we can move forward to support only xdebug 3 as the default one

Ref: https://xdebug.org/docs/compat#versions

chiiya commented 3 years ago

That would break all projects running older versions of PHPUnit (including still supported Laravel versions such as 7.x)

rocksfrow commented 3 years ago

I guess I will stick w/ my before_script usage to avoid the seg faults until we can figure out what in the hell incompatible extension is causing these seg faults then. thanks for the feedback.

evs-xsarus commented 3 years ago

Magento 2 also breaks with XDebug as it throws:

Fatal error: Uncaught Error: Call to undefined function xdebug_disable() in /builds/lov/magento2/vendor/magento/magento2-functional-testing-framework/src/Magento/FunctionalTestingFramework/_bootstrap.php on line 78