Unable to comprehend handling of stale issue when days-before-issue-stale is -1 #451
Comments
|
For the first case: To be marked as stale, we check that the days before stale are superior or equal to 0. If the workflow had mark as stale, it would have considered the issue as stale the like when a stale label was just applied, obviously. Since it's -1, it makes sense to have this when working with a cron job for an issue not yet stale. You mentioned that you wish to have a workflow running with manual stale label, yet we can see in the logs "This issue hasn't a stale label" which mean that currently, the workflow is processing something that is a candidate for the stale action, not the close action. Checking this issue astropy/astropy#11011 confirm to me that there is no "Stale" label applied which is the default value of the option "stale-issue-label" which is not override by your configuration. Can you provide the logs of this issue astropy/astropy#11011 but beforehand add a "Stale" label? |
|
Re: "Stale" label -- We use "Close?" in lieu of "Stale". I thought this would have made it understand this: stale-issue-label: 'Close?'
any-of-issue-labels: 'Close?'We choose not to create a new label called "Stale" because we have been using "Close?" for many years. |
|
Re: logs -- I think these are the ones (the very first and second runs). First attempt: https://github.com/astropy/astropy/runs/2626331162?check_suite_focus=true Second attempt: https://github.com/astropy/astropy/runs/2635921679?check_suite_focus=true |
|
In the first attempt config that you display above, there is no 'stale-issue-label' option. |
|
Correct. So I added it in the second attempt and still it didn't quite do what I wanted. |
|
I will take a look at the second case later |
|
Thank you! Your advise would be much appreciated. 🙏 |
|
If the option to remove the stale label when updated is enabled, and if the issue has been commented, then the stale label is removed. FYI, in the code we expect There is also an issue in the default values that I already fixed in this PR #456 because the option |
|
@pllim FYI I have one concern about the configuration. |
|
Yeah, I saw actions/toolkit#725 but that shouldn't have changed |
I think that is possible but I might not get to it for a few days. Thanks for all your help! |
|
Actually thinking about this more, testing this live on our repo downstream might be a little controversial, as it will introduce a bunch of temporary commits into Is there a way to generate the log you want locally? Say, use some GitHub API to pull in the |
|
If you wait for the merge of #463, and update your config to use the main branch, you can enable the debug logs and the debug-only option as mentioned in the documentation. |
|
Yes, it is currently running on v3 in debug mode, so switching to main would be less controversial maybe. |
|
@pllim I found an issue that I created... So, here is the mistake: Line 53 in e884599 As you can, you see, instead of giving to _toOptionalBoolean the name of the input, it get the value...I forgot that internally, the function already get the input so the value at the end given to this option was not the right one... Sorry! |
|
No worries. I am glad you found the cause. Thank you for your continued help! |
|
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 |
|
up |
|
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 |
|
up |
|
Thanks! After some contemplation, we decided to port our old bot instead due to the differences between our stale policies and yours. Still, I am looking forward to use this for a simpler project. |
|
It seems though that there was an intention to keep digging into this? I was looking into using this action, but I have the same policy as described in this ticket, so this issue being fixed would help me :) |
|
Ok, I'll reopen then. :) |
|
For academic purpose, I share with you the logic we decided to go with. If you end up using it, please be advised that I wrote it for a particular project in mind and probably won't try to generalize it for other policies: https://github.com/pllim/action-astropy-stalebot |
…ity (#540) * chore(assignees): add logs * docs(readme): use the override syntax to simplify the reading * docs(readme): add missing default options * docs(readme): add 3 new options to ignore activity before stale * chore(action): add 3 new options * fix(removeStaleWhenUpdated): use the value of the action config as expected Fixes #451 * chore(main): add 3 new options * feat(ignore): add new class to ignore all activities before stale * feat(option): add new options to ignore all activities before stale * chore(index): update index file * docs(readme): fix typo * docs(readme): add missing empty row * chore(rebase): fix logger issues due to rebase * chore: aplly changes due to rebase * refactor(naming): change the name of the options as suggested * chore(logs): reverse the logs as well * docs(readme): format the table of options * refactor(naming): rename the the options * style(rename): rename more updates wording to activities * build(ci): run the test step as expected for a CI instead of using a real linter with auto fix and the tests verbose as fuck * chore: handle breaking changes due to new changes * refactor(naming): rename and reverse the options * style(tests): use plural for some describe * docs(days-before-stale): list the new option * chore(index): update index file * chore: keep static methods on top * chore(logs): remove useless log
Describe your issue
What I want: For issues, don't try to apply stale labels, as those are all applied manually by a human. Only go through the issues labeled as stale (manually) and close them after 7 days of inactivity. This action should not try to apply/remove the stale label but only act upon it.
What happened: I ran two configurations (see below) in dry run mode but unsure if any of them have the exact desired outcome from the logs. I wish to fully understand this behavior before production.
Case studies:
closed-by-botlabel.Noneastropy/astropy#11710 -- Same outcome as above.Your stale action configuration
I tried two configurations based on previous discussions with y'all. Relevant snippets below.
First attempt
https://github.com/astropy/astropy/blob/0e5a37485567fc2fac4429c2b4f719ebef6ab397/.github/workflows/ci_cron_daily.yml#L49-L77
Not sure why it decided it is a no-op. At least, I think this means no-op, as I am looking for a log entry that would say "closing this issue" or something similar but I don't see it. It just says the issues are not stale even though they are.
Second attempt
Added a
stale-issue-labelparameter.https://github.com/astropy/astropy/blob/769031bb61ff8f179e932805d5587d3cdbe798a9/.github/workflows/ci_cron_daily.yml#L49-L79
I think the first case is handled correctly, at least in theory.
I don't know why it is trying to remove the stale label for the second case. This is not what I thought would happen.
Further context
astropy/astropy#11070
The text was updated successfully, but these errors were encountered: