The phpstan job returns errors about missing artifact files

Hi avpaderno,
The reason that PHPStan fails in this scenario is that Gitlab Templates is designed to run all linting jobs at it's "current" Drupal core version, which was Drupal 10 at the time the templates were being developed. Your pipeline is specifying 9.5.11 to be seen as the "current" core, which as you say, does not include PHPStan. There are (at least) three ways to solve this

1. If you are not interested in the PHPStan output, then simply set variable SKIP_PHPSTAN: 1 and the job will not run
2. If you do want to run the job at Core 9.5 then you can probably load the requirements via a phptsan: before_script
3. If the project is compatible with Drupal 10, then you could set "current" core to Drupal 10 and "previous major" to Drupal 9. Then all linting would run with D10, but you could still keep test coverage at D9 by using OPT_IN_TEST_PREVIOUS_MAJOR: 1

In the case of the Seven theme → which I believe is the project you are tallking about, this does have compatibility with Drupal 10, so option (3) above might be your better choice. Or if this is not the project, please link to your pipeline / project where you found the problem.

I added the link to the failing job. (I forgot to do that when I created the issue.)

The real problem here is this

$ php $CI_PROJECT_DIR/vendor/bin/phpstan --version
Could not open input file: /builds/project/seven/vendor/bin/phpstan

phpstan comes from drupal/core-dev, and this was only included in versions 10+, not 9 or below.

The fix here should be to check for the phpstan binary directly, if not present, exit with a warning before going any further (not an error because we haven't actually checked the code). Let's make sure that the warning is visible via the $DIVIDER syntax that we've used in other places.

I don't think that we need to do if/else logic about Drupal versions, or try to bring phpstan in any other way. I would just check for the existence of the tool and bail out early if not present with an useful message.

OK that sounds reasonable. Then if a custom before_script loads it specifically, the job will run OK.

Another idea would be to add an exists: check in the phpstan job, so it would not even get added to the pipeline if there was no binary. Maybe that would confuse people, as it would not show why the job wasn't run. But it would be better in that there would be no amber warning, so the pipeline would be cleaner. The job should not end either green or red, so it would have to be amber, which indicates that the maintainer has to do something. I'd prefer just not to add the job at all. But happy to go with your preference if you convince me :-)

Scrap that idea! I don't think it would work as the exists: has to check the files right at the start, as the pipeline is being created. At that point the vendor/bin/phpstan folder would not exist anyway.

So we can't conditionally prevent the job from being added, it will run and we have to give a warning message if phpstan is not available.

Ready for initial feedback. The d9-basic job temporarily has DRUPAL_CORE: 9.5.11 and the failing job shows:

******************************************************************
The PHPSTAN binary was not found.
Expecting it in /builds/project/gitlab_templates_downstream/vendor/bin/phpstan
Set variable SKIP_PHPSTAN:1 to avoid running this job. 
******************************************************************

The d10 job (which does not have any core modification) runs phpstan ok as usual.

I'm not sure how we can make the job end amber if the pipeline has already set allow_failure:false. Maybe we need to experiment with the exit code?

I added a bit to the message, but the whole logic is perfect in my opinion.

I don't think we need to worry about the allow_failure setting. If it's false, this addition will make the pipeline fail, and rightfully so, because they want the phpstan job and this is not possible, so they need to do something about it.

RTBC after the suggestion is applied (feel free to change the language if needed) and the testing code is removed. NW for now.

Here's the latest downstream job showing the updated failure message. I used your suggestion, and all I changed was the quotes, and to start a new line which was beter than wrapping.

https://git.drupalcode.org/project/gitlab_templates_downstream/-/jobs/55...

I have removed the temporary lines, but decided to leave in _PHPSTAN_EXTRA: '--debug' as this will be useful for all testing downstream jobs.

Looks good, and totally fine to leave that debug flag for when we run the downstream pipelines too.

Merged. Thanks!