-
Notifications
You must be signed in to change notification settings - Fork 897
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
Auto assign PR to author #16969
base: branch-24.12
Are you sure you want to change the base?
Auto assign PR to author #16969
Conversation
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'm requesting a review because I have a couple questions.
on: | ||
pull_request_target: | ||
types: | ||
- opened |
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.
Maybe on reopen too? Anything else?
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 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.
Maybe
edited
too? If a second person starts pushing to the PR then we can make them both share ownership.
From the documentation, edited
means
The title or body of a pull request was edited, or the base branch of a pull request was changed.
whereas synchronize
means
A pull request's head branch was updated. For example, the head branch was updated from the base branch or new commits were pushed to the head branch.
So we might want synchronize
over edited
.
The one caveat is that it might get messy with people merging upstream, but if there isn't an easy way to avoid that I think adding them is better than not.
Since the commit message is always something like Merge {latest branch} into {current branch}
, we might be able to not run the job when we get this message (I'm not sure how to do this though.)
@vyasr You were interested in increasing automation. What do you think of this proposal? |
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 think that this is a (small) positive change overall. I don't think it's crucial since PR ownership is something that we often handle implicitly and it's much more important for issues where it isn't always obvious who is working on it unless there is a linked PR, but I think this is lightweight enough to be worth adding. Apologies for the slow response.
on: | ||
pull_request_target: | ||
types: | ||
- opened |
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.
Description
I think most PRs remain unassigned, so this PR auto assigns the PR to the PR author. I think this will help keep our project boards up-to-date.
Checklist