Branch Protection

[grandixximo]

Continuation on the discussion on #3580 about "Branch Protection" and "Require branches to be up to date before merging"

[grandixximo]

@rene-dev why do we need "Require branches to be up to date before merging" ?
With this option we will have to run CI twice for practically all the merges, or am I missing something?

Edit:
ok I see you turned it off, nevermind then, still Branch Protection discussion can go on here

[BsAtHome]

The rip-and-test CI test is marked as "required". However, there are many more CI parts that are required. We do not want to add PRs that fail any CI test, except for the Debian Sid runs.

That said, there are still tests that fail once in a while due to 1) race conditions in LCNC or the test or 2) failing CI infrastructure. Making CI tests a hard requirement can make life hard in case 2. For case 1 we need to fix the problem, of course. However, that can be a very hard problem at times.

[grandixximo]

I lean toward leaving it unforced for flexibility. We rarely merge PRs that fail CI, but the option matters when CI itself is the thing that's wrong; as you say, infra flakes and race conditions happen, and a hard requirement means a red X from the infrastructure can block an otherwise good merge.
The lock adds friction in the common case to guard against a rare one. I'd rather spend the effort fixing the flaky tests than working around the gate.
Trust with an escape hatch has served this project well so far; I'd keep CI as a strong signal, not a hard wall.