-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: require "allow edits" to be checked #35002
Conversation
on: [pull_request_target] | ||
|
||
jobs: | ||
_: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why _
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The display on the PR will be Require "Allow Edits" / _
with this. If there's a different name "after the slash" you'd prefer, I'm happy to change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ohh hmm, looks like by providing the name
field the _
is overridden :-)
What display text would you like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the name
field is used I'm fine with it. I asked because I thought _
had some implicit hidden behavior maybe 😅
063cb9f
to
d6d01ff
Compare
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this option should be required for all PRs. I personally disable the option every time because I prefer being in control of what changes are made to my PRs, so that there are no surprises.
I am fine with the merge feature or whatever being opt-in for those that want to enable the "allow edits" option.
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. |
That was what I asked previously and you said yes, so now I'm confused.
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. |
PR-URL: nodejs#35002 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Rich Trott <[email protected]>
d6d01ff
to
07423b5
Compare
Landed in 07423b5 |
PR-URL: #35002 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Rich Trott <[email protected]>
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? |
PR-URL: #35002 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Rich Trott <[email protected]>
@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. |
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'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. |
This reverts commit 07423b5. Refs: nodejs#35002 (comment) PR-URL: nodejs#35094 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This reverts commit 07423b5. Refs: #35002 (comment) PR-URL: #35094 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Richard Lau <[email protected]>
PR-URL: nodejs#35002 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Rich Trott <[email protected]>
This reverts commit 07423b5. Refs: nodejs#35002 (comment) PR-URL: nodejs#35094 Reviewed-By: Mary Marchini <[email protected]> Reviewed-By: Richard Lau <[email protected]>
This github action will fail if "allow edits" is not checked - this allows all PRs to be landed purple.
Open to any feedback for tweaking error messages, and if there's concern with depending on
main
, i'm happy to use tags, or make an explicitnode
branch, so node's usage of the action can be more precisely targeted.See also, #35001