SQLite version too low for Drupal 11

Maybe something we can fix probably following our own advice here https://project.pages.drupalcode.org/gitlab_templates/info/common/#test-...

@drunken-monkey, can you try setting _TARGET_PHP_IMAGE_VARIANT to "ubuntu-apache" in your ".gitlab-ci.yml" file? As you are only running one variant, that variable can be set in the top level variables, like the other ones you already have.

Note that only PHP 8.3 and 8.4 has the "ubuntu-" image available as seen here: https://git.drupalcode.org/project/drupalci_environments/-/tree/dev/php?...

My thinking is to change the default value of _TARGET_PHP_IMAGE_VARIANT to "ubuntu-apache" in the templates, but that probably means that we'll need to revert to just "apache" for the previous major variant.

Dowstream pipelines: https://git.drupalcode.org/project/gitlab_templates/-/pipelines/316857

@drunken-monkey, can you try setting _TARGET_PHP_IMAGE_VARIANT to "ubuntu-apache" in your ".gitlab-ci.yml" file? As you are only running one variant, that variable can be set in the top level variables, like the other ones you already have.

I added it directly to the schedule, ran it again and it worked fine. Thanks!
(I don’t think it would make sense for me to add it to the .gitlab-ci.yml file since I normally don’t run tests using SQLite.)

Thanks for confirming. Yeah, you wouldn't need to change it anywhere really. We might just implement the fix upstream. We have a related issue about PHP 8.4 and the changes here might help in that other one too.

Tested on Scheduler. I also have a manual Drupal 9 (and Drupal 8!) composer and phpunit job. These both needed the extra _TARGET_PHP_IMAGE_VARIANT: "apache" of course, but all runs OK.
https://git.drupalcode.org/project/scheduler/-/pipelines/325104

Looks RTBC to me.

Thanks for the additional review and test. Merged!

Does this also require a one-liner in a doc page, saying that the new default is "ubuntu-apache" so if you have custom jobs using Drupal Core prior to D11 you may need to set _TARGET_PHP_IMAGE_VARIANT: "apache".

This is kind of a Change Record, but we don't have those for Gitlab Templates yet. Maybe we should? instead of filling the doc pages with these types of things.

Good point. We don't need that one-liner, but we do need to adapt this part: https://project.pages.drupalcode.org/gitlab_templates/info/common/#test-...

We can mention that the default is now "ubuntu-apache" and that older versions can just use "apache".
Are you happy adding this change to an MR? Otherwise I can do it if needed.

I added a change to the dpocumentaion MR255
https://git.drupalcode.org/issue/gitlab_templates-3473000/-/commit/e4e0d...
Can you check the wording please.

I added a really small suggestion. If you're happy with it just apply it and we can merge MR255.

D7 integration cannot have that default.
https://git.drupalcode.org/project/api/-/jobs/3218566

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

A monthly test job of mine fired off last night https://git.drupalcode.org/project/vault/-/jobs/3412515 pointing out this did break BC on the templates for existing configured jobs.

Reminder that the rule for BC was basically if a maintainer needed to make changes to their .gitlab-ci.yml in response to a change in gitlab_templates it needed to be a major branch release.

It was known when the Apache image was added it would be a feature change per module to enable it if they needed SQLite support for D11, either through the job menu on the GUI or in their GitLabCi in order to avoid breaking the rest of the contrib ecosystem we could not set it as the default for the baseline job until we jumped to a new major. We were only able to set it for next major because that was a controlled job that api explicitly defined it as managed and only supporting next major environments.

Longer term pressure was going to be needed with the DrupalCi Environments project to find a solution (such as backporting the Ubuntu image to all the PHP images, or adding a selectable SQLite into the image so that we only need one) or for Gitlab_templates to change the PHP image to a different vendor.

Created ✨ Release ubuntu images for PHP 8.1 and 8.2 Active

As per the discussion on #33 in #3486021-33: Unable to run "composer (previous major)" from pipeline UI; no image → I have drafted a CR https://www.drupal.org/node/3488684 →

The change record looks great!

Should we link to it in the code or changelog somewhere or just leave them as is, so people can visit them if needed? I don't know what's the policy on core or other projects for this.

jonathan1055 → changed the visibility of the branch 1.0.x to hidden.

For deprecations or other things that cause an exception we'd definitely link to the CR in the message. But we don't have any specific place where we could detect this problem, because it is specifically when the job has been customiszed for DRUPAL_CORE but not with the required overrride for PHP_IMAGE_VARIANT.

Linking to it in the Change Log would be good, as that is where people may go to see what has happened. It should be associated with the 1.6.5 release https://git.drupalcode.org/project/gitlab_templates/-/blob/main/CHANGELO... and I have attached a patch as the MRs have been closed.

With ✨ Release ubuntu images for PHP 8.1 and 8.2 Active completed so quickly no one will be getting the error anyway!

I added the above patch. Thanks!

I have just set the Change Record to 'published'