Test-infra: prow: remind me plugin

Created on 5 Jul 2018 · 9Comments · Source: kubernetes/test-infra

I have no clue how complex this would be or if it's even a good idea.. but wanted to toss it out there.

There are times where I when I want to be reminded to come back to an issue. Say someone says they are going to work on something, but I want a reminder to check back in, in two weeks.

I wonder how useful, vs how awful, something like a "/remind" command would be.

Something like:

I leave a command like "/remind 2 weeks"
Prow stores that in something stateful (BLEH, this probably makes this whole idea a non-starter)
Prow checks that stateful table on a cron or something.. and when something is due, it comments back out on the issue, pinging the author
Would need restrictions on who can use it and how long a time frame you can set to prevent abuse

ref something similar on reddit: https://www.reddit.com/r/RemindMeBot/comments/24duzp/remindmebot_info/

lifecyclrotten

Source

cblecker

Most helpful comment

cc: @BenTheElder @fejta
(please don't throw things at me)

cblecker on 5 Jul 2018

😄3

All 9 comments

cc: @BenTheElder @fejta
(please don't throw things at me)

cblecker on 5 Jul 2018

😄3

This seems slightly out of scope for Prow. Also time is hard, would this bot assume UTC? 🙃

More seriously:

the long-term statefulness is not something any prow components handle well currently (except public GCS uploading of job results). We have jobs on cron, but if we lose the CRDs backing these we can still recover from the checked-in config with their schedule.
who would we restrict it to? for how long? I don't think we could restrict it much and still have it be useful, maybe collaborators

This one I think is key:

If it's going to post to the thread, everyone will get a notification. It wouldn't be so much "remind me" as "remind everyone". GitHub doesn't have trees and anyone who touches the thread is default subscribed to notifications. I don't think we have a great way to privately message users right now either. GitHub doesn't have any features for this and we haven't (yet?) tried to build out one ourselves.

BenTheElder on 5 Jul 2018

hummm, can be some REAL kube cron job prow creates?

krzyzacy on 5 Jul 2018

Collaborators and 6 months seems reasonable to me. Your point about notifying everyone.. yeah, it could get spammy.

cblecker on 5 Jul 2018

This is not really a constructive comment but: in such cases, I just snooze the email related to the issue so that it reminds me about it. ¯\_(ツ)_/¯

nikhita on 6 Jul 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 4 Oct 2018

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot on 3 Nov 2018

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot on 3 Dec 2018

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.