8000 Add stale comment on issues manually labled as stale · Issue #188 · actions/stale · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add stale comment on issues manually labled as stale #188

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

Closed
TheOneRing opened this issue Oct 6, 2020 · 24 comments · Fixed by #352
Closed

Add stale comment on issues manually labled as stale #188

TheOneRing opened this issue Oct 6, 2020 · 24 comments · Fixed by #352
Labels
enhancement New feature or request keep

Comments

@TheOneRing
Copy link

This would increase the usability in setups where automatic marking as stale is not possible

@github-actions
Copy link
Contributor
github-actions bot commented Nov 6, 2020

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the Stale label Nov 6, 2020
@TheOneRing
Copy link
Author

unstale

@github-actions github-actions bot removed the Stale label Nov 7, 2020
@github-actions
Copy link
Contributor
github-actions bot commented Dec 7, 2020

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the Stale label Dec 7, 2020
@TheOneRing
Copy link
Author

Unstale

@github-actions github-actions bot removed the Stale label Dec 8, 2020
@github-actions
Copy link
Contributor
github-actions bot commented Jan 7, 2021

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

@github-actions github-actions bot added the Stale label Jan 7, 2021
@hasezoey
Copy link
hasezoey commented Jan 7, 2021

i guess again, unstale

@github-actions github-actions bot removed the Stale label Jan 8, 2021
@hross hross added keep enhancement New feature or request labels Jan 15, 2021
@C0ZEN
Copy link
Contributor
C0ZEN commented Jan 16, 2021

I do not think that there is a way to know if a stale label was added automatically or manually during the cron job workflow.

The "good way" to do it IMO would be to use the GitHub feature to run an action when a label is added to an issue or a PR, check if it's the stale one and add a comment.
But it will be in conflict with the cron job because it will also be triggered by it 😞
Also it means that this project would no longer be a simple cron job 😲

Checking the comments would not be a safe solution either IMO because we don't have a date when a label is added so we can't compare the fact that a stale label is here with the fact that a related comment was added.
Also it means that it should take into account the case where the comment was possibly removed to avoid adding it once again.

TL;DR: hard one IMO!

@TheOneRing
Copy link
Author

How about a label "mark stale"

@C0ZEN
Copy link
Contributor
C0ZEN commented Jan 17, 2021

Good idea, we could have a dedicated label to indicate that we want to speedup the stale action manually.
In that case, the name of the label could be a new option so that everyone could choose which is it.
The stale workflow would then check if the label is present and ignore some of the steps like the startDate and the process to define if it needs a stale or not.

I do think though that the closing workflow is based on the date of the label so it would not work as expected to close an issue/PR 😢

@C0ZEN
Copy link
Contributor
C0ZEN commented Jan 23, 2021

I just saw that in fact we can find a label's creation date 🎉
I do not know if it can help but more data means more possibilities.

@C0ZEN
Copy link
Contributor
C0ZEN commented Feb 21, 2021

Possible implementation:

  • Add new option to manually add a label to mark it as stale (pass the name of the label)
  • ? Throw an error if the label is identical as the stale one
  • Do not add the stale label when the manually added label is present (useless)
  • Add the comment about being stale (useful)
  • Ignore the process for closed/locked issues (makes no sense)
  • Skip the start date check (manually added stale label should ignore this)
  • Skip the assignees/milestones checks (manually added stale label should ignore this)
  • Get the creation date of the manually added label (required for the checks of the close action)
  • Check the days before close based on this creation date (basically follow the same process as a normal stale label but from the creation date instead)
  • Close and add a comment when the days before close is reached from the creation date
  • Eventually delete the branch if the option is enabled
  • Any comment/issue should work like the stale process meaning that we should just remove the manual stale label

@TheOneRing @hasezoey do you think I missed something or is there something you don't agree with please?

@hasezoey
Copy link

Do not add the stale label when the manually added label is present (useless)

just to clarify, you mean to use the manually added label, add the comment, but wont add the normal "stale" label?

Eventually delete the branch if the option is enabled

is this meant in relation to Pull Request stales?


just wanna clarify these things, otherwise LGTM 👍

@TheOneRing
Copy link
Author

LGMT

I imagined something like "Label mark as stale" -> "Label stale, stale commend" -> Normal flow
But your solution sounds good :)

