Update PHP_MAX to 8.4

Downstream pipelines: https://git.drupalcode.org/issue/gitlab_templates-3496181/-/pipelines/37...

https://www.drupal.org/docs/getting-started/system-requirements/php-requ... →

10.4 and 11.1 are marked as PHP8.4 compatible. The MR looks good. RTBC and merging shortly.

Merged. Thanks!

When investigating 🐛 beStrictAboutOutputDuringTests=true or failOnRisky=true causing test failures due to PHP8.4 Implicit Nullable deprecation Active I realised that the variants using Max PHP do not have allow_failure: true. This had not been noticed before, probably becuase there had never been a php upgrade which caused test failures. But I think we should set this as the default in both the PHPUnit and Nighwatch max PHP jobs. Testing against the max php version is, by definition, trying to forward-test just like we do with Next Minor and Next Major variants, so this in consistent with that design.

MR312 ready for review and testing.

Here's a test using MR132
https://git.drupalcode.org/issue/scheduler-3445052/-/pipelines/384028 - the phpunit Max PHP job ends with amber warning

For comparison, here is the existing repo pipeline, using default-ref. The phpunit Max PHP ends red.
https://git.drupalcode.org/project/scheduler/-/pipelines/381261

No strong feelings, but fwiw, PHP_MAX is a stable and supported PHP version, unlike next major/minor which are still in development.

People are in the process of testing and switching to that, it's a bigger issue than incompatibility with a development version of Drupal core.

So I can see an argument either way. PHP_MAX is already opt-in, it doesn't fail by default. Modules likely did the opt-in before it was changed to 8.4, but the same can be said for any job, the current version also shifts every 6 months and in bigger/more complex projects, I'm seeing test fails with pretty much every minor version.

I'm in the same position here. I see arguments for either side.
Since we are allowing failure to non-default variants, I am going to merge this. Thanks.

Before we make any further commits, is is possible to change the commit message added here? It is a repeat of the original "Update CORE_PHP_MAX to 8.4" which does not say what we actually did. Can it be changed to "Allow max PHP variants to fail" or something like that. Or maybe you cannot do a git commit amend on the real branches?

That was my bad, I should have changed it before hitting the merge button. I don't know if we can do git commit amend. I can try it.

I'd need to force-push, so it's not an option. I can revert and redo the commit, but that'll make the commit history even more messy. I'll try to be more careful in the future if there are several commits within the same issue.

No problem, just thought I would ask. Maybe the changelog can have the alternative message.

Yup, I actually had that already staged locally

# GitLab Templates Changelog

## 1.6.14 - 2025-01-xx

#3496181 - Add `allow_failure: true` to max PHP variants.\
#3497842 - Bump core versions to 11.1.1/10.4.1.

## 1.6.13 - 2024-12-27

#3496181 - Update PHP_MAX variables to 8.4.\
#3439240 - Cspell: sanitize suggested words for dictionary.
...

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