[CI] Run PHPStan job on PHP 8.4

Updating the baseline seems ineffective.

This is weird. It looks like CI is stashing the .phpstan-baseline.php file 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)

Tried running locally, no errors.

From 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

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

mondrake → changed the visibility of the branch 3525031-cirun-phpstan-job-fix to hidden.

RTBC as it's green, curious if other jobs also has broken order of dealing with codebase

from slack

...a problem with the sequence of the steps: composer was getting called after the codebase had been already moved to /build

that for some reason makes the update script override core with the HEAD version

that does not occur if you call composer on the gitlab project directory, as the phpunit jobs do

FIled 📌 [CI] Run PHPStan job in the GitLab project directory instead of /build Postponed  for follow up.

Lint cache warming will not work proper with this, the cache would be taken from the wrong place. I think it's better go straight to doing what 📌 [CI] Run PHPStan job in the GitLab project directory instead of /build Postponed would do. Doing it here so we can keep the status and history.

Added comments across the entire script.

Lets do it, feedback for comments seems to be addressed.

Updated IS because the problem is not an override of the code, but from where the job executes.

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

Better wait for 📌 Deprecate TestDiscovery test file scanning, use PHPUnit API instead Active that is now partially overlapping.

Blocker is in. Rebased.

Committed/pushed to 11.x and cherry-picked to 11.2.x, thanks!

catch → closed merge request !12150

Seems wasn't pushed to 11.x

Needed to fetch locally..

I 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?

Can we try and make it work with latest approach instead of reverting to run on /build/?

This issue is enabling 📌 [CI] Stop post editing regenerate PHPStan baseline Active that would be a pity to lose.

So the problem here is https://github.com/phpstan/phpstan/issues/8599?

@mondrake yes that's exactly the one - similar problems with cspell et al caches too.

Drats! 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/.

MR!12534 restores running the job from /build/; not sure about cache warming as I think it needs to be committed to verify

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

not sure about cache warming as I think it needs to be committed to verify

Yes 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 📌 [CI] Run PHPStan job on PHP 8.4 Active then forgot until 3/4 weeks later...)

Appears to have some pipeline issues, should it be postponed on 📌 Remove deprecated use of Assert::isType Active seems to be addressing some of the same right?

Sorry I can't understand #40 - tests are green and the comment seems not related to this issue. Can you elaborate please?

My mistake think I had another MR open for 8.4 that wasn't this, sorry for the noise.