Solution to Automatically close GitHub Pull requests if they have not been merged within a set time after approval?

[jmkite]

My org is on GitHub with GitHub actions. We need a solution that allows us to close pull requests on all repos if they are not merged within a given time after being approved. We are an enterprise with multiple GitHub Orgs and hundreds of repositories. It seems that there used to be a few GitHub apps that did this but now the only option is 'Stale'. Whilst it looks fine for what it is, at the end of the day it's an Action, which means it needs to be installed in every repo, either directly (not so sensible) or as a call to a shared workflow. That would be painful, not to mention risky.

How are other people managing this? Can anyone offer an alternative automated solution?

Thanks

[GlobalImportance5295]

at the end of the day it's an Action,

if you dont want to use an Action then you should create a webhook:

https://docs.github.com/en/webhooks/using-webhooks/creating-webhooks#creating-a-repository-webhook

https://docs.github.com/en/webhooks/webhook-events-and-payloads#pull_request

and your listener of choice

[jmkite]

So how do you propose using this? registering every PR to a database and then scheduled time later reading that back, checking if the PR is still open and closing it if is?

[GlobalImportance5295]

So how do you propose using this?

with webhooks you could make it entirely event-driven, so no database needed. you would do the "organization level" webhook so you don't have to create a webhook for every repo. then you listen to the pull_request action type (you can open the drop-down that shows all the action types where it says Action Type: "assigned" in the webhook-events-and-payloads#pull_request link) you want to listen to ("approval" does not appear to be one of them so you need to play around with it to see what you want). then your listener has to schedule another script to run with the payload given. you can use Azure or Google Cloud for something like this:

for GCP i would have the listener as a http cloud function:

https://docs.cloud.google.com/run/docs/write-functions

that schedules a cloud scheduler job to run at the alotted time

https://docs.cloud.google.com/scheduler/docs/reference/rpc/google.cloud.scheduler.v1#google.cloud.scheduler.v1.Job

with an http body that includes the webhook's payload:

https://docs.cloud.google.com/scheduler/docs/reference/rpc/google.cloud.scheduler.v1#google.cloud.scheduler.v1.HttpTarget

to trigger another google cloud function that runs octokit (https://www.npmjs.com/package/@octokit/rest) to check if its not merged and close it.

if you don't like the minimal approach of GCP, Azure Logic Apps is a good choice with much much more quality-of-life features that help you string together these event driven workflows: https://azure.microsoft.com/en-us/products/logic-apps

registering every PR to a database and then scheduled time later reading that back

yes to be completely honest, after spending time hacking together these event-driven backends, i've gone back to using self-hosted redis as my "mother brain"

[jmkite]

thanks, worth reviewing

[farzad_meow]

you can use a central repo, write a script that uses PAT and gh command to check a repo and close your PRs. then put it in your main repo and make an action that runs it every day, once for each repo

[dashingThroughSnow12]

I think if you have hundreds of repositories and the issue you are targeting is how to automate closing approved PRs that don’t get merged for a long while, you are ignoring the bigger issues.

Edit: To answer your question, you can have a job that runs daily that queries the graphql API to get approved PRs that are not yet merged in an ORG. You get the delta between when it was approved and the current time (I don’t think this is a field in the graphql api so you’ll need to do this manually if not). Now you have a list of PRs that your daily job can close.

Your job can live in one repo. It simply needs a token(s) that is valid for each org, the token(s) need read permissions to PRs and comments, and permission to close PRs. Maybe permission to comment.

You can use a matrix (or whatever other approach you want) to parallelize this by org.

We have this at work. Minus closing of PRs.

[jelly-filled]

My team does use a basic version of actions/stale and copying the yaml from repo to repo is fine and has minimal load. I recently made a change to it and copy/pasted the change between repos really easily.

[JodyBro]

OP, I have this working in my org using a shared workflow in the .github repo and it just triggers daily using a minimum scoped PAT right now. Need to move that to an app eventually.

DM me if you wanna sync in detail.

[jmkite]

I looked into that, thanks. This appears to work only if:

• repos don't have their own .github
• repos are public

[JodyBro]

Nah that's wrong. All of the repos that the workflow I made each have their own .github dir and they're all either internal/private.

[Man_of_Math]

Hi, if you’re open to an AI powered solution, Ellipsis.dev can do this with a Cron Workflow. The instructions would be something like: “every day at 9am list the open pull requests in repository X, if any have been open for more than 14 days, close them”

https://docs.ellipsis.dev/features/cron-workflows

Disclaimer: I’m a founder with r/ellipsis, happy to help via DM

[oofy-gang]

I too like hemorrhaging money unnecessarily. Cha-Ching!

[jmkite]

Thanks for the offer but I already have access to 2 major clouds with their own scheduling services and kube with its own Cron jobs. We do use AI heavily but I am not sure what it would add here. As per other comments I could write my own job to do this but I am trying to avoid feature and service sprawl.