RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes
Zhao Song
zsong at openjdk.org
Tue Jun 13 18:39:07 UTC 2023
On Tue, 13 Jun 2023 17:49:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 189:
>>
>>> 187: .map(HostedBranch::name)
>>> 188: .filter(name -> !name.startsWith("pr/"))
>>> 189: .toList();
>>
>> Currently, fetching all existing branches is the main overhead in this feature. It takes about 2s for JDK repo. If this overhead is not acceptable, the other way to solve this is store the branches in bot config.
>
> I assume this is taking a long time in mainline due to all the pr branches. We also have several update repositories (internally) with a lot of branches. With the future move to branched development in mainline, there will be even more in the main jdk repo. Those will not be filtered out either, so will add more rounds in the loop fetching .jcheck/conf below.
>
> I don't think fetching all branches and checking them for .jcheck/conf is a good idea. Instead I think we should keep a `Map` of branch names to set of PR IDs. Then we only need to iterate over the known targeted branches when looking for .jcheck/conf changes.
>
> To maintain the map, look at every PR found by the poller, if it's open, add it to the set for the branch, if it's closed, remove it. The poller will return all open PRs in the first round, so at that point we know it's up to date. After that it will catch all updates to all PRs, so we know we will catch when a PR is closed and get it removed from the map.
>
> Both GitHub and GitLab support querying for pull requests that target a specific branch, so when we get a hit on .jcheck/conf, we can fetch just the relevant pull requests. (In GitHub it's called `base`)
Yes, it will be much better. No extra overhead will be added.
-------------
PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228549811
More information about the skara-dev
mailing list