Repo setup oddities

[RalfJung]

Something about the repo setup makes GitHub show this for each PR:

bors Expected — Waiting for status to be reported

Looks like the repo is set up to require a "bors" status, or so. This has the unfortunate side-effect that the PR will always be considered "waiting" for CI even after PR CI passed, because bors CI is still missing. So, the PR doesn't get the green checkmark that it should get once CI is good.

Isn't it sufficient to enable "Restrict who can push to matching branches", and then say that only the bors app can push, and be done with that? That should avoid these CI status annoyances.

Cc @japaric

[jethrogb]

This is normal

[RalfJung]

Uh... could you elaborate? It is unnecessary and has bad side-effects. How is that "normal"?

[jethrogb]

This is how bors-ng (https://bors.tech/) works. I have yet to find another way to set everything up that doesn't give administrators the right to push to master in any circumstance.

[RalfJung]

"whatever rust-lang/rust does" should be good enough for us, I think. And they do not have "Require status checks".

I am not sure what they do, but I'd enable "Restrict who can push to matching branches", set that to bors-only, and also enable "Include administrators" to enforce the restrictions for admins. (Well personally I think admins having an override is fine, but they do anyway -- they can change the branch protection settings.)

I see no good reason to enable "Require status checks to pass before merging".

[jethrogb]

Continuing the discussion in bors-ng/bors-ng#894 to keep everything in one place...