Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Problem/Motivation
Spin off of #3515706: [CI] Switch the default test environment to PHP 8.4 and MySQL 8.4 .
Proposed resolution
Separate running PHPStan job on PHP 8.4 in this issue.
In the process, make PHPStan execute from the base project directory (that varies per run) instead of the fixed /build directory.
Remaining tasks
User interface changes
Introduced terminology
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|
Issue fork drupal-3525031
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
mondrakeUpdating the baseline seems ineffective.
Comment #6
mondrakeThis is weird. It looks like CI is stashing the
.phpstan-baseline.phpfile away, and using it instead of the one in the MR (see https://git.drupalcode.org/project/drupal/-/merge_requests/12150/diffs?c... that is emptying the MR's version of the file, still old report appears)Comment #7
mondrakeTried running locally, no errors.
Comment #8
mondrakeFrom some debugging, I'm inclined to think that somehow the composer steps are overwriting the MR content - just at the beginning of the job the bait file I placed is present, once we get to run PHPStan it's no longer there
Comment #9
mondrakeThe culprit is
composer run-script drupal-phpunit-upgrade-check: that script leads to the baseline file from the MR being overwritten by the one in HEAD.That is clearly visible here https://git.drupalcode.org/issue/drupal-3525031/-/jobs/5291184 where I made debug addition to report the datetime of the .phpstan-baseline.php file at various points of the script execution: the file is the MR's one until the execution of that script, and the HEAD one just afterwards.
At closer inspection, found that the the PHPUnit jobs work fine. There, the composer jobs are run on the GitLab project directory. So the problem is with moving the codebase to the /build directory BEFORE summoning composer.
Made changes so that the composer stuff is executed in the before_script section of the job and before moving the codebase to the /build directory, this now seems ok.
Bumping to critical because regardless of this issue, the buggy behaviour is in HEAD right now.
Comment #11
mondrakeComment #12
andypostRTBC as it's green, curious if other jobs also has broken order of dealing with codebase
from slack
Comment #13
mondrakeComment #14
mondrakeFIled #3525143: [CI] Run PHPStan job in the GitLab project directory instead of /build for follow up.
Comment #15
mondrakeLint cache warmingwill not work proper with this, the cache would be taken from the wrong place. I think it's better go straight ahead and do what #3525143: [CI] Run PHPStan job in the GitLab project directory instead of /build would do. Doing it here so we can keep the status and history.Comment #16
mondrakeComment #17
mondrakeAdded comments across the entire script.
Comment #18
smustgrave commentedLets do it, feedback for comments seems to be addressed.
Comment #19
mondrakeUpdated IS because the problem is not an override of the code, but from where the job executes.
Comment #20
mondrake.. and it's not Critical. Maybe Major since we're in the middle of the river crossing from default PHP 8.3 to default PHP 8.4 for GitLab jobs.
Comment #21
mondrakeBetter wait for #3497431: Deprecate TestDiscovery test file scanning, use PHPUnit API instead that is now partially overlapping.
Comment #22
mondrakeBlocker is in. Rebased.
Comment #24
catchCommitted/pushed to 11.x and cherry-picked to 11.2.x, thanks!
Comment #26
mondrakeSeems wasn't pushed to 11.x
Comment #28
catchNeeded to fetch locally..
Comment #29
catchI think this broke PHP artifact caching, see the "Result cache not used" line on https://git.drupalcode.org/issue/drupal-3532871/-/jobs/5705047 - could we open a follow-up to run phpstan inside the build directory again?
Comment #30
mondrakeCan we try and make it work with latest approach instead of reverting to run on /build/?
This issue is enabling #3532407: [pp-upstream][CI] Stop post editing re-generated PHPStan baseline that would be a pity to lose.
Comment #31
mondrakeSo the problem here is Relative path in ResultCache?
Comment #32
catch@mondrake yes that's exactly the one - similar problems with cspell et al caches too.
Comment #33
mondrakeDrats! Tried having a look at the phpstan cache, definitely worse to try and manipulate that than keeping manipulating the baseline. So for the moment there's no alternative to running on /build/.
Comment #35
mondrakeMR!12534 restores running the job from
/build/; not sure about cache warming as I think it needs to be committed to verifyComment #36
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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 #37
mondrakeComment #38
catchYes this is unfortunately true, it's very hard to test without a commit especially the build directory stuff. However as long as the main phpstan job is working fine the consequences of not fixing caching are that caching still doesn't work so fine to try it and check post-commit (which what I said I'd do in https://www.drupal.org/project/drupal/issues/3525031#mr12150-note518482 then forgot until 3/4 weeks later...)
Comment #39
larowlanComment #40
mondrakeComment #41
smustgrave commentedAppears to have some pipeline issues, should it be postponed on #3530453: Remove deprecated use of Assert::isType() seems to be addressing some of the same right?
Comment #42
mondrakeSorry I can't understand #40 - tests are green and the comment seems not related to this issue. Can you elaborate please?
Comment #43
smustgrave commentedMy mistake think I had another MR open for 8.4 that wasn't this, sorry for the noise.
Comment #44
mondrakeDiscussed this issue status in Slack, https://drupal.slack.com/archives/C079NQPQUEN/p1752837466231169
Return this to Fixed as it was before reopening. PHPStan is already running on PHP 8.4 as part of separate issue, so I will file a separate issue for the follow-up currently open.