Problem/Motivation
Follow-up of #3485069: [CI] Spin off Drupal Components tests in a job of their own, add test coverage metrics.
Components tests coverage metrics differ slightly by PHP version, and apparently the last PHP version job completing the components unit test is winning the box. Not a big deal, but this can cause some confusion when looking at test results and seeing that metrics are changing even if components code/tests are not part of the MR.
Example from HEAD on Apr 28, 2025:
PHP 8.3 and 8.4
Classes: 31.62% (37/117)
Methods: 46.88% (315/672)
Lines: 36.59% (2782/7604)
PHP 8.5
Classes: 30.77% (36/117)
Methods: 46.43% (312/672)
Lines: 36.53% (2778/7604)
Proposed resolution
Solution 1 from the list below.
Possible solutions:
- Produce code coverage report only in the job running the default PHP version; no code coverage for the other PHP versions.
- Produce a different set of metrics for each PHP version.
- Investigate why the differences and try to remove them (might be impossible if there are code paths dependent on PHP version checking)
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
Comments
Comment #3
mondrakeMR implements option 1 from the issue summary. IMHO option 2 is overkill and 3 is complicated and risk regressions easily.
Comment #4
catchYeah only for the default PHP version sounds good to me too.
Comment #5
smustgrave commentedAssuming this will have to be tweaked when https://www.drupal.org/project/drupal/issues/3515706 lands?
Comment #6
mondrakeWhy so?
Comment #7
smustgrave commentedDidn't mean to change status but if 8.4 is a default won't this change need to apply to 8.4
Comment #8
mondrakeAh! No it’s already for 8.4, check the MR - 8.3 and 8.5 are getting the “no-coverage” job settings. Anyway this is about components unit tests which are getting rather independent as we speak.
Comment #9
smustgrave commentedThanks for clarifying!
Comment #10
mondrakeSorry, I found opportunities to remove duplication
Comment #11
smustgrave commentedClean up seems to be good
Comment #12
mondrakeComment #13
mondrakeAdjusted post-#3418267: Support PHPUnit 11 in Drupal 11.
Letting PHPUnit's own deprecations fail the job execution on PHPUnit 8.5 as the purpose of that job is precisely to shout out when language deprecation or changes occur in this stage of PHP development, so I thought it is a good spot where to let PHPUnit shout as well.
With the
PHPUNIT_FAIL_ON_PHPUNIT_DEPRECATIONjob variable it's a piece of cake to silence them if we do not manage to solve them before PHP 8.5 is released.Comment #14
mondrakeComment #15
mondrakeComment #16
smustgrave commentedStill seems worth adding.
Comment #17
mondrake#3525031: [CI] Run PHPStan job on PHP 8.4 needs to go in first as it fixes a nasty bug that would impact here.
Comment #18
mondrakeComment #19
mondrakeComment #20
mondrakeComment #21
mondrakeComment #22
mondrakeComment #23
mondrakeComment #24
mondrakeComment #25
mondrakeComment #26
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".
This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.
Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.
Comment #27
mondrakeComment #28
smustgrave commentedAdditional changes look good to me
Comment #29
catchNeeds a rebase. I've looked at this one a couple of times, but as with all pipeline changes, find it hard to meaningfully review it / predict whether it will work etc. Since it's only the pipeline changes it should be low risk to find out though.
Comment #30
mondrakeRebased.
Comment #31
alexpottWe should also make the coverage version run on performance and the others not.
Comment #32
mondrakeJust local naming changes, back to RTBC.
Comment #33
mondrakeAddressed reviews.
Comment #34
alexpottCommitted and pushed c5beab93a87 to 11.x and 929fbcab120 to 11.3.x. Thanks!
Comment #38
alexpottWe broke this in #3515704: [CI] Move unit tests to a 'unit tests' stage as component tests are again excluded from the performance tests. Let's re-open this one and fix it here...
Comment #41
mondrakeComment #45
catchCommitted/pushed to 11.x and cherry-picked to 11.3.x, thanks!