# ci: enhance stale issue/PR workflow
- Split stale workflow into marking and closing jobs
- Add dry-run mode input and environment variables
- Improve configuration for timing, messages, and operations per run
## Motivation and Context
To mark and close stale issues/PRs automatically
## How it works
The automations.yml workflow automates the lifecycle of inactive issues
and pull requests using a two-stage process. It is scheduled to run
daily at 2:00 AM UTC and supports manual execution with a dry-run
option.
### 1. Marking Phase (mark-stale job)
This job identifies inactive items and labels them as stale without
closing them.
- Criteria: Any issue or PR with no activity for 30 days.
- Action: Adds the stale label and posts a notification comment.
- Exemptions:
- Draft PRs are ignored.
- Issues labeled with awaiting-approval or work-in-progress are ignored.
- Recovery: If a contributor updates the item, the stale label is
automatically removed.
- Safety: This job is explicitly configured never to close items
(days-before-*-close: -1).
### 2. Closing Phase (close-stale job)
This job handles the final closure of items that have remained inactive
after being marked.
- Criteria: Only targets items that already have the stale label and
have seen no further activity for 15 days.
- Action: Closes the issue or PR and posts a final closure message.
- Safety: This job is explicitly configured never to mark new items
(days-before-*-stale: -1).
### Global Configuration
- Dry Run: Controlled by the DRY_RUN variable. When true, the bot logs
planned actions in the workflow output but does not actually apply
labels, post comments, or close items.
- Throttling: Processes up to 100 items per run to avoid hitting GitHub
API rate limits.
- Permissions: Requires write access to issues and pull requests to
perform its actions.
## How Has This Been Tested?
[Manually tested on
CI](https://github.com/modelcontextprotocol/kotlin-sdk/actions/runs/21984701285)
with dry run
## Breaking Changes
No
## Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing
functionality to change)
- [ ] Documentation update
- [x] Workflow update
## Checklist
<!-- Go over all the following points, and put an `x` in all the boxes
that apply. -->
- [ ] I have read the [MCP
Documentation](https://modelcontextprotocol.io)
- [ ] My code follows the repository's style guidelines
- [ ] New and existing tests pass locally
- [ ] I have added appropriate error handling
- [ ] I have added or updated documentation as needed
## Additional context
<!-- Add any other context, implementation notes, or design decisions
-->
52a0ec3b8f