-
Notifications
You must be signed in to change notification settings - Fork 119
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
bot incorrectly adding 'dont-land-on-v7.x' #116
Comments
Got any example PRs by any chance? I could query the logs if it's a quite recent PR. Noticed you removed it from nodejs/node#6601, but that seems correct cause those changes didn't land cleanly on the v7.x-staging branch when a tried on my machine a week or two ago. |
For example: nodejs/node#10980 or any of the recently merged test PRs (e.g. nodejs/node#10923) which should have no problem. |
tbqh I think we should consider dropping that auto label. incorrectly
labeling don't land is potentially a big problem.
…On Tue, Jan 24, 2017, 2:24 PM Brian White ***@***.***> wrote:
For example: nodejs/node#10980 <nodejs/node#10980>
or any of the recently merged test PRs (e.g. nodejs/node#10923
<nodejs/node#10923>) which should have no problem.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#116 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAecV9ZF_bqvkI0sMdG6r4m9DYRCznEiks5rVnoEgaJpZM4LsmbV>
.
|
/cc @Fishrock123 |
Another example is this one: nodejs/node#10927 This one does actually have conflicts, but not any that were not automatically resolvable (no conflicting hunks). I'm thinking the bot maybe isn't set up correctly to do these safe automatic conflict resolutions? |
Logs related to ^ (10927):
|
Logs related to 10980 looks weird:
Totally understandable. It's trivial to disable the actual labelling, tho still perform the backport attempts for debugging what causes these issues.. I'd let @Fishrock123 decide when/what to do. @mscdex would you say any backporting attempt labels are buggy, or mainly dont-land-on-v7.x? |
@phillipj Right, but there are no conflicting hunks, so an automatic resolution should be possible. For example, for that particular PR I merged with |
@phillipj I don't know about the other labels, but definitely |
@mscdex ahh good catch, looking at ./scripts/attempt-backport.js#L217 it seems we're not passing the |
I agree with @MylesBorins about #116 (comment) We should distinguish the auto-labels and the human labels (assuming the auto labels can actually be fixed). The auto-label should be something like An opinion on |
It gets re-added incorrectly to nodejs/node#10980 on every rebase, so if you are looking for a repro, its easy. |
I've always been a proponent of having separate labels for intention vs. technically landable without human intervention. |
Interesting discussion, personally not too opinionated as long as the devs using these labels to filter/exclude commits to land on staging branches is happy. Fixing auto labels is needed anyway. I opened #117 enabling 3-way merge which will hopefully increase the number of PRs landing cleanly, and thereby not adding invalid auto labels. |
AFAIK those that update the staging branches every so often already check if commits don't land cleanly, so it seems like they don't rely on the labels anyway. I believe the labels were more there for the PR author's benefit? |
The tools to update the staging branch need a label to use when a PR is known to be irrelevant for, so they can skip it, that label is The bot's labelling is probably useful for the author's benefit, but unfortunately, the bot is currently applying the |
+1, the Can we stop the bot applying the cc/ @Fishrock123 as I don't really know anything about the Github bot 😅 I'd also note that the 100 labels issue has now been fixed, so if we want to add bot labels to help with releases that should be straightforward (we should document them somewhere though). |
There's been some concerns about auto labelling `dont-land-on-*` labels lately, especially since the bot is often wrongly adding these labels ATM. Therefore temporarily disabling that functionality to avoid further damage. Refs nodejs#116
There's been some concerns about auto labelling `dont-land-on-*` labels lately, especially since the bot is often wrongly adding these labels ATM. Therefore temporarily disabling that functionality to avoid further damage. Refs #116
The auto labelling of |
Closing this since |
The bot continually adds 'dont-land-on-v7.x' even though the PR (should) lands cleanly. This has been going on for awhile now and I've had to manually remove the label in those cases.
The text was updated successfully, but these errors were encountered: