Please don't. It's green since a few months. Keeping this as required prevent us from merging PRs that break that.

it is not green since a month. It was green during one month, then red since yesterday due to changes done in PHP, which turned all PRs to a red CI while none of them was responsible.

I didn't notice it was red for so long. But that doesn't change my point: I'd like to continue giving this strategy a try. We run all our deps as dev-master for the same reason: it increases the pressure to take care of our dependencies, and this is good pressure. Eg when doctrine deps make our builds green, this forces us to have a conversation with or send PRs to doctrine, and that's a very sane thing to me. Doing the same with PHP 8.2 provides the same benefits to me.

I think everybody agrees with what you're saying Nicolas, but at the same time, contributors are not aware of this and they have all their PRs red without being able to fix them.

Only occasionally, and that's no different from doctrine failing temporarily. At least until today included to me.
Having 8.2 green was a milestone on its own and made us fix issues earlier.
Making it fail silently will make us drift from that milestone. Unless we have a strong reason to do it (eg 8.2 being red with unreasonable time-to-green.), I'd like to keep open eyes on the topic...

Sorry I double down on this one: this hides failures that have to be fixed anyway.

Clear 👎 on this one today.

I'm going to send a PR to fix the build instead.

I do think it's useful feedback to see the actual failures (instead of a wrong green check every time).

However, I do believe this impacts the DX of contributors. I created this PR after seeing this error in #46157 and I had to investigate whether it was due to my changes. I understand Symfony's build system, so it didn't take me long. But, a normal (or new) contributor is much more worried about this red cross in their PR (I've had to tell people often on Slack to ignore build failures that are unrelated to their changes).

If we reject this PR, can we consider using the "required check" setting of GitHub Actions, to better indicate to users not to worry about a failing PHP 8.2 build? (by not marking it required) It's unfortunate that GitHub doesn't come with a better "allow failures" feature currently, but I think we can improve the contributing DX here :)

Failures on appveyor are much more annoying (yet needed) :)

can we consider using the "required check" setting of GitHub Actions, to better indicate to users not to worry about a failing PHP 8.2 build? (by not marking it required)

worth a try yes!

using required checks would prevent us from pushing to github without these checks passing, which would affect us in 2 ways:

• it would prevent us merging when we decided that the failure was a volatile test that failed and we're OK with this
• it would prevent us from squashing or retargetting locally with the Symfony gh tool, as the result of that local operation would not have the checks on them.

Closing as explained. 8.2 is back to green since #46170.
We can reconsider of course when we'll have a real issue with keeping 8.2 green.

For reference, since php/php-src@f869a54 (merged yesterday) builds are red again: https://github.com/symfony/symfony/runs/6240314891

Perfect, that's exactly what a ci is for :)
Time to rebase the fix I submitted a few days ago to make it green again: #46167