This will require all PRs to allow edits?

@mscdex yes, but that's the default, and in my experience vanishingly few people turn it off.

I don't have strong opinions, my PR #35001 already takes into account PRs with and without "allow edits" 🤷🏻‍♀️

@mscdex to be clear; this PR doesn't actually make it required on all PRs, but I'm told that NCU doesn't differentiate between required and optional PR status checks, which makes everything effectively required.

@mscdex to be clear; this PR doesn't actually make it required on all PRs

That was what I asked previously and you said yes, so now I'm confused.

but I'm told that NCU doesn't differentiate between required and optional PR status checks, which makes everything effectively required.

I'm assuming "NCU" is referring to node-core-utils here? If so, I don't quite follow.

All I care about is being able to create PRs with "allow edits" disabled. I'm not using node-core-utils or anything fancy like that, just plain old git commands to do everything. As long as that kind of workflow won't be affected, then I will be happy to withdraw my -1.

@mmarchini can you confirm?

My assumption is that as long as you’re landing your own PR, this requirement won’t affect you; it’s for when someone else needs to land the PR.

Nope, the bot has a different token (it doesn't pretend to be you), so it won't be able to force push to head branch (it won't be able to purple merge if "allow edit" is not checked)

Also for some context @ljharb, we don't have "required" checks (the GitHub setting) in this repository.

@mmarchini ok, but if someone lands the PR without using the bot, will it still work?

@mscdex it's also worth noting that you could, at the final moment before merging, check the box and rerun the one workflow, and then land it even with ncu?

Yes, ncu let's you bypass the check if necessary. And I might be misinterpreting, but I think @mscdex doesn't use node-core-utils to land PRs.

So then the changes in this PR do not affect the UI when I click "New pull request" on the website, correct?

Correct; that’s not something a repo can control beyond the pull request template - this PR is just an action for opened PRs.

Landed in 07423b5

This currently shows up as a red ❌ on pull requests when allow-edits isn’t possible, and keeps the CQ from working as it seems, e.g. #35067 – maybe this should be reverted?

@addaleax when is "allow edits" not possible? in that case, the user appears to have not checked the box.

@ljharb It’s not possible when it comes from an organization fork rather than the author’s personal one.

More importantly, the author should absolutely not have to check that box. I read the conversation with @mscdex above as implying that everything would still work when this box is not checked, except that the PR would not get a purple merge badge. I’m sorry for misunderstanding, but I think this is reason enough to revert this for me.

It's certainly possible, but due to a github bug, checking the box won't allow force pushing to the branch (but it will cause the PR check to pass).

Everything will indeed still work when it's an X, just like it did on the PR you referenced.

Everything will indeed still work when it's an X, just like it did on the PR you referenced

Except the CQ will fail, as Anna mentioned (also worth noting that this PR landed before the purple CQ merge). If this is getting in the way for folks I'm fine reverting.

If it's stopping the CQ from landing things it was able to land before let's revert.

In terms of the CQ purple merging I think the CQ should cope with both PR's that allow edits and PR's that do not as we do not currently require PR's to allow edits (to me that feels unnecessarily restrictive).

Ah, that's something I missed, in that case a revert does make sense.

It seems like it would be a better approach to use Github's branch protections to mark specific checks as "required", and then fix CQ and relevant tools so they only fail when required checks fail. That way, this check can land and be optional, and it wouldn't interfere?

It seems like it would be a better approach to use Github's branch protections to mark specific checks as "required", and then fix CQ and relevant tools so they only fail when required checks fail

It's a lot more work than it seems. We have doc-only change rules where tests don't need to run, we have Jenkins status which are posted to GH via Status API instead of Checks API (and have erratic behavior sometime), and we have enough flaky tests that an override is frequently necessary.

Either way, this needs to be first a change to our collaborators guide, and such a change will need to follow the overall consensus process as well as have someone willing to implement and fix all the pieces.