RFR: 1710: CommitCommandWorkItem always fetches Commit

Magnus Ihse Bursie ihse at openjdk.org
Wed Dec 14 13:03:37 UTC 2022

On Tue, 6 Dec 2022 19:05:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> During bot restart, quite a few CommitCommandWorkItems are spawned. Most of them will discover that nothing needs to be done. One of the first things done in the run method is fetching the commit from the remote repository. The Commit instance will always be created with the full set of diffs for the commit. In certain cases, where commits are very large, this can take considerable time. Specifically in the jfx repos, there are examples where the REST request is split into 147 pages. (e.g. https://github.com/openjdk/jfx11u/commit/4bd6877dbd46e37f6774c50dcdc98a8a1ab41214) The way these WorkItems are spawned on startup, most of these gigantic commits will be included for a long time. The Commit instance isn't needed to figure out if a new command is present, just the comments are. This means we can move this query to after we have established that a command is to be executed.
> To further reduce overhead when fetching commits from remote repositories, I'm also making the inclusion of the "parentDiffs" optional. Of all the uses of `HostedRepository::commit`, there is currently only one that actually needs the diffs (BackportCommand). This will require the caller to be mindful of the state of the returned `Commit` object, especially when sending it other consumers, but I believe it's worth it to reduce unnecessary load on the system.
> This also affects `Forge::search`, where there is one other use where the diffs are used (when evaluating if a backport is clean).



Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/skara/pull/1436

More information about the skara-dev mailing list