ci: add stale issue/PR automation (#574)#1130
Conversation
Implements the policy requested in #574: mark issues/PRs stale after 60 days of inactivity and close 14 days later (exempting pinned/security and active labels). Runs daily and via workflow_dispatch for manual/dry-run verification.
actions/stale does not create its label, so add an idempotent gh label create step. Wire workflow_dispatch dry_run input to actions/stale debug-only (default true) so manual runs validate the policy without labeling/closing; the daily schedule still runs live.
Greptile SummaryThis PR adds stale issue and pull request automation. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (2): Last reviewed commit: "ci(stale): skip label mutation on dry ru..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
|
Warning Review limit reached
More reviews will be available in 4 minutes and 43 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughAdds a scheduled and manually runnable workflow for stale issues and pull requests, with dry-run support, label bootstrapping, and ChangesStale issue automation workflow
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related issues
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/stale.yml:
- Around line 42-50: The stale-label bootstrap step in the workflow is
overwriting an existing label because `gh label create` is using `--force`;
update the `Ensure the "stale" label exists` step so it only creates the label
when missing and does not reset its properties on every run. Use the existing
workflow step with `gh label create stale` as the locator, and remove the
forceful update behavior while preserving the repo, color, and description
settings for initial creation only.
- Line 52: The workflow currently uses the mutable actions/stale@v9 tag, so
update the stale action reference in the stale workflow to an immutable full
commit SHA and, if compatible, move to the latest major release. Locate the
uses: actions/stale entry and replace the tag with the pinned SHA recommended
for v10.3.0, or alternatively pin the v9.1.0 SHA if you must stay on v9.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: b2ab2b3c-fc8a-490b-90d4-779aa56f5ae9
📒 Files selected for processing (1)
.github/workflows/stale.yml
| --description "No recent activity; will be auto-closed if it stays inactive" | ||
| --force | ||
|
|
||
| - uses: actions/stale@v9 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major
🧩 Analysis chain
🏁 Script executed:
git ls-files ".github/workflows/*.yml" | head -5 | xargs grep "uses: actions/.*@.*" | grep -v "@" | head -10Repository: RunMaestro/Maestro
Length of output: 156
🏁 Script executed:
git ls-files ".github/workflows/*.yml" | head -5 | xargs grep -E "uses: .*/.*@[a-f0-9]{40}" | wc -lRepository: RunMaestro/Maestro
Length of output: 158
🏁 Script executed:
git ls-files ".github/workflows/*.yml" | head -5 | xargs grep -E "uses: .*/.*`@v`[0-9]" | head -10Repository: RunMaestro/Maestro
Length of output: 789
🌐 Web query:
actions/stale github action pin to sha best practices
💡 Result:
Pinning GitHub Actions, such as actions/stale, to a full-length commit SHA is a widely recognized security best practice that protects against supply chain attacks, including tag-retargeting or account compromise [1][2][3]. Because tags and branch names are mutable pointers, pinning to a specific, immutable commit SHA ensures that your workflow consistently runs the exact code you have vetted [1][4][5]. Best Practices for SHA Pinning: 1. Use Full-Length SHAs: Always use the full 40-character commit SHA [1][6]. Avoid short SHAs to prevent potential ambiguity or collision risks [6]. 2. Maintain Human-Readable Provenance: When pinning to a SHA, include the original version tag as a trailing comment [2][3]. This practice is critical because automated dependency management tools like Dependabot and Renovate use this comment to correlate the pinned SHA back to the semantic version, allowing them to propose updates when new tags are released [2][4][3]. Example: uses: actions/stale@b5d41d4 # v10.2.0 3. Automate Updates: Use tools like Dependabot or Renovate to manage these pinned dependencies [2][7][3]. These tools can be configured to open pull requests that update both the SHA and the version comment, ensuring your actions remain current without sacrificing security [2][4][3]. 4. Enforce via Policy: If you are an administrator, you can enforce this practice at the organization or repository level using GitHub's "Allowed actions and reusable workflows" policy [1][8]. When enabled, this policy causes any workflow that uses a non-pinned action (or a tag-based reference) to fail [8][4]. 5. Use Helper Tools: To streamline the transition or maintain compliance, consider using tools like zizmor (for auditing) or gha-hashpinner (for automated pinning of existing workflows) [9][6][3]. While pinning provides significant security benefits by ensuring immutability, it should be part of a broader security strategy that includes reviewing the actions you depend on and utilizing security scanners to detect potential issues in your workflow files [9][7][3].
Citations:
- 1: https://docs.github.com/en/actions/reference/security/secure-use
- 2: https://safeguard.sh/resources/blog/github-actions-pinning-sha-vs-tag
- 3: https://architecture.lullabot.com/adr/20260505-pin-github-actions-to-hash/
- 4: https://www.romainlespinasse.dev/posts/github-actions-commit-sha-pinning/
- 5: https://www.stepsecurity.io/blog/pinning-github-actions-for-enhanced-security-a-complete-guide
- 6: https://safeguard.sh/resources/blog/how-to-pin-github-actions-to-shas-correctly
- 7: https://emmer.dev/blog/pin-your-github-actions-to-protect-against-mutability/
- 8: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/
- 9: https://github.com/mfisher87/gha-hashpinner
🌐 Web query:
actions/stale@v9 latest commit sha
💡 Result:
The latest release of the actions/stale action is v10.3.0 [1]. The v9 series, which is no longer the latest major version, concluded with version v9.1.0 [2]. The commit SHA for the v9.1.0 release of actions/stale is 28c89c8a983196c34e0689b0d62a9b3a4a2b9032. While you requested the SHA for v9, it is recommended to use the latest version (v10.3.0), which corresponds to commit SHA eb5cf3af3ac0a1aa4c9c45633dd1ae542a27a899 [3]. If you specifically require v9 for compatibility or stability reasons, ensure you are pinning to the full-length commit SHA for security and consistency [4].
Citations:
- 1: https://github.com/actions/stale/releases/tag/v10.3.0
- 2: https://github.com/actions/stale/releases/tag/v9.1.0
- 3: actions/stale@eb5cf3a
- 4: [TASK] Ensure all remaining GitHub Actions are pinned to specific commit SHAs longhorn/longhorn#12920
Pin actions/stale to a full commit SHA and consider upgrading to the latest major version.
The current usage of actions/stale@v9 relies on a mutable tag, which poses a supply chain risk, especially given the workflow's write permissions on issues and pull requests. GitHub Actions best practices recommend pinning to a full 40-character commit SHA to ensure immutable execution.
The current v9 series ends at v9.1.0 (SHA: 28c89c8a983196c34e0689b0d62a9b3a4a2b9032). The latest major version is v10.3.0 (SHA: eb5cf3af3ac0a1aa4c9c45633dd1ae542a27a899).
Update the line to:
uses: actions/stale@eb5cf3af3ac0a1aa4c9c45633dd1ae542a27a899 # v10.3.0If you prefer to remain on the v9 series for compatibility, use the v9.1.0 SHA instead.
🧰 Tools
🪛 zizmor (1.26.1)
[error] 52-52: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/stale.yml at line 52, The workflow currently uses the
mutable actions/stale@v9 tag, so update the stale action reference in the stale
workflow to an immutable full commit SHA and, if compatible, move to the latest
major release. Locate the uses: actions/stale entry and replace the tag with the
pinned SHA recommended for v10.3.0, or alternatively pin the v9.1.0 SHA if you
must stay on v9.
Source: Linters/SAST tools
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 85ebc16c60
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| days-before-issue-stale: 60 | ||
| days-before-issue-close: 14 | ||
| stale-issue-label: stale | ||
| exempt-issue-labels: 'pinned,security,up next,back burner,approved,blocking' |
There was a problem hiding this comment.
The repository's current labels include high-priority for work the maintainers want sooner, but this issue exemption list omits it. Any high-priority issue with no comments or edits for 60 days will now be marked stale and auto-closed 14 days later, despite the workflow comment saying active triage labels are protected; add high-priority to the exempt issue labels so prioritized work is not closed by the housekeeping bot.
Useful? React with 👍 / 👎.
| permissions: | ||
| issues: write | ||
| pull-requests: write |
There was a problem hiding this comment.
When this workflow hits operations-per-run: 200, actions/stale uses the Actions cache to remember where it stopped; I checked the action README, which recommends actions: write when permissions are restricted and documents the cache-backed state. Because this permissions block omits the actions scope, cache updates can fail with 403 and later runs keep reprocessing the same prefix instead of reaching the rest of the backlog; include actions: write so the workflow can make progress.
Useful? React with 👍 / 👎.
…t actions:write (#574) Review fixes: guard the gh label create step so a dry-run dispatch does not mutate labels; add high-priority to exempt-issue/pr-labels; add actions:write for the stale state cache. Declined SHA-pinning (repo pins actions by major tag) and label-overwrite change (intentional, documented).
|
@greptile re-review please |
1 participant
Summary
Closes #574. Adds a GitHub Actions stale workflow implementing the policy requested in the issue: mark issues/PRs stale after 60 days of inactivity and close 14 days later (about 74 days total), exempting
securityand the repo's active triage labels.Changes
.github/workflows/stale.ymlusingactions/stale@v9.cron) and viaworkflow_dispatch. Manual dispatch defaults to a dry run (debug-only) so maintainers can validate the policy without labeling/closing anything; the scheduled run is live.gh label create stale --force) so thestalelabel exists before the action tries to apply it (actions/stale applies but does not create it).permissions, concurrency guard, draft-PR exemption, andoperations-per-runcap.Notes
pinnedis included in the exempt list for forward compatibility (a no-op until a maintainer creates/applies that label).codex exec(read-only); the two findings (missingstalelabel, misleading dry-run comment) are addressed above.Summary by CodeRabbit