Skip to content

ci: add stale issue and PR cleanup workflow - #216

Open
kietcoderlor wants to merge 3 commits into
Raftersecurity:mainfrom
kietcoderlor:fix-35-stale-workflow
Open

ci: add stale issue and PR cleanup workflow#216
kietcoderlor wants to merge 3 commits into
Raftersecurity:mainfrom
kietcoderlor:fix-35-stale-workflow

Conversation

@kietcoderlor

Copy link
Copy Markdown

Summary

Closes #35.

This PR adds .github/workflows/stale.yml using actions/stale@v9 to help manage inactive issues and pull requests.

What changed

  • Added a scheduled stale cleanup workflow.
  • Issues are marked as stale after 60 days of inactivity.
  • Stale issues are closed after 14 additional days of inactivity.
  • Pull requests are marked as stale after 30 days of inactivity.
  • Pull requests are not automatically closed because the issue only requested stale labeling for PRs.
  • Issues and PRs labeled pinned or security are exempt.
  • The stale label is removed when new activity occurs.
  • Added workflow_dispatch so maintainers can run the workflow manually.

Test plan

  • Confirmed the diff only touches .github/workflows/stale.yml.
  • Ran git diff --check.
  • Ran npx -y prettier --check .github/workflows/stale.yml.
  • Verified the workflow uses actions/stale@v9.
  • Verified issue stale/close timing matches the issue requirements.
  • Verified PR stale timing matches the issue requirements.
  • Verified PR auto-close is disabled with days-before-pr-close: -1.
  • Verified pinned and security labels are exempt.

@Rome-1

Rome-1 commented Aug 28, 2026

Copy link
Copy Markdown
Collaborator

This is a clean implementation — it matches every bullet in #35 line for line, the days-before-pr-close: -1 idiom for "label but never close" is right, the permissions are correctly scoped to issues: write + pull-requests: write, and workflow_dispatch was a good addition to include unasked. Thanks also for the specific test plan.

Before merging I want to widen one thing, and it's a gap in my original issue rather than anything you got wrong.

I checked what the first run would actually do to the current backlog: 7 of our 11 open issues would be marked stale immediately and closed 14 days later — and five of those are labeled good first issue or help wanted. Those sit idle on purpose; they're the queue new contributors pick from. (This PR's sibling, #215, came out of exactly that pool.) Auto-closing them would quietly dismantle the onboarding backlog.

Could you add to both exempt lists:

exempt-issue-labels: pinned,security,good first issue,help wanted
exempt-pr-labels: pinned,security,good first issue,help wanted

One other thing that was on my side: pinned and security didn't exist as labels in this repo, so those exemptions would have matched nothing. I've created them both — no action needed from you.

With that one change this is good to merge.

Rome-1 added a commit that referenced this pull request Aug 29, 2026
The suite only triggered on `pull_request` into `prod`, so every contributor
PR targeting `main` merged with no automated verification — tests ran later,
at release time, when main was promoted to prod. #215, #216 and #218 all sat
mergeable with an empty status-check rollup.

Add `main` to the trigger and gate the jobs: PRs into prod always run (that
is the release gate, unchanged), PRs into main run only for outside
contributions. Our own work — Rome-1's PRs, or any branch living in the
Raftersecurity repo — is reviewed and tested locally before it is pushed, so
re-running the full matrix would only burn runner minutes.

Uses `pull_request`, not `pull_request_target`: fork PRs run with a read-only
token and no secrets. Tests that need RAFTER_API_KEY already skip when it is
absent, so a fork PR gets a clean green rather than a spurious failure.
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.

ci: add stale issue/PR cleanup workflow

2 participants