Repository navigation
fix(ci): fix mergify stale/close rules that never trigger - #798
Conversation
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses several critical bugs in the Mergify configuration that prevented the automatic stale and close lifecycle for inactive pull requests from functioning correctly. The changes ensure that pull requests are properly identified as stale, reminded once, and then automatically closed if they remain inactive, improving repository hygiene by managing old, unmerged work. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughRemoved Mergify stale-PR rules from Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Scheduler as "GitHub Scheduler\n(daily)"
participant Runner as "Actions Runner\n(ubuntu-latest)"
participant StaleAction as "actions/stale@v10"
participant Repo as "Repository\n(Issues & PRs)"
Scheduler->>Runner: trigger workflow
Runner->>StaleAction: run with config (thresholds, labels, messages)
StaleAction->>Repo: list issues & PRs
StaleAction->>Repo: add/modify labels (`stale`, `unstale`)
StaleAction->>Repo: post stale/close comments
StaleAction->>Repo: close items meeting thresholds
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This is an excellent fix for a tricky CI problem. Your detailed explanation of the bugs in the stale PR lifecycle is very clear, and the proposed changes correctly address all the identified issues. The logic of using label = stale and adjusting the timeframes seems sound and should make the stale/close process work as intended. I have one suggestion to further simplify one of the rules for better clarity.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/mergify.yml (1)
123-133:⚠️ Potential issue | 🟡 MinorThe
sender != mergify[bot]syntax is valid, but other bot-triggered updates may still remove the stale label.The condition
sender != mergify[bot]correctly filters Mergify's own updates and is syntactically valid. However, the current rule doesn't account for other bots (e.g.,dependabot[bot],github-actions[bot]) that may update the PR. If bot-initiated updates shouldn't reset the stale timer, consider filtering them as well:conditions: - updated-at > 14 days ago - -closed - label = stale - sender != mergify[bot] - sender != dependabot[bot] - sender != github-actions[bot]Alternatively, review whether allowing non-author collaborators and other bots to remove the stale label aligns with the intent of "Remove stale label when PR becomes active." The description says "by the author," but the condition allows any human user to trigger label removal.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/mergify.yml around lines 123 - 133, The rule currently uses the condition sender != mergify[bot] alongside updated-at > 14 days ago and label = stale, but that still allows other bots to clear the stale label; update the conditions block to either (A) explicitly exclude common bots by adding additional checks like sender != dependabot[bot] and sender != github-actions[bot] (and any other org-specific bots), or (B) more strictly enforce "by the author" behavior by replacing/augmenting the sender check with an author = <author> (or equivalent Mergify author condition) so only the PR author can remove the stale label; adjust the conditions around sender != mergify[bot], label = stale, and updated-at > 14 days ago accordingly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Outside diff comments:
In @.github/mergify.yml:
- Around line 123-133: The rule currently uses the condition sender !=
mergify[bot] alongside updated-at > 14 days ago and label = stale, but that
still allows other bots to clear the stale label; update the conditions block to
either (A) explicitly exclude common bots by adding additional checks like
sender != dependabot[bot] and sender != github-actions[bot] (and any other
org-specific bots), or (B) more strictly enforce "by the author" behavior by
replacing/augmenting the sender check with an author = <author> (or equivalent
Mergify author condition) so only the PR author can remove the stale label;
adjust the conditions around sender != mergify[bot], label = stale, and
updated-at > 14 days ago accordingly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 341960da-d5f2-4510-899d-365df862e784
📒 Files selected for processing (1)
.github/mergify.yml
![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: 9661a4a0f2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
9c70008 to
7f2c09f
Compare
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/stale.yml:
- Around line 3-6: The workflow only triggers on schedule; add a manual trigger
by adding the workflow_dispatch event alongside the existing schedule under the
top-level on key so you can run the stale workflow on demand (update the on
block to include both schedule: - cron: '30 1 * * *' and workflow_dispatch).
Ensure you place workflow_dispatch at the same level as schedule in the YAML so
GitHub Actions recognizes the manual trigger.
- Around line 11-14: Remove the unnecessary "actions: write" permission from the
permissions block in the stale workflow: update the permissions section (the
block containing "issues: write", "pull-requests: write", and "actions: write")
to omit the "actions: write" entry so only "issues: write" and "pull-requests:
write" remain.
- Around line 25-26: Remove the unused bidirectional label configuration by
deleting the labels-to-add-when-unstale and labels-to-remove-when-stale keys
from the stale.yml workflow; locate the entries named
"labels-to-add-when-unstale" and "labels-to-remove-when-stale" and remove them
so the workflow no longer references the unused "unstale" label, simplifying the
workflow while preserving standard staleness behavior.
- Line 17: The workflow reference actions/stale@v10 may require GitHub Actions
runner v2.327.1+ and Node 24; verify the CI environment compatibility for
actions/stale@v10 by checking the repository's runner version (hosted or
self-hosted) and Node runtime used, and if runners are older either upgrade the
runners to v2.327.1+ (or GitHub-hosted images that include Node 24) or change
the workflow to use a compatible tag (e.g., actions/stale@v9) until runners are
upgraded; specifically locate the uses: actions/stale@v10 entry in the workflow
and take one of these corrective actions.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c2a4a910-1e9a-4b03-a988-19ba36fc5c65
📒 Files selected for processing (2)
.github/mergify.yml.github/workflows/stale.yml
The mergify stale PR rules had three bugs: 1. The stale comment posted at 14 days resets `updated-at`, so the 30-day close rule never fires — perpetually "updated" by Mergify. 2. The "remove stale label" rule triggers immediately after adding it because the comment bumps `updated-at`. 3. The stale rule re-fires on every evaluation even if already labeled. Additionally, `updated-at` is unreliable — GitHub bumps it for invisible events like conflict recalculation when main changes. Replace Mergify stale/close rules with `actions/stale` GitHub Action (same approach as vLLM), which correctly tracks activity without being affected by bot comments or internal GitHub updates. - PRs: stale after 14 days, closed after 16 more days (30 total) - Issues: stale after 90 days, closed after 30 more days - Draft PRs and `keep-open` labeled items are exempt Signed-off-by: Chang Su <chang.s.su@oracle.com>
7f2c09f to
d29e020
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d29e02015f
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/stale.yml (1)
11-14:⚠️ Potential issue | 🟠 MajorRemove unnecessary
actions: writepermission.
actions/staleonly needs issue/PR write scope;actions: writeis broader than required.🔒 Proposed fix
permissions: issues: write pull-requests: write - actions: write🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/stale.yml around lines 11 - 14, The workflow permissions block grants an unnecessary broad permission—remove the "actions: write" entry from the permissions map so only the scoped permissions remain; specifically edit the permissions block containing "issues: write" and "pull-requests: write" and delete the "actions: write" line to limit access for the stale action.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/stale.yml:
- Around line 18-26: The workflow claims to exempt "keep-open" labeled items but
only has exempt-draft-pr: true; add explicit label exemptions by adding the keys
exempt-issue-labels and exempt-pr-labels (or exempt-pr-labels) and set them to
include "keep-open" (prefer a YAML list like ['keep-open']) so both issues and
PRs with the keep-open label are skipped by the stale action; update near the
existing exempt-draft-pr/stale-issue-label settings to keep related config
together.
---
Duplicate comments:
In @.github/workflows/stale.yml:
- Around line 11-14: The workflow permissions block grants an unnecessary broad
permission—remove the "actions: write" entry from the permissions map so only
the scoped permissions remain; specifically edit the permissions block
containing "issues: write" and "pull-requests: write" and delete the "actions:
write" line to limit access for the stale action.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: a880386b-65c2-4a1b-a54a-02d69de3a529
📒 Files selected for processing (2)
.github/mergify.yml.github/workflows/stale.yml
Signed-off-by: Chang Su <chang.s.su@oracle.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e3ef4ed646
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| operations-per-run: 500 | ||
| exempt-draft-pr: true |
There was a problem hiding this comment.
keep-open opt-out in the stale action
This workflow only exempts draft PRs. actions/stale uses exempt-issue-labels / exempt-pr-labels to skip labeled items, and neither is set here, so any issue or PR that maintainers label keep-open will still be marked stale and auto-closed on the normal schedule. That breaks the explicit manual opt-out described in this change for long-lived tracking items and PRs.
Useful? React with 👍 / 👎.
…t#798) Signed-off-by: Chang Su <chang.s.su@oracle.com>
…t#798) Signed-off-by: Chang Su <chang.s.su@oracle.com>
1 participant
Description
Problem
The Mergify stale PR rules have three bugs that prevent auto-close from ever firing:
Stale comment resets updated-at: The 14-day stale rule posts a comment, which bumps updated-at. The 30-day close rule checks updated-at < 30 days ago, but the PR was just "updated" by the comment. The cycle repeats every 14 days indefinitely.
Stale label immediately removed: The "remove stale label" rule checks updated-at > 14 days ago, which is true right after the stale comment. Label is added and removed in rapid succession.
updated-at is unreliable: GitHub silently bumps updated-at for invisible events like merge conflict recalculation when main changes. This explains why all old PRs show recent update timestamps despite no real activity for months.
As a result, no open PR has ever received the stale label or been auto-closed.
Solution
Replace Mergify stale/close rules with
actions/staleGitHub Action (same approach as vLLM), which correctly tracks activity without being affected by bot comments or internal updated-at recalculations.Changes
.github/mergify.yml: Remove broken stale/close/remove-stale rules, replace with comment pointing to the workflow.github/workflows/stale.yml: New workflow usingactions/stale@v10running daily at 1:30 AM UTCkeep-openlabeled items are exemptunstalelabel added/removed for clean state trackingTest Plan
After merge, monitor over the next few days:
stalelabel on the next daily runstalelabel removedSummary by CodeRabbit