Run on PHP 8.4 when OPT_IN_TEST_MAX_PHP=1

I have set CORE_PHP_NEXT to 8.4 in this MR, but this variable is not actually used yet. The Max PHP jobs use variable CORE_PHP_MAX which I think has to stay at 8.3 until Core officially supports 8.4
See https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →

But with the above change, you may be able to use

composer (max PHP version):
  variables:
    PHP_VERSION: $CORE_PHP_NEXT

I have not tested this yet, and there may be other requirements like changes to the image, etc. But this is a start.

Quick test of MR276 here, and as expected it failed with
Failed to pull image "drupalci/php-8.4-apache:production"
But we have the starting point now.

Added suggestion as image https://hub.docker.com/r/drupalci/php-8.4-ubuntu-apache/tags

We need to change two variables, not one. I left feedback in the MR.

updated both variables and added _TARGET_PHP_IMAGE_VARIANT but it think it need more work as CORE_PHP_NEXT variable is unused by code

I think we need to be sure of the goal of this issue before we do any more changes/testing. The two questions I have are:

1. Does Drupal 11 officially support PHP8.4 yet? Maybe this page → has not been updated, or is PHP8.3 still the highest version?
2. Is the aim in this issue (a) to make the default 'max php' composer job use PHP 8.4 automatically for all contrib, or (b) still keep 8.3 as the default for now, but provide the variable(s) so that a maintainer can customise their max php job to use 8.4?

If PHP8.3 is still the highest supported release then that is the version that should remain in CORE_PHP_MAX, and we provide CORE_PHP_NEXT: 8.4 for maintainers to use, as suggested in #3 and #5. It will also need the image tag value too, of course.

Arguably, currently with CORE_PHP_MAX no higher than CORE_PHP_MIN we should not waste resources and should skip the 'max php' jobs (like we have done now that there is no 'next major'). That's a separate issue, I know, but it has a bearing on what we consider to be the purpose of the 'max php' job. Currently it is identical to the 'current' jobs.

Good points. Let’s do two things:
- do not run php max if the php max value is the same as the php min value, as it is right now. This will save resources
- let’s try to do the phpx max 8.4 to see what’s involved and how to document it. We can undo or comment out the actual change until core officially supports it.

Sounds reasonable?

Core is not ready for 8.4, it will bloat logs with deprecations

From #10

do not run php max if the php max value is the same as the php min value,

I suggest a subtle change, and we make the rule "do not run it if $PHP_VERSION is same as $CORE_PHP_MIN". This allows the maintainer to override the php version in their customised max job, and it would run (just like in the testing MR above). If our rule was "do not run if php max = php min" then no overrride would ever get the job to run.

From #11

Core is not ready for 8.4

Thanks. In that case I suggest we should leave $CORE_PHP_MAX at 8.3, which, with the new rule above will mean the "max PHP" variant will not run by default. But we have $CORE_PHP_NEXT: 8.4 to allow maintainers to use this to override if they want.

The composer max job fails with
phpspec/prophecy[v1.18.0, ..., 1.x-dev] require php ^7.2 || 8.0.* || 8.1.* || 8.2.* || 8.3.* -> your php version (8.4.0RC3) does not satisfy that requirement.
Here is the full constraint failure log
Is there a way round this to allow us to continue on this issue?

Prophecy and few more needs patches https://github.com/phpspec/prophecy/issues/624

Lost of vendor patches required but it also need to fix composer constraints

I have opened 📌 Do not run the Max PHP jobs when the PHP version is the same as 'current' Active so that this issue can remain focussed on PHP8.4

Although from the comments in #13-15 it looks like we can't do much here yet.

The fix for 🐛 SQLite version too low for Drupal 11 Active is to actually make the "apache-ubuntu" image the default. That would affect this issue.
Adding here to bring awareness.

The fixes in that other issue seem to work, which might simplify the MR here.

Yeah, as far a core does not fully support 8.4 we shouldn't do too much about it for contrib. We'd be preparing for the changes here and updating some variables, but we would not push the 8.4 until it makes sense.

The above issue was merged and even though there is no conflict after rebasing, some of the changes in the MR for this issue are no longer needed.

I removed the two overrides that are no longer necessary
https://git.drupalcode.org/project/gitlab_templates/-/merge_requests/276...

Retested this MR and it still fails of course due to Core not being compatible with PHP8.4 yet, but it did load the correct image which shows that removing those overrides was correct.
https://git.drupalcode.org/project/scheduler/-/pipelines/326640

I think we can postpone this issue, unless someone else wants to try using those vendor patches to make it work?

Actually, this first change does not need to be postponed. The variable $CORE_PHP_NEXT is not used anywhere in the templates, and it is correct that this should be set to 8.4 not 8.3. Then it can be used in custom overrides such as I posted in #3. Arguably it should have been 8.4 all the time.

In due course, when Core becomes compatible with PHP 8.4, we will create a second MR here to change $CORE_PHP_MAX from 8.3 to 8.4, and $CORE_PHP_NEXT from 8.4 to 8.5.

Ready for review!

Agree, we can merge this already.

When core is 8.4 compatible, we can create a new issue for the switch, but this change will allow using the variable instead of hardcoding the version.

Merged. Thanks.

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