etcd-io
Use bot to remove stage/triaged tag if no activity for a while
What would you like to be added?
Use a bot to remove stage/triaged tag if no activity in a PR/issue for a while (2 month?)
We can probably use the k8 triage bot
Why is this needed?
It is easier to rely on the stage/triaged tag filter to triage issues and PRs, but we need to watch out for abandoned issue/PR.
/cc @ivanvc @ArkaSaha30
PR: https://github.com/etcd-io/etcd/pull/19716
Hi, @IAMRogerXi. Thanks for your pull request. I see that you're introducing a new GitHub action. Because we have access to K8s' infra, and because we're trying to minimize our GirHub actions workflows, may I ask if you explored using the k8s-triage-bot as suggested in the description (https://github.com/kubernetes/test-infra/blob/9c8103abd65925a9e075c01908d40c31d00c1bbf/config%2Fjobs%2Fkubernetes%2Fsig-k8s-infra%2Ftrusted%2Fsig-contribex-k8s-triage-robot.yaml)?
If it wasn't a good fit, can you explain why? Thanks, again! :)
thanks for the comment. i'm not familiar with the container gcr.io/k8s-staging-test-infra/commenter and Prow commands. that's why i use JS to fetch the details. but after some researching, i managed to use commenter to add comment in my own repository.
however, it is not that easy to setup a Prow command env to test the Prow commands like /remove-stage triaged in my own repository. may i know what will be a proper unit testing for this part? thanks.
however, it is not that easy to setup a Prow command env to test the Prow commands like /remove-stage triaged in my own repository. may i know what will be a proper unit testing for this part? thanks.
It is pretty hard to test it because of bot access limitations. We will have to depend on code review and see what happens ^_^. But we should still try to use prow for this issue.
thanks for the explanation. i will abandon #19716 and push a new one with prow command in comment.
i don't have time to push a PR last weekend. will try my best to do so this week...
Hi @ivanvc , @siyuanfoundation
By reading the above comments, I noticed that similar jobs are defined in the existing yaml.
Would it be okay to add the etcd-specific job there, or would it be better to create a new file like etcd-triage-bot.yaml under the same directory?
Just want to confirm the preferred approach before opening a PR.
Hi @lavishpal, thanks for your interest in working on this. But, @IAMRogerXi is assigned and said he'll get back at it next week. If he doesn't show progress next week, we'll re-assign the task. But as long as it's assigned to another one, let's try not to work on it. Thanks.
@IAMRogerXi: The label(s) /label stage/triaged cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, ci-short, ci-extended, ci-full. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?
In response to this:
/label stage/triaged
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
@IAMRogerXi: The label(s) /remove-label stage/triaged cannot be applied. These labels are supported: api-review, tide/merge-method-merge, tide/merge-method-rebase, tide/merge-method-squash, team/katacoda, refactor, ci-short, ci-extended, ci-full. Is this label configured under labels -> additional_labels or labels -> restricted_labels in plugin.yaml?
In response to this:
/remove-label stage/triaged
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
@IAMRogerXi: Those labels are not set on the issue: triage/accepted
In response to this:
/remove-triage accepted
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
looks like there is a limitation in Prow. it only supports the following labels.... https://github.com/kubernetes/test-infra/blob/master/label_sync/labels.md#why-these-labels
| triage/accepted | Indicates an issue or PR is ready to be actively worked on. | org members | label |
|---|---|---|---|
| triage/duplicate | Indicates an issue is a duplicate of other open issue.This was previously close/duplicate, duplicate, | humans | |
| triage/needs-information | Indicates an issue needs more information in order to work on it.This was previously close/needs-information, | humans | |
| triage/not-reproducible | Indicates an issue can not be reproduced as described.This was previously close/not-reproducible, | humans | |
| triage/unresolved | Indicates an issue that can not or will not be resolved.This was previously close/unresolved, invalid, wontfix, | humans |
to reuse the existing bot, supported tags such as triage/accepted must be applied from now on.
@ivanvc @siyuanfoundation
my solution is to:
- re-use the action with Prow.
- introduce a new tag 'triage/accepted' in etcd repo - so that Prow can manipulate the tag correctly.
- update the existed 'stage/triaged' to 'triage/accepted' to align the new context.
do you have any comment on it?
if this is not an acceptable approach, i think i need to go back to my initial implement, which uses JS in action to handle the tag.
@ivanvc @siyuanfoundation may i know whether any reviewer will help to review the PR? thanks.
I think your approach from 2 and 3 makes sense. I added this topic as an agenda item for our next community meeting (July 24th). I'll come back to this issue after we discuss it there (I'm looking for an agreement to update our labels).
Thanks for the work, @IAMRogerXi :)
Sorry, I forgot to provide an update after the community meeting. The consensus was to align with k/k's labels. We also discussed this during our etcd operator WG meeting cc. @jberkus.