Automatically close draft PRs after a period of inactivity

[andrross]

Is your feature request related to a problem? Please describe.
We currently have 33 open draft PRs, with the oldest ones over a year old and no recent activity. It's great to iterate on a draft or seek feedback on a rough prototype, but drafts should either be promoted to a real PR with an intent to be merged, or closed (possibly to live on as a working branch in a user fork until the code is ready for review) after some relatively brief period.

Describe the solution you'd like
Automatically close draft PRs after a set period of inactivity. Closing is a non-destructive action and can be reversed simply by reopening the PR. A quick duckduckgo search found a GitHub action to automate this: https://github.com/marketplace/actions/draft-pr-closer. There may be other options as well.

Describe alternatives you've considered
Do nothing and leave the draft PRs open until someone takes action.

/cc @anasalkouz @mch2

[dblock]

I like this. I think you can raise a (draft :) PR for this / get enough maintainers to say yes?

[kotwanikunal]

I like this. I think you can raise a (draft :) PR for this / get enough maintainers to say yes?

I raised a (draft) PR for it - #8176
The workflow first marks the PR as stale, closes on no activity for 5 days.
Since closing the PR can be reversed, why not make it happen even for other PRs which are inactive.
The author can reopen or comment if needed, helping with the overall health of the repo.

In future, we can also utilize this with issues. The action in the draft PR (#8176) provides a ton of options like excluding assigned issues and PRs, label exclusion/inclusion - https://github.com/marketplace/actions/close-stale-issues.
It's also featured in the GH samples -https://docs.github.com/en/actions/managing-issues-and-pull-requests/closing-inactive-issues

[andrross]

@kotwanikunal Just missed your comment, but I created a PR as well :) To answer your question, I don't think we need to consider the "draft" status and can just label and close PRs based on a period of inactivity.

[anasalkouz]

Shall we do the same logic for PRs that are failing gradle check and have been idle for a while?
Currently: we have 63 PRs with status:failure

[kotwanikunal]

Shall we do the same logic for PRs that are failing gradle check and have been idle for a while? Currently: we have 63 PRs with status:failure

This workflow is for all the PRs in the repo. Any PR that is idle for a while will be labeled and then closed within the thresholds specified (30 days for stale label, 7 days post that for closure)

[anasalkouz]

Yeah, that make sense. The implemented logic is generic and cover all cases. Thanks Kunal for the clarification.

[andrross]

So it seems like this worked, sort of? https://github.com/opensearch-project/OpenSearch/pulls?q=is%3Apr+is%3Aopen+label%3Astalled

It labelled 6 PRs as stalled. But taking a random example, #6336 was last updated in February as far as I can tell but it did not get labelled.

[kotwanikunal]

So it seems like this worked, sort of? https://github.com/opensearch-project/OpenSearch/pulls?q=is%3Apr+is%3Aopen+label%3Astalled

It labelled 6 PRs as stalled. But taking a random example, #6336 was last updated in February as far as I can tell but it did not get labelled.

I think we might need to configure the max operations limit - https://github.com/marketplace/actions/close-stale-issues#operations-per-run
Also, I think it makes calls to the fetch issues + PRs - which is why we see a random number of 6 operations.
I think it will scan over things eventually over the next 42~ish days (1250 issues/30 ops a day) based on the current config (provided it keeps track of the issues it did scan and not tag)

[anasalkouz]

Seem the workflow is working as expected, we have 13 staled PRs closed so far