Feature request: Limit the number of open PRs

[abuggin]

One goal: keep the number of PRs open per repo small Two reasons:

1. build takes long and it takes resources that impacts pipeline for other services
2. stale PRs are not useful (they can't be merged)

Right now, we have:

• updates.limit = N
  • that provides a limit scoped to each run (doesn't consider already open PRs against that limit)

  • Scala Steward will only create or update n PRs each time it runs

• updatePullRequests = "always" | "on-conflicts" | "never"
  • that updates already open PRs
• pullRequests.frequency

  • allows to control how often or when Scala Steward is allowed to create pull requests

So we introduced a updates.limit = 5 and updatePullRequests = "never" and pullRequests.frequency=@asap (but it is actually scheduled as a chron job in self-hosted). Unfortunately it doesn't gives us what we really want:

• a small number of PR are added every half-hour
• they don't get updated

What we really want is a small number of PR that are updated on conflicts and no other PRs are opened until those are merged. To get that I think we need another setting:

updates.global.limit = N (or something along the line) that will offer these behaviours:

• Scala Steward will not create PRs because there are already N PRs open. (maybe log a warning?)

• Scala Steward will keep updating those open PRs (if there are conflicts/necessary according to updatePullRequests setting)

[fthomas]

That sounds like a useful feature request to me.

[alifirat]

Hey @abuggin @fthomas any plan to work on this one ?

Maybe I can have a look it :-)

[mzuehlke]

@alifirat we are happy about any contributing PR. Give it a try

[alifirat]

@mzuehlke I was wondering one thing: how you can identify the PRs opened by Steward on a repository ? I think to the private repositories for example and in my use case, I'v a dedicated user to let Steward create the PR but so I imagine that using labels or metadata can help to identify the number of open PRs. Any idea ?

[abuggin]

@alifirat An option that came to mind: you can add a configuration key for specifying the Steward Github username so that you can filter pr opened by that username by matching the author to that configured username.

[alifirat]

Ok, what's the best process to contribute ? Open a PR directly or started a branch that refers this issue ?

[alifirat]

Hey @mzuehlke @abuggin I'm deep diving a bit in the code and I was wondering where this feature take place. I see two locations that are interesting:

1. PruningAlg : it can be a new step since we can remove some PRs if the threshold is reached
2. NurtureAlg: we have all the PRs to create in our hands and we can add a new step to remove some PRs if the threshold is reached.

It looks like the first option makes more sense but I didn't have access to the gitAlg in this class while I have it in the second option. Can you advice me a bit ?

Also, I think we should careful at which step we should apply this check: to me, it should happens when we find all the updates that should be ignore otherwise it's going to create inconsistency in the checks. What do you think ?

Update 1: PruningAlg seems the best location since if I have access to PullRequestRepository that already have a function called getObsoleteOpenPullRequests from which I can inspiration and make it even simpler since it just want to count the number of opens PR.