Update & improve workflow for stale issues & PRs #7045
Conversation
1. The previous settings were incorrect. The value of `stale-issue-label` should be `status/going-stale`; it is the value of `close-issue-label` that should be `status/stale`. 2. Added a couple of labels that would exempt PRs from staleness. 3. Per discussion on issue quantumlib#6866, the message should be more clear that users can easily reopen the issue or PR by commenting on it.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #7045 +/- ##
==========================================
- Coverage 98.17% 98.17% -0.01%
==========================================
Files 1089 1089
Lines 95177 95177
==========================================
- Hits 93438 93436 -2
- Misses 1739 1741 +2 ☔ View full report in Codecov by Sentry. |
.github/workflows/stale.yml
Outdated
| the Cirq project maintainers at [email protected]. | ||
| This pull request has been closed due to inactivity for 60 days since | ||
| the time the `status/stale` label was applied. If you would like to | ||
| restore its active status, please leave a comment here; doing so will |
There was a problem hiding this comment.
here and in close-issue-message
| restore its active status, please leave a comment here; doing so will | |
| continue working on this PR, feel free to reopen it. |
There was a problem hiding this comment.
Good catches! Thanks.
Is it a requirement to have different labels for |
This makes corrections to the "close" messages per [review comments by @NoureldinYosri](quantumlib#7045 (comment)).
To avoid writing actual duration values in multiple places (and thus face the risk of not updating some of them if we decide to change values in the future), this now uses environment variables to store the important values. This also provides an easier way of writing the lists of exempt labels. The stale handler action needs them as a comma-separated string, and this is a bit of a PITA to edit when we make changes. We can make it easier on ourselves in the future by using a list format instead.
Per [discussion in review](quantumlib#7045 (comment)), we decided we don't need separate labels `status/going-stale` and `status/stale`. When an issue or PR is closed due to staleness, the comment left by the workflow will make it clear why it was closed. We can simplify things by using a single label.
Not a requirement, no. I think I only followed the existing convention in Cirq; the going-stale label has been around since 2019, and while the number of issues showing that label is small, that may be misleading because IIRC the workflow would remove the going-stale label when it applies the Anyway, I like the simplification, and in any case, would defer to your experiences. I'll go ahead and update stale.yml to use one label. If we are doing this, perhaps we should also get rid of |
More of the workflow names in Cirq are, well, names, rather than statements about what they do.
mhucka
added
the
kind/health
mhucka
changed the title
The previous settings were incorrect. The value of
stale-issue-labelshould bestatus/going-stale; it is the value ofclose-issue-labelthat should bestatus/stale.Added a couple of labels that would exempt PRs from staleness.
Per discussion on issue Revisit policy of auto-closing issues #6866, the message should be more clear that users can easily reopen the issue or PR by commenting on it.