@C0ZEN
Copy link
Contributor
C0ZEN commented Feb 22, 2021

@hasezoey yes, the manual stale label workflow will work on it's own and it will be separated completely from the stale label workflow.
Indeed, the option "delete-branch" for pull requests should work exactly like it is currently working.

@C0ZEN
Copy link
Contributor
C0ZEN commented Feb 27, 2021

@TheOneRing @hasezoey I have doubts based on the implementation I proposed.
I was seeing this feature as an "admin stale" but maybe you just wish to bypass the idle time.

If bypass it is then ALL the rules of the stale by idle should be applied as well.
It seems to me that this is something in both cases good to have but what I don't like with the second option is that it means that someone could for example "try to mark for stale" something that will never be processed like for example an issue with an exempted milestone.
Anyway, if you prefer the bypass only, please say so until then I will pause the dev.

@hasezoey
Copy link

If the bypass it is then ALL the rules of the stale by idle should be applied as well.

i saw it like to be able to add an normal-stale (or admin-stale) label, while ignoring exempt labels, and times that would normally trigger an stale (and then wait for the specified time before closing)

@C0ZEN
Copy link
Contributor
C0ZEN commented Feb 27, 2021

@hasezoey thank you for the reply. In that case the implementation I proposed seems good.
This label would ignore most of the rules and instead of basing the stale process on the idle time it will base it on the label creation.
This label would ignore some options than avoid the stale like the startDate for example.

In fact, both kind of behaviours can be a feature so I prefer to have a feedback from @TheOneRing as well.

I proposed manual-stale-label, do you think it's ok @hasezoey?

@hasezoey
Copy link

I proposed manual-stale-label, do you think it's ok @hasezoey?

yes

@TheOneRing
Copy link
Author

Sounds good, so basically the "needs info" label many repos use and after the default stale period it would get marked as stale ? :)

@hasezoey
Copy link
hasezoey commented Mar 1, 2021

Sounds good, so basically the "needs info" label many repos use and after the default stale period it would get marked as stale ? :)

this would mean when the needs info label gets assigned, it would close in the stale-to-close time (my case 7days) and no activity-to-stale time, is this what you meant?

@TheOneRing
Copy link
Author

Well initially I had the 7 days period in mind, that was before we got the start date process, for issues that look stale and so I just can get the default stale comment.
After thinking about it I'm not sure this feature is that important anymore.
I assume that if I perform any action on an issue from before the start date, the issue would be updated?
So it would now be handled by the default algorithm?

@C0ZEN
Copy link
Contributor
C0ZEN commented Mar 1, 2021

@TheOneRing rephrasing:

Sometimes you saw and review an issue and you are waiting for the author's response to take any further action.
In that case, it can be handy to inform him that the issue will be closed automatically in X days without doing anything except adding a label - which is this new one we are talking about.

It would mark as stale way sooner - instead of being based on the issue activity.

Option 1:
This label have the same rules as the stale one.
For example, if you apply it on an issue with an exempted milestone or something that can avoid stale like the startDate it would not stale anything at all.

Option 2:
This label have not the same rules as the stale one.
For example, if you apply it on an issue with an exempted milestone or something that can avoid stale like the startDate it would stale the issue anyway working more like a "super admin" stale.

Both are convenient because if the user reply then it will unstale automatically.

Explained like this, even for me it gave me a better vision and I think the option 2 is basically the more logical one but IMO.

@TheOneRing
Copy link
Author

I'm not sure you can check who set the stale label.
In that case we could easily have both.

  1. A user added the stale label, the bot detects this and adds the default comment.
  2. A user adds the mark as stale label and ....

@C0ZEN
Copy link
Contributor
C0ZEN commented Mar 2, 2021

@TheOneRing

I'm not sure you can check who set the stale label.

Yes, we can know it.

A user added the stale label, the bot detects this and adds the default comment

Yes, it can be done BUT the default workflow check if the issue is stale based on the last activity for a given issue and compare it with a number of days from the days-before-stale option.
So we could improve the logic to add a condition: if the label was added by a user which is not the stale bot then it is a manually added stale label and in that case we base the workflow on this new information.
Meaning that we could keep all the same rules except we will change the way to calculate the stale date.
This has the advantage to be a very small change in the code and the risk to broke something is very minimal.

It would be very convenient that way since we won't need to add a new option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request keep
Projects
None yet
4 participants
0