DB requirements for next major were changed

Suggested approach ready for review.

Pipeline: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/172486
MR: https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/203

This is with nightwatch jobs, but the error (and the fix) is exactly the same as with PHPUnit jobs.

- ❌ Before: https://git.drupalcode.org/project/decoupled_pages/-/jobs/1592137
- ✅ After: https://git.drupalcode.org/project/decoupled_pages/-/jobs/1592320

I ran into this today and was shocked was not already the case 😅 📌 [11.x] [policy] Require MySQL 8.0 (increased from 5.7) or MariaDB 10.5 (increased from 10.3) for Drupal 11 Active landed 3 months ago! We must've overlooked this 😬

Thanks for that, good catch! I applied your suggestions and reverted the change in the variables file.

I feel it is worth asking:
Do we want to keep putting these sort of changes in?

If you run your tests with a version of SQL that is no longer going to be supported should we be blindly hiding that or should we be telling you it’s time to change the version of SQL you use for testing?

Back on DrupalCi you would set your core version then choose your php+sql version. Leave the job long enough and eventually it just wouldn’t work. There was nothing stopping you from trying to run with an invalid SQL version.

As a maintainer of many contrib projects, I very much value that all those versions are now managed as a recommended default. I always found it annoying that you had to select the right combination from a very long list of versions and the majority in there weren't even supported anymore.

Possibly related / unrelated. Lines are blurry
Had success with the following configuration, as this issue's changes would suggest.

phpunit (next major):
  variables:
    _PHPUNIT_CONCURRENT: 1
    _TARGET_DB_VERSION: $CORE_MYSQL_MAX
    SYMFONY_DEPRECATIONS_HELPER: "disabled"

Noting, I needed to use SYMFONY_DEPRECATIONS_HELPER as disabled with PHPUnit 10. The weak setting was still spilling out hundreds of deprecations from functionality outside my control :)

The tests do pass locally with Drupal 11 and PHPUnit 9, without "disabed"

Config used:
https://git.drupalcode.org/project/graphql_compose/-/blob/0fffe9decbb215...

Job result:
https://git.drupalcode.org/project/graphql_compose/-/jobs/1595359

Re #8 - we try to at least set sensible defaults for current and for previous and future variants when possible. Anybody can fully override these, but the idea of having those variables was to also make it easier to update. Having said that, it's also true that module maintainers won't need to wait for us to fix things as they can easily override these values.

Re #10 - thanks for confirming! That's pretty much what the MR does for _TARGET_DB_VERSION. It's failing (as opposed to #4 where it was almost identical), so I'm investigating why, but this confirms that this is the right approach for this.

If feels like my last 10 commits were not needed, yet the downstream decoupled_pages:nightwatch (next major) keeps on failing.
It did work (see #4) and the changes since then have been minimal. I'll keep trying or maybe test with another project.

Ok, it seems like the rules:if:variables calculates the variable after the services are created, so we can't do it that way. But I found a better way just overriding the default MySQL version, which won't interfere if other people are using other database types.

Note that this issue and #3444792: Prepare for PHPUnit 10 → are both affecting the "next major" variants, so they'll be committed one after the other.

Based on this https://git.drupalcode.org/project/decoupled_pages/-/jobs/1600211, where it now works, I am marking this RTBC and will deploy shortly as this is blocking "next major" testing.

I haven't tested however I'll ask to make sure it wasn't missed.

Do we need to make any changes for SQLITE?

D11 now requires SQLITE 3.45 which I believe now requires the drupalci/sqlite-3 php (Unless I missed a change the other PHP images have 3.26)

We have not tested that part yet. In fact, the whole "sqlite" database type might be as it was from the early days.

Core uses https://git.drupalcode.org/project/drupal/-/blob/11.x/.gitlab-ci.yml?ref...

    _TARGET_PHP: "8.3-ubuntu"
    _TARGET_DB: "sqlite-3"

I will open a follow-up issue for this, to see if it's needed or not.

Follow up #3447792: See if we need to raise sqlite version for Drupal 11 →

Automatically closed - issue fixed for 2 weeks with no activity.