Skip to content

Conversation

@Ronitsabhaya75
Copy link
Contributor

@Ronitsabhaya75 Ronitsabhaya75 commented Nov 5, 2025

Type of Change

  • Bug fix
  • New feature
  • Breaking change
  • Documentation update

Motivation and Context

  • PRs inactive for 30 days → marked as stale with friendly reminder
  • PRs inactive for 45 days → automatically closed
  • Security, critical, and dependency PRs are exempt from auto-closure
  • Stale label automatically removed if PR is updated

Testing

  • Tested locally
  • Added/updated tests
  • Added/updated docs

@Ronitsabhaya75 Ronitsabhaya75 changed the title Add stale management ci: add stale PR and issue management workflow Nov 5, 2025
@Ronitsabhaya75 Ronitsabhaya75 changed the title ci: add stale PR and issue management workflow ci: add stale PR management workflow Nov 5, 2025
Comment on lines 25 to 26
days-before-stale: 14
days-before-close: 30
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should up these numbers to 30 days for stale and 60 days for close, though I'm open to other feedback here.

Ideally things are merged much faster than that, but we should account for large changes that take a while to deliberate and for things like people going on vacations.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should up these numbers to 30 days for stale and 60 days for close, though I'm open to other feedback here.

Ideally things are merged much faster than that, but we should account for large changes that take a while to deliberate and for things like people going on vacations.

I feel like 30 days grace period for making it stale is good and closing should be at 35th or 40th day this way we dont have large numbers of pr gathered.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be more comfortable with giving people a two week period to prevent their work from being closed. How do you feel about closing after 44/45 days?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd be more comfortable with giving people a two week period to prevent their work from being closed. How do you feel about closing after 44/45 days?

I feel like 45 days are enough time for closing

days-before-issue-stale: -1
days-before-issue-close: -1

remove-stale-when-updated: true No newline at end of file
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably not super necessary, but we should consider changing this to remove-pr-stale-when-updated.


The PR will be closed in 30 days if there's no activity.

If you need help or have questions, feel free to ask! We appreciate your contribution. 🙏
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer we remove this emoji

stale-pr-message: |
This pull request has been inactive for 2 weeks and will be marked as stale.

If you're still working on this, please:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make it clear that they only need to do one of the following list?

close-pr-message: |
This pull request was automatically closed due to inactivity.

If you'd like to continue this work, feel free to:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thing here, only one option is necessary. Though they should always feel free to comment if they need assistance :)

@katiewasnothere
Copy link
Contributor

Thanks for working on this @Ronitsabhaya75, I think this will be really helpful for us to have!

Could you update the PR description to match that this workflow is only for PRs? Since the repo is set to squash commits when we merge PRs, the PR description becomes the squashed commit's message, so we want to make sure we keep that accurate. Thanks!

@Ronitsabhaya75
Copy link
Contributor Author

for sure katie I can

Thanks for working on this @Ronitsabhaya75, I think this will be really helpful for us to have!

Could you update the PR description to match that this workflow is only for PRs? Since the repo is set to squash commits when we merge PRs, the PR description becomes the squashed commit's message, so we want to make sure we keep that accurate. Thanks!

For sure Katie I'll update the description and update reviewed changes asap.

Thank you so much for review

stale-pr-label: 'stale'

exempt-pr-labels: 'security,critical,dependencies'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have a process for using labels like these today, so I think we should remove this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok I'll def remove those labels

Comment on lines +16 to +17
permissions:
pull-requests: write
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@realrajaryan pointed out to me that there's an issue on actions/stale where issues: write was required even when only dealing with PRs here. The last comment on that issue mentions that someone was still hitting it in 2024, so it's possible that this is no longer an issue.

We should find a way to test this flow without needing the PR to be merged. That could look like changing the trigger on the flow and using only-labels to target a specific test label that we can create so we only comment on/close the test PR. Let me know if you want to try this and I can make the test label.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@realrajaryan pointed out to me that there's an issue on actions/stale where issues: write was required even when only dealing with PRs here. The last comment on that issue mentions that someone was still hitting it in 2024, so it's possible that this is no longer an issue.

We should find a way to test this flow without needing the PR to be merged. That could look like changing the trigger on the flow and using only-labels to target a specific test label that we can create so we only comment on/close the test PR. Let me know if you want to try this and I can make the test label.

sure we can give it a try

stale-pr-label: 'stale'

exempt-pr-labels: 'security,critical,dependencies'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these labels don't exist

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.

3 participants