RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes

[Erik Joelsson]

On Mon, 12 Jun 2023 23:26:53 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this."
> 
> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr.
> 
> In this patch,
> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches).
> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated.
> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1338:

> 1336:             // Calculate current metadata to avoid unnecessary future checks
> 1337:             var metadata = workItem.getMetadata(workItem.getPRMetadata(censusInstance, title, updatedBody, pr.comments(), activeReviews,
> 1338:                     newLabels, pr.targetRef(), pr.isDraft(), pr.targetRefJCheckConf()), workItem.getIssueMetadata(updatedBody), expiresIn);

The .jcheck/conf file is already read when creating the `CensusInstance` (and may sometimes even be overridden and located in another repository). I think we should store the raw .jcheck/conf string in `LimitedCensusInstance` and get it from there in the rest of `CheckWorkItem`/`CheckRun`.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 197:

> 195:             }
> 196:             var currConf = currConfOpt.get();
> 197:             if (!jCheckConfMap.containsKey(targetRef) || !jCheckConfMap.get(targetRef).equals(currConf)) {

If we don't have a record of .jcheck/conf yet, then we should not schedule a WorkItem. The poller will take care of this in the first round. This logic only needs to worry about changes.

-------------

PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228512493
PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228499869