-
Notifications
You must be signed in to change notification settings - Fork 212
Different stale settings for specific labels #65
Comments
Is this still relevant? If so, please comment with any updates or addition details. |
I believe this is still relevant to the probot stale project, at least no discussion has taken place to indicate otherwise 😄 |
Is this still relevant? If so, please comment with any updates or addition details. |
Yes this is still relevant and has been referenced in other issues |
Seems like a reasonable feature. The easiest way to implement it would probably be to copy how different settings can be specified for labels:
x:
daysUntilStale: 1
daysUntilClose: 1
y:
daysUntilStale: 14
daysUntilClose: 3 As an aside, I had thought about some drastic changes to stale configuration at one point that I think would also fit this use case…The TL;DR, is that it should allow specifying an unlimited number of configurations. It might look something like this: mark x stale issues:
if:
days: 1
label: x
is: issue
then:
label: stale
comment: Whatever you want to say when marking the issue
close x stale issues:
if:
days: 1
labels:
- x
- stale
is: issue
then:
close: true
mark y stale issues:
if:
days: 14
label: y
is: issue
then:
label: stale
comment: Is this still relevant? If so, please comment with any updates or addition details.
close y stale issues:
if:
days: 3
labels:
- y
- stale
only: issues
then:
close: true So if you wanted different configuration for each label, you'd just use the This is a drastic change, so I wouldn't wait for it to happen before exploring a solution, but wanted to throw it out there. |
The logic based configuration looks like a really good idea for future extensibility and could open the doors to a highly custom configuration. One could probably use the logic system to power all existing configurations during it's implementation but as you said that's a very drastic change to the system. The first proposal also seems like a good and simple approach to take, should be easy to lookup configuration for different issues. I guess a question it prompts though is what happens it two labels cause a rule conflict? I'm assuming it would be sensible to take the longest (thus most lenient) rule and apply it. |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? |
Over at https://github.com/campus-experts/training, we're looking to use stale to handle neglected issues and PR's, however we would really like to put different durations across different labels.
Example use case
We have one training module which takes a long time to work through. It's quite typical that a user submits a first draft and we then review it. Once it's reviewed it can sometimes take a while for a user to push their changes as they often take a while to complete, we're talking on a scale of 2-3 weeks. However other modules can be much quicker and fixes can often be carried out in a matter of minutes and we want the expected turn around to be much quicker.
It would be fantastic if we could enter an array of labels with some override values, falling back to the top level stale settings. IE:
label x - is stale after 1 day and closed after 1 more
label y - is stale after 14 days and closed after 3 more days
The text was updated successfully, but these errors were encountered: