Github Action: Add action to auto close issues/PRs after a certain time

[vishesh92]

Description

This PR adds a github action to close stale issues and PRs after a certain time.

This action will mark the issue/PR as stale after 120 days. It will add a label and comment marking it as stale.
If there is no activity on an issue/PR after it has been marked stale, it will get closed after 120 days.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 3.58%. Comparing base (53a39d3) to head (22f8747).
⚠️ Report is 2 commits behind head on main.

❗ There is a different number of reports uploaded between BASE (53a39d3) and HEAD (22f8747). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (53a39d3)	HEAD (22f8747)
unittests	1	0

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #8667       +/-   ##
============================================
- Coverage     17.48%   3.58%   -13.91%     
============================================
  Files          5913     445     -5468     
  Lines        529650   37571   -492079     
  Branches      64716    6921    -57795     
============================================
- Hits          92633    1347    -91286     
+ Misses       426572   36058   -390514     
+ Partials      10445     166    -10279     

Flag	Coverage Δ
uitests	3.58% <ø> (-0.01%)	⬇️
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[DaanHoogland]

looks good but, ... (not saying "no"!)
can we use some of these:
exempt-issue-labels Labels on issues exempted from stale
exempt-pr-labels Labels on PRs exempted from stale
only-labels Only issues/PRs with ALL these labels are checked
only-issue-labels Override only-labels for issues only
only-pr-labels Override only-labels for PRs only
any-of-labels Only issues/PRs with ANY of these labels are checked
any-of-issue-labels Override any-of-labels for issues only
any-of-pr-labels Override any-of-labels for PRs only

for instance with the unplanned milestone we might want to keep things around longer. or ready-for-merge we might want to exempt (during freeze)

that said lgtm

[weizhouapache]

agree with Daan

we need to consider the labels.
also the current days (90/30) is too agressive I think.

looks good but, ... (not saying "no"!) can we use some of these: exempt-issue-labels Labels on issues exempted from stale exempt-pr-labels Labels on PRs exempted from stale only-labels Only issues/PRs with ALL these labels are checked only-issue-labels Override only-labels for issues only only-pr-labels Override only-labels for PRs only any-of-labels Only issues/PRs with ANY of these labels are checked any-of-issue-labels Override any-of-labels for issues only any-of-pr-labels Override any-of-labels for PRs only

for instance with the unplanned milestone we might want to keep things around longer. or ready-for-merge we might want to exempt (during freeze)

that said lgtm

[vishesh92]

@DaanHoogland @weizhouapache Let me update the PR.

@weizhouapache After how many days should we mark stale or close the PRs?

[weizhouapache]

@DaanHoogland @weizhouapache Let me update the PR.

@weizhouapache After how many days should we mark stale or close the PRs?

I just went through the issues, actually most of the issues were created in 2023 , few of them in 2022.
I am not sure how many days we should set. maybe 1 year ?

[rohityadavcloud]

@vishesh92 is this being discussed on the dev@ ML ? Perhaps nudge the community (again)?

[rohityadavcloud]

@vishesh92 I like the general idea of it, some questions; how does it consider an issue or PR to be stale (is it by last activity such as commits or comments, or by date of when the issue/PR was opened)? Could we do something like anything opened beyond 2yr+ is closed, as it's not fixed/resolved to the effect in the last 2yr+?

Otherwise LGTM on the general idea, the specific duration may need tweaking.

[sureshanaparti]

LGTM, may need update the stale/close period based on the inputs from discussion

[rohityadavcloud]

LGTM - are we doing this @vishesh92 @Pearl1594 @DaanHoogland ?

[DaanHoogland]

LGTM - are we doing this @vishesh92 @Pearl1594 @DaanHoogland ?

ha, this PR was stale ;), I think we should merge though. Fromality: did we discuss on dev@?

also @vishesh92 i would have gsoc be an exempt-issue-labels

[Copilot]

Pull request overview

This PR introduces a GitHub Action workflow to automatically manage stale issues and pull requests. The workflow marks issues/PRs as stale after 90 days of inactivity and closes them after an additional 30 days if no activity occurs.

Key Changes

• Added a scheduled GitHub Action that runs daily at 1:30 AM UTC
• Configured the actions/stale@v9 action with custom messages and labels for both issues and PRs
• Set inactivity thresholds: 90 days before marking as stale, 30 days before closing

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ShadowJonathan]

I can't reply to the mailing list thread (as I subscribed to it after this issue was made), but I have a STRONG stance AGAINST auto-closing issues. I'd say that marking them as stale has merit, to being able to identify stale issues and cleaning them up, but auto-closing serves less use than not making the issue in the first place; it signals disrespect to users' time to submit those issues, and it isn't an effective remedy to cleaning up issues, and clutters the definition of "fixed" for older issues, and obscures patterns of repeating issues.

I've personally made a site that elaborates on this a bit more (in a rambly fashion, pardon me for that): https://nostalebots.xyz/

[DaanHoogland]

@ShadowJonathan I understand your arguments and have counters, but am willing to apply your suggestion. I think we should then also change the accompanying message to state: “this issue/PR is marked stale, it may be closed at any moment.”.

but auto-closing serves less use than not making the issue in the first place

No, it is being adminstered and archived.

it signals disrespect to users' time to submit those issues

Not more than bothering a community with a complaint and then ghosting them, does.

and clutters the definition of "fixed" for older issues, and obscures patterns of repeating issues.

Closed issues are not deleted but there for eternity to apply statistical analysis on.

I think it is safe to say that I am not in your camp on that one. But all that said, I am in the Apache Cloudstack camp and want to have this project and community running to satisfaction of all, including you ;) so let’s apply your suggestion to address your concerns and revisit later.

[ShadowJonathan]

Thanks for the reply; my own words are merely my own impressions and heard second-hand experiences of many different projects taking the same route, and as such, I'm only taking that here, not inferring that this is and/or will be the case here.

I don't have as much knowledge with the way cloudstack's project is ran, but in a way, I want to put those impressions here as warnings as to where these approaches could lead in the future.

If they're acknowledged, then I'm fine with it, but I think it's often very easy to apply a stalebot without properly being aware of a slippery slope it could lead to.

[DaanHoogland]

@ShadowJonathan , you are allright with these changes as is, or do you have more remarks?

[ShadowJonathan]

Nope, all good, thanks for acknowledging them, and apologies for the harshness :)

[DaanHoogland]

Nope, all good, thanks for acknowledging them, and apologies for the harshness :)

no problem @ShadowJonathan , answer harshness with very kind and extremely polite harshness ;) welcome to the community!!!

/me merging now