[CI] Switch the default test environment to PHP 8.4 and MySQL 8.4

Isn't it a bit too early for that? Still a lot of contrib modules still don't work well on PHP 8.3

I wonder would it make sense to switch to PHPUnit 11 for 8.4 too? And let 8.3 and below onto PHPUnit 10? https://stitcher.io/blog/php-version-stats-january-2025

In start of July first alpha of PHP 8.5 will arrive so no reason to wait

added https://packagist.org/php-statistics to summary

Added commit to switch MySQL to 8.4 (LTS) for the default pipeline

Ref https://dev.mysql.com/doc/refman/8.4/en/mysql-releases.html

Note: MySQL 8.0 is a Bugfix series that preceded the LTS release model.

lets do it!

8.0.34+ will transition to only bug fixes until 8.0 End-Of-Life (EOL) scheduled for April-2026

So nightly testing is good enough for support https://dev.mysql.com/blog-archive/introducing-mysql-innovation-and-long...

clearer title

@catch thank you, curious how perf tests are executed (I have no access to start'em) and how it vary from 8.3 at the end

FTR, weirdly, the revert also fixed the build tests failure lately in #3418267: Support PHPUnit 11 in Drupal 11. Ideally, it would preferable to postpone this one on that if there is interest to get PHPUnit 11 in Drupal 11.2 so that we do not have to play catch there.

Re-opened MR as MySQL 8.4 image is fixed via #3521926: Fix deprecated MySQL native passwords

See https://git.drupalcode.org/issue/drupal-3521851/-/jobs/5110756

I see the linked issue has been merged to "production" and "dev" so assuming that's what we use. So would this be good to go again

The 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.

Since bumping the default to 8.4 also forces the PHPUnit 11 bump for the PHPStan job, we now have a few more PHPUnit 11 errors that we should add to baseline.

I do not understand why despite adding the baseline update, PHPStan still fails.

Maybe bump PHPstan in separate issue?

Tried #28.

Keeping PHPStan job on PHP 8.3 let the job pass, but the Build tests failure seems legitimate.

Spinned off #3525031: [CI] Run PHPStan job on PHP 8.4

The Build test failure had the same root cause of #3525031: [CI] Run PHPStan job on PHP 8.4.

composer run-script drupal-phpunit-upgrade-check, run during the PHPCS lint job, flashes a new composer.lock file as well as the packages metadata json files. But only the /vendor folder is stored as an artifact, not the updated files.

The MR now is built on top of the one in #3525031: [CI] Run PHPStan job on PHP 8.4; it is extended by including also the updated files in the PHPCS artifacts.

The downside: now the composer build artifacts as built by PHP 8.4 are also used by the PHP 8.3 tests of the child pipelines.

Unfortunately the needs:job entry does not accept variables.

leaning on pipeline passing for this one.

Sorry, better wait for #3497431: Deprecate TestDiscovery test file scanning, use PHPUnit API instead that is now partially overlapping here too.

Tweaking this.

This could use a good look by @andypost if the php/db combinations are now accurate - a lot of changes and rebases of late here.

Filed #3531022: Let run-tests.sh print db type and version in the initial output that would help in a case like this.

Thank you looks good but something still fails

RTBCed #40 as it will help to debug real combination of php+db containers as I see something is not propagated from defaults

Seems to have a number of failures in package_manager but don't know if related.

(not so) random recurring test failures

The 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.

no more failures, except random