Extend PHPUnit variant jobs from .phpunit-base

I can’t remember the issue where we talked about this, but we left it like this on purpose because it is very likely that maintainers would want any customizations made to “phpunit” to be in the other variants too.

Think of groupings (like scheduler) or concurrent jobs (like api) or any other customization that you’d do to “phpunit”. If we change the design then those customizations would need to be done to the other variants too.

The changes proposed here would be easy, the workarounds would also be easy, but the level of disruption in contrib could be pretty high, which is why we didn’t change it in the end I think.

I’ll try to find the issue where we discussed it.

Found it: #3425373: Extend from base jobs to keep personalisations at job level →

I knew we had talked about it before! We both wanted it to be changed, but ultimately felt it would be safer to leave as is. But the instructions to fix a broken phpunit job should be very simple, they just make the customisations to .phpunit-base not phpunit if the change is wanted in every job. This works in Scheduler, where I add the parallel: values for test groups.

I think it is worth not closing this issue yet, but to trying to evaluate the pros and cons of disruption. Some of the benefits are big, for example, not having to do the work-around

phpunit (next major):
  extends: !reference [.phpunit-base]

when you don't want to affect every job.

Yeah, I'm happy to keep this open and even experiment with the possible changes and workarounds.

The question is still the same as the other issue really, whether to carry over customizations from "phpunit" to the other variants or not, as that's the way that a lot of people expect to behave.

We know that the same could easily be done with ".phpunit-base", but this would add a level of complexity and knowledge of the templates that maintainers might not have or need. And if they have the internal knowledge, then they should also be able to design easy workarounds.

From a code-design perspective, I'd love to do this (that's the reason why I opened the other issue indeed), but yeah, from a "nearly 2000 integrations and adding a disruptive change" point of view, I have my reservations.

Projects with the word phpunit in their .gitlab-ci.yml file: https://git.drupalcode.org/search?group_id=2&repository_ref=main&scope=b...

If we do this, we can consider it in a possible "2.x" scenario and that way we won't need to worry too much about existing integrations.