-
Notifications
You must be signed in to change notification settings - Fork 14k
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
Add PR triage workflow #17881
Add PR triage workflow #17881
Conversation
I totally love this idea!
Could we just add label "needs-attention" if the PRs from non-committer have no reviewer after 7 days? That may be more simple and it can remind committers to check those languished PRs as well |
I like this, thanks @mumrah. |
Unfortunately, So, for now it would be a manual process to remove the One improvement we can make is to use https://github.com/actions/stale?tab=readme-ov-file#exempt-all-pr-assignees to prevent Edit: Since we already require adding 2nd Edit: IF we ever use GitHub Projects (a big "IF" 😄), then labels like this can be automatically removed when transitioning a PR from one state to another which is a drag-and-drop action in the UI |
.github/workflows/pr-update.yml
Outdated
FOUND_CONTRIBUTOR=$(gh api \ | ||
-H "Accept: application/vnd.github+json" \ | ||
-H "X-GitHub-Api-Version: 2022-11-28" \ | ||
/repos/apache/kafka/contributors --jq '.[] | select(.login == "'"$PR_USER"'") | .login') |
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.
does /repos/apache/kafka/contributors
return "committers"? it seems to return top contributors
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.
You're right 😖
I think we can query the "orgs" API to check if the author is a member of apache
, but that won't tell us if they are a Kafka committer (could be any Apache committer). That would at least prevent committers from having the triage
label added.
Another approach is to create a list of committers by GH username. This is related to another improvement I've been contemplating. I'd like to separate the "reviewers" (anyone in community) from the "approvers" (must be committer) in our commit messages. A config file of GH usernames + email + preferred name is how I would approach that one. We could use this config file as the input for this task which would solve the problem.
WDYT?
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.
Another approach is to create a list of committers by GH username.
Maybe we can leverage committers.html?
This is related to another improvement I've been contemplating. I'd like to separate the "reviewers" (anyone in community) from the "approvers" (must be committer) in our commit messages.
I love this idea!
@chia7712 I created a mapping file from the ASF roster and manually matched it up with GitHub user names. https://github.com/mumrah/kafka/blob/asf-committers/README.md I would like to add this WDYT? |
My main concern is how to sync the file with committers.html 🤔 |
I'm not sure it's that much of a problem TBH. There's already a lot of manual steps involved in becoming a committer. I don't think one more PR is too much of a burden :). Also, the committers.html is more about personal info (photo, links to social, etc). The dataset I'm proposing is more technical to help power GH automations. If the two are out of sync, I can't think of any real negative outcomes. For the workflow in this PR, the worst outcome is that a committer gets a If we wanted to combine the two data sets, I think that would be do-able as well. This would involve moving the photos to the I'll start a discussion thread about adding the asf-committers branch, since I can't really a PR for it without first creating the orphaned branch. |
In https://kafka.apache.org/committers, we have a
This is what we currently use in https://github.com/apache/kafka/blob/trunk/committer-tools/refresh_collaborators.py |
@mimaison good to know! I had no idea we had the GH usernames in a hidden div. Any idea why we don't create a link to the committer's GitHub page? Privacy concerns? Thanks to @assignUser for the tip on "author_association" 👍 |
We can see this in action on my fork. PR opened by me
PR opened by collaborator
|
As good practice I'd recommend minimising the token |
# See the License for the specific language governing permissions and | ||
# limitations under the License. | ||
|
||
name: Pull Request Reviewed |
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.
We're starting to have quite a few actions. I think it would be good to add the description
field to all of them to clearly state their role, how they work, and the potential relationships between each others.
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 there is a description field for the workflow files. I've been adding comments here and there to help people navigate the workflow files. I think name
is as good as we get unfortunately.
Here's the docs: https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#about-yaml-syntax-for-workflows
And a similar question on SO: https://stackoverflow.com/questions/70941956/description-for-a-workflow-in-github-actions
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.
My bad I was looking at https://docs.github.com/en/actions/sharing-automations/creating-actions/metadata-syntax-for-github-actions#description which is not available for workflows.
So let's use comments to describe the workflows. Maybe it's only me (I'm not super familiar with GitHub Actions) but looking at the files (without reading the PR), it's not immediately obvious what each one does.
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 just added some docs to the README in the .github/workflows directory. PTAL
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.
Thanks that's very helpful!
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.
LGTM
Well, something isn't quite right. I opened a test PR and it was labeled as triage. Looking into it. |
Ok, it is working but there is a little quirk. Filed #18128 |
Another quirk: this is causing workflows to fail after reviewing PRs: https://github.com/apache/kafka/actions/runs/12266421343 It doesn't block anything, it just seems to generate nuisance emails. I submitted this review: #16754 (review) |
name: Pull Request Reviewed | ||
|
||
on: | ||
pull_request_review: |
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.
This event brings a interesting race condition:
-
Approve the Pull Request (PR):
- This action triggers the "Pull Request Reviewed" workflow.
- Example Run
-
Add ci-approve:
- This action attempts to locate the "pending" run_id.
- it mistakenly retrieves the run_id of the "Pull Request Reviewed" workflow, resulting in an error.
Error Example
Perhaps the issue is invalid, as pull requests should not be approved before the CI process completes. 😄
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.
Filed #18200 to (hopefully) fix this
Replaces #17298.
This patch adds a simple label based workflow for PRs. PRs opened by non-committers will have a
triage
label automatically added. This allows committers to see which PRs need to be triaged. After 7 days, aneeds-attention
label will be added. This serves as a reminder to committers and allows them to see which PRs have languished.For now, the
triage
label will need to be manually removed by a committer. In the future, we could try to automate this by removing the label after a PR has been reviewed, assigned, or commented on.