-
-
Notifications
You must be signed in to change notification settings - Fork 665
Fix in label synchronization bot according to issue #40758 #40839
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
base: develop
Are you sure you want to change the base?
Conversation
TestcaseAs a first testcase I use #39881, since this has two merge commits and ![]() Since one of the merge commits ( ![]() Using the new
The assertion is confirmed in the last line: |
Documentation preview for this PR (built with commit 111257b; changes) is ready! 🎉 |
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.
A question and a suggestion.
Also, how can we test this before I approve it?
.github/sync_labels.py
Outdated
if Status.needs_work.value in self.get_labels(): | ||
for com in date_commits: | ||
message = com['messageHeadline'] | ||
if message.startswith('Merge') and message.find('develop') > 0: |
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 message.startswith('Merge') and message.find('develop') > 0: | |
if message.startswith("Merge branch 'develop' into "): |
Would this work? Since it's more specific it's less likely to have a false positive.
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.
Never mind, I see you already mentioned this. You can ignore this suggestion if you think people changing the merge commit message could be an issue.
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.
There are also default messages that wouldn't match, for example in #40448: Merge remote-tracking branch 'upstream/develop' into remove-incremental
|
||
# ignore merge commits with the develop branch for commit_date if needs_work is set | ||
date_commits = list(self._commits) | ||
if Status.needs_work.value in self.get_labels(): |
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.
Is there a reason not to include the needs info
tag as well here?
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.
No! I will include it in the next commit.
This is a bit complicated. I've created a dummy PR (soehms#16) in my fork relative to the branch of this PR. I've declared the latter as the default branch so that GH-Action uses the changes in You should request changes on this PR. Afterwards I will merge the change concerning |
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.
Or is the PR you wanted me to request changes on?
I think that the behaviour being changed here should be agnostic to if changes were requested through the "review changes" interface or someone manually setting the "needs work" label.
We cannot test the new changes with this PR because GH-Actions inherits the code from the base branch of the PR, which is
That's right! This is the case when all of the bot's triggers are activated, meaning synchronization is bidirectional, meaning a change in the GH states translates into a change in the labels and vice versa. Currently, the direction from states to labels isn't even fully activated (changes in the review state are missing). For the return path, the activation of label changes is missing. You can see the current activation status in the header of #35927: ![]() If all triggers are enabled, your scenario works like this:
|
Co-authored-by: Vincent Macri <[email protected]>
Sorry, time is over for the moment. I'll do the |
I'm wondering (loud) if it makes sense to never change needs work to needs review. Take for example this PR: Vincent had a few remarks, some but not all of them were addressed in a new commit - and the bot put it now onto needs review, although it is still in needs work. This would also align it a bit better with the github interface: Vincent's review still shows as "requested changes" although there was a commit afterwards. But I'm probably missing something essential here, in that case, sorry for the noise. Btw, what's blocking the activation of
This would be quite convenient to have, and looks very similar to the already active "marking a draft PR as ready for review" |
I think this came up on sage-devel. The problem is that changing labels requires certain GitHub permissions that not all contributors (particularly new contributors) have. So if a reviewer requests changes, the changes are made, and the reviewer doesn't look at the changes then the PR will be stuck marked as "needs work" and will probably get ignored. If that happened to one of my PRs I could change the label. If it happens to a new contributor they wouldn't have any way of bringing attention to their PR (besides tagging people, and they probably wouldn't know who to tag and might not be comfortable tagging random people they've never interacted with). I think the main issue with the bot changing the labels to needs review when it doesn't need a review is that it makes it harder to find PRs that actually need a review. This PR should cut down on that noise a lot, even if there may still be some situations where the bot changes the label too early. |
This PR fixes #40758.
This is achieved by ignoring merge commits when the latest commit date is determined in case a
s: needs_work
label exists. Sinces: needs_work
persists if there is a more recent review requesting changes this should solve the problem.This remains unchanged.
In both cases, the predefined message begins with
Merge
and contains the worddevelop
. I just check that this is valid. However, note that the user (at least in the in the command line) has the option of changing the messages. Therefore, we generally cannot detect merge commits exactly.This PR also implements a new method
test_method
just for test purposes. This allows to run arbitrary methods of the class from the command line.📝 Checklist
⌛ Dependencies