Skip to content

Issue 353 stale cleanup#369

Open
pritkc wants to merge 2 commits into
csrc-sdsu:mainfrom
pritkc:issue-353-stale-cleanup
Open

Issue 353 stale cleanup#369
pritkc wants to merge 2 commits into
csrc-sdsu:mainfrom
pritkc:issue-353-stale-cleanup

Conversation

@pritkc
Copy link
Copy Markdown
Collaborator

@pritkc pritkc commented May 16, 2026

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Example
  • Documentation

Description

Adds automated inactivity management for open issues, pull requests, and draft pull requests.

The workflow:

  • Runs once per day from GitHub Actions.
  • Scans open issues, PRs, and draft PRs.
  • Ignores workflow bot comments when calculating inactivity.
  • Posts a pre-stale reminder after 14 inactive days.
  • Adds stale after 28 inactive days and posts a close warning.
  • Closes stale items 42 days after the stale warning if there is still no human activity.
  • Removes stale when human activity happens after the stale warning.
  • Supports a single protection label: keep-open.
  • Posts reminder-only comments on keep-open items every 28 inactive days.
  • Never marks keep-open items stale and never closes them.
  • Adds a keep-open request section to issue and PR templates.

Human activity includes non-bot comments, issue/PR edits, label changes, PR commits, and PR reviews.

Related Issues & Documents

Maintainer Notes

No manual label setup is required for normal operation. On a non-debug run, the workflow creates or updates:

  • stale: used by the workflow for items scheduled for automatic closure.
  • keep-open: manually applied by maintainers when an issue or PR should stay open despite inactivity.

Maintainers only need to apply keep-open when they want to protect an item from stale handling. If keep-open is applied to an item that already has stale, the next workflow scan removes stale.

After merge, maintainers can run the workflow manually from the Actions tab with debug_only: true to preview behavior without comments, labels, or closures.

GitHub Workflow Test Methodology

The workflow was tested on the fork default branch so workflow_dispatch could run exactly as it will after merge.

Fork setup used for runtime tests:

Runtime workflow runs:

Test artifacts:

What was verified:

  • Manual workflow dispatch runs successfully from a default branch.
  • The workflow creates/updates stale and keep-open.
  • Regular issues receive a pre-stale reminder.
  • Bot comments do not reset inactivity.
  • Regular issues receive stale plus a close warning.
  • Stale issues close when the close threshold is reached.
  • keep-open issues receive reminder-only comments, are not marked stale, and are not closed.
  • Human activity after a stale warning removes stale.
  • Draft PRs are scanned, marked stale, and closed with pull-request wording.

Static workflow checks:

  • YAML parse check passed for .github/workflows/stale.yml.
  • actionlint passed for .github/workflows/stale.yml.
  • Embedded actions/github-script JavaScript syntax check passed.
  • git diff --check passed.

Added/updated tests?

We encourage you to test all code included with MOLE, including examples.

  • Yes
  • No, and this is why: please replace this line with details on why tests
    have not been included
  • I need help with writing tests

Read Contributing Guide and Code of Conduct

Post-merge Task

Run the workflow manually once with debug_only: true to preview the first production scan before allowing the scheduled run to make changes.

@pritkc pritkc marked this pull request as ready for review May 16, 2026 17:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Proposal: Automate stale issue/PR cleanup and improve Project Board hygiene

1 participant