From gli at openjdk.org Sat Jul 9 06:25:57 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Jul 2022 06:25:57 GMT Subject: RFR: 1497: build: update JUnit to 5.8.2 completely Message-ID: Hi all, This patch updates JUnit to 5.8.2 completely. The previous patch [1] didn't update file `test/build.gradle`. Thanks for taking the time to review. Best Regards, -- Guoxiong [1] https://github.com/openjdk/skara/commit/abe48a5d ------------- Commit messages: - SKARA-1497 Changes: https://git.openjdk.org/skara/pull/1340/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1340&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1497 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1340.diff Fetch: git fetch https://git.openjdk.org/skara pull/1340/head:pull/1340 PR: https://git.openjdk.org/skara/pull/1340 From ihse at openjdk.org Sat Jul 9 07:08:43 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 9 Jul 2022 07:08:43 GMT Subject: RFR: 1497: build: update JUnit to 5.8.2 completely In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 06:21:12 GMT, Guoxiong Li wrote: > Hi all, > > This patch updates JUnit to 5.8.2 completely. The previous patch [1] didn't the update file `test/build.gradle`. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://github.com/openjdk/skara/commit/abe48a5d Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1340 From gli at openjdk.org Sat Jul 9 16:18:27 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Jul 2022 16:18:27 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage Message-ID: Hi all, This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. But in detail, this patch has the following feature or solves the following issues: - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. Although it seems that many features are not related to SKARA-1495, I put them together as an enhance of the PullRequestBot. Best Regards, -- Guoxiong ------------- Commit messages: - Fix reply message. - SKARA-1495 Changes: https://git.openjdk.org/skara/pull/1341/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1495 Stats: 153 lines in 13 files changed: 102 ins; 31 del; 20 mod Patch: https://git.openjdk.org/skara/pull/1341.diff Fetch: git fetch https://git.openjdk.org/skara pull/1341/head:pull/1341 PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Sat Jul 9 16:29:24 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Jul 2022 16:29:24 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. > > But in detail, this patch has the following feature or solves the following issues: > > - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. > - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. > - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. > - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. > > Although it seems that many features are not related to SKARA-1495, I put them together as an enhance of the PullRequestBot. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix NPE. ------------- Changes: - all: https://git.openjdk.org/skara/pull/1341/files - new: https://git.openjdk.org/skara/pull/1341/files/2a1c4908..49d5ef51 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1341.diff Fetch: git fetch https://git.openjdk.org/skara pull/1341/head:pull/1341 PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Sat Jul 9 16:29:56 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Jul 2022 16:29:56 GMT Subject: RFR: 1497: build: update JUnit to 5.8.2 completely In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 07:06:36 GMT, Magnus Ihse Bursie wrote: >> Hi all, >> >> This patch updates JUnit to 5.8.2 completely. The previous patch [1] didn't update the file `test/build.gradle`. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong >> >> [1] https://github.com/openjdk/skara/commit/abe48a5d > > Marked as reviewed by ihse (Reviewer). @magicus Thanks for the review. Integrating. ------------- PR: https://git.openjdk.org/skara/pull/1340 From gli at openjdk.org Sat Jul 9 16:29:57 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 9 Jul 2022 16:29:57 GMT Subject: Integrated: 1497: build: update JUnit to 5.8.2 completely In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 06:21:12 GMT, Guoxiong Li wrote: > Hi all, > > This patch updates JUnit to 5.8.2 completely. The previous patch [1] didn't update the file `test/build.gradle`. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > [1] https://github.com/openjdk/skara/commit/abe48a5d This pull request has now been integrated. Changeset: 281ff1b9 Author: Guoxiong Li URL: https://git.openjdk.org/skara/commit/281ff1b91eb6881cbbbaf6a634f11c30ddafe0ed Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 1497: build: update JUnit to 5.8.2 completely Reviewed-by: ihse ------------- PR: https://git.openjdk.org/skara/pull/1340 From ihse at openjdk.org Sat Jul 9 17:08:32 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Sat, 9 Jul 2022 17:08:32 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 16:29:24 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. >> >> But in detail, this patch has the following feature or solves the following issues: >> >> - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. >> - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. >> - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. >> - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. >> >> Although it seems that many features are not related to SKARA-1495, I put them together as an enhance of the PullRequestBot. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix NPE. Thank you for tackling this PR. Both Erik and I are on vacation right now, and you'll have to wait to get a full review. My main worry here is that there were some underlying reason for not going this route with `/backport` on the PRs directly, that is not obvious to me, and that may make this change unsuitable. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Wed Jul 27 14:41:40 2022 From: gli at openjdk.org (Guoxiong Li) Date: Wed, 27 Jul 2022 14:41:40 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: Message-ID: <6wPLhS_sg4vMMCxXHHe6uzB1X1QdzmHXYrzDUAGNdRs=.cc7dc9fe-9593-435e-a9e7-eb37b4c41858@github.com> On Sat, 9 Jul 2022 17:05:30 GMT, Magnus Ihse Bursie wrote: > Thank you for tackling this PR. Both Erik and I are on vacation right now, and you'll have to wait to get a full review. > > My main worry here is that there were some underlying reason for not going this route with `/backport` on the PRs directly, that is not obvious to me, and that may make this change unsuitable. Thanks for the reply. Still waiting for comment or review. ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Wed Jul 27 18:59:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 27 Jul 2022 18:59:58 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 16:29:24 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. >> >> But in detail, this patch has the following feature or solves the following issues: >> >> - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. >> - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. >> - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. >> - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. >> >> Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix NPE. bots/notify/src/main/java/org/openjdk/skara/bots/notify/PullRequestWorkItem.java line 187: > 185: > 186: var issues = parseIssues(); > 187: var commit = integratorId != null ? pr.findIntegratedCommitHash(List.of(integratorId)).orElse(null) : null; Consider keeping the resultingCommitHash() method with the current signature and have it wrap the new pr.findIntegratedCommitHash(), doing the null checks and conversions there instead. I think that will make the code more readable. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 58: > 56: public void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, > 57: CommandInvocation command, List allComments, PrintWriter reply) { > 58: reply.println("The command `backport` can not be used in a pull request that has not yet been integrated."); Shouldn't the message here be the one suggested in the Bug? "(!) You cannot issue `/backport` on a pull request. Instead, give that command on the actual commit you want to backport." bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommandExtractor.java line 55: > 53: } > 54: var command = commandMatcher.group(1).toLowerCase(); > 55: var handler = commitCommandFirst ? CommitCommandWorkItem.commandHandlers.get(command) : PullRequestCommandWorkItem.commandHandlers.get(command); What are you trying to achieve with the commitCommandFirst boolean? In what situation would it be wrong to just use one unified list? bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 43: > 41: private static final Pattern commandReplyPattern = Pattern.compile(""); > 42: > 43: static final Map commandHandlers = Map.ofEntries( Instead of making these package private and adding the convoluted logic in extractCommands, can't we just add BackportCommand to the commandHandlers for PullRequestWorkItem? It seems like the original author mixed two ways of separating commands between PRs and commits, both through these handler lists, and through the allowedIn* methods. If we really want to improve all the error messages, then all commands should be added to both lists, or maybe the lists should be unified into one. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 174: > 172: if (isCommit) { > 173: if (handler.get().allowedInCommit()) { > 174: var hash = pr.findIntegratedCommitHash(); It's worth noting that this will trigger a new `comments()` call to the forge instead of reusing the existing list of comments. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 205: > 203: printer.print("The command `"); > 204: printer.print(command.name()); > 205: printer.println("` can not be used in pull requests. Please try to use this command on the commit."); I don't think we need to suggest using the command on a commit in the general case. Suggestion: printer.println("` cannot be used in pull requests."); forge/src/main/java/org/openjdk/skara/forge/PullRequest.java line 189: > 187: > 188: default Optional findIntegratedCommitHash(List userIds) { > 189: Pattern pushedPattern = Pattern.compile("Pushed as commit ([a-f0-9]{40})\\."); If you are moving this pattern from the bots modules to this class, then I think you should also move the comment logic from IntegrateCommand here so that both the creation and parsing of this kind of comment is handled at the same level. It seems bad to have PullRequest know about what special comments the IntegrateCommand happens to add. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 13:09:24 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 13:09:24 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. > > But in detail, this patch has the following feature or solves the following issues: > > - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. > - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. > - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. > - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. > > Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Unify two command handlers. - Fix message. Add method resultingCommitHash. ------------- Changes: - all: https://git.openjdk.org/skara/pull/1341/files - new: https://git.openjdk.org/skara/pull/1341/files/49d5ef51..1fe72a16 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=01-02 Stats: 161 lines in 5 files changed: 66 ins; 86 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1341.diff Fetch: git fetch https://git.openjdk.org/skara pull/1341/head:pull/1341 PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 13:09:26 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 13:09:26 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: Message-ID: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> On Wed, 27 Jul 2022 13:35:38 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix NPE. > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/PullRequestWorkItem.java line 187: > >> 185: >> 186: var issues = parseIssues(); >> 187: var commit = integratorId != null ? pr.findIntegratedCommitHash(List.of(integratorId)).orElse(null) : null; > > Consider keeping the resultingCommitHash() method with the current signature and have it wrap the new pr.findIntegratedCommitHash(), doing the null checks and conversions there instead. I think that will make the code more readable. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 58: > >> 56: public void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, >> 57: CommandInvocation command, List allComments, PrintWriter reply) { >> 58: reply.println("The command `backport` can not be used in a pull request that has not yet been integrated."); > > Shouldn't the message here be the one suggested in the Bug? > > "(!) You cannot issue `/backport` on a pull request. Instead, give that command on the actual commit you want to backport." I want the`/backport` command can be used in the PRs which hava been integrated. So the message `You cannot issue /backport on a pull request` seems not accurate. But the current message seems not accurate too. Looking for a better description and your idea. > In what situation would it be wrong to just use one unified list? The only one situation I concern about is the `help` command. But after second thought, it looks good. So I unified them. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 43: > >> 41: private static final Pattern commandReplyPattern = Pattern.compile(""); >> 42: >> 43: static final Map commandHandlers = Map.ofEntries( > > Instead of making these package private and adding the convoluted logic in extractCommands, can't we just add BackportCommand to the commandHandlers for PullRequestWorkItem? > > It seems like the original author mixed two ways of separating commands between PRs and commits, both through these handler lists, and through the allowedIn* methods. If we really want to improve all the error messages, then all commands should be added to both lists, or maybe the lists should be unified into one. I unified these two lists into one and put it in class `CommandExtractor`. All the tests in PR bot passed locally. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 174: > >> 172: if (isCommit) { >> 173: if (handler.get().allowedInCommit()) { >> 174: var hash = pr.findIntegratedCommitHash(); > > It's worth noting that this will trigger a new `comments()` call to the forge instead of reusing the existing list of comments. Yes, it is a tradeoff between code concision and the running time. If we find the code becomes slower in the future and want to optimize it, this is a good place to optimize. But now we can keep it because we want to refactor the method in this PR. And the method `pr.findIntegratedCommitHash` always get the newest comments so it may avoid some issues that the `Pushed as ...` comment is added during processing command. But I am not really know whether this situation would happen. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 205: > >> 203: printer.print("The command `"); >> 204: printer.print(command.name()); >> 205: printer.println("` can not be used in pull requests. Please try to use this command on the commit."); > > I don't think we need to suggest using the command on a commit in the general case. > > Suggestion: > > printer.println("` cannot be used in pull requests."); Fixed. > forge/src/main/java/org/openjdk/skara/forge/PullRequest.java line 189: > >> 187: >> 188: default Optional findIntegratedCommitHash(List userIds) { >> 189: Pattern pushedPattern = Pattern.compile("Pushed as commit ([a-f0-9]{40})\\."); > > If you are moving this pattern from the bots modules to this class, then I think you should also move the comment logic from IntegrateCommand here so that both the creation and parsing of this kind of comment is handled at the same level. It seems bad to have PullRequest know about what special comments the IntegrateCommand happens to add. What about adding a parameter like `Pattern commitComment` to the method `findIntegratedCommitHash`? ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 13:18:15 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 13:18:15 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: On Thu, 28 Jul 2022 13:04:32 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 58: >> >>> 56: public void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, >>> 57: CommandInvocation command, List allComments, PrintWriter reply) { >>> 58: reply.println("The command `backport` can not be used in a pull request that has not yet been integrated."); >> >> Shouldn't the message here be the one suggested in the Bug? >> >> "(!) You cannot issue `/backport` on a pull request. Instead, give that command on the actual commit you want to backport." > > I want the`/backport` command can be used in the PRs which hava been integrated. So the message `You cannot issue /backport on a pull request` seems not accurate. But the current message seems not accurate too. Looking for a better description and your idea. Additional information: When the PR has been integrated and the `backport` command is used in this integrated PR, the another `handle` method instead of this method will be invoked so that the `backport` command can be processed. ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Thu Jul 28 18:54:12 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 18:54:12 GMT Subject: RFR: 1514: Add metrics for mailing list archive polling Message-ID: This patch adds a new metrics counter tracking the polling rate for the MailmanListReader. I would like to get this live before trying to reduce the polling rate in SKARA-1513, so that any improvements can be accurately measured. ------------- Commit messages: - SKARA-1514 Changes: https://git.openjdk.org/skara/pull/1342/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1342&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1514 Stats: 8 lines in 3 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1342.diff Fetch: git fetch https://git.openjdk.org/skara pull/1342/head:pull/1342 PR: https://git.openjdk.org/skara/pull/1342 From erikj at openjdk.org Thu Jul 28 19:46:00 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 19:46:00 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: On Thu, 28 Jul 2022 13:15:01 GMT, Guoxiong Li wrote: >> I want the`/backport` command can be used in the PRs which hava been integrated. So the message `You cannot issue /backport on a pull request` seems not accurate. But the current message seems not accurate too. Looking for a better description and your idea. > > Additional information: When the PR has been integrated and the `backport` command is used in this integrated PR, the another `handle` method instead of this method will be invoked so that the `backport` command can be processed. But BackportCommand doesn't yet support running on a PR. That's still a feature that would need to be implemented. ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Thu Jul 28 19:46:01 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 19:46:01 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: On Thu, 28 Jul 2022 13:04:07 GMT, Guoxiong Li wrote: >> forge/src/main/java/org/openjdk/skara/forge/PullRequest.java line 189: >> >>> 187: >>> 188: default Optional findIntegratedCommitHash(List userIds) { >>> 189: Pattern pushedPattern = Pattern.compile("Pushed as commit ([a-f0-9]{40})\\."); >> >> If you are moving this pattern from the bots modules to this class, then I think you should also move the comment logic from IntegrateCommand here so that both the creation and parsing of this kind of comment is handled at the same level. It seems bad to have PullRequest know about what special comments the IntegrateCommand happens to add. > > What about adding a parameter like `Pattern commitComment` to the method `findIntegratedCommitHash`? The drawback of that is that we then need to have a copy of the pattern everywhere we call the method. I think it's better to have something like a static method on PullRequest like `String commitHashMessage(Hash)`, which takes a hash and returns a String with the formatted message. IntegrateCommand can use that to format the relevant part of the comment. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 20:18:18 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 20:18:18 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: On Thu, 28 Jul 2022 18:54:00 GMT, Erik Joelsson wrote: >> Additional information: When the PR has been integrated and the `backport` command is used in this integrated PR, the another `handle` method instead of this method will be invoked so that the `backport` command can be processed. > > But BackportCommand doesn't yet support running on a PR. That's still a feature that would need to be implemented. In this patch, it can be used at PRs which had been integrated. This is a main feature of this patch. ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Thu Jul 28 20:45:55 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 28 Jul 2022 20:45:55 GMT Subject: RFR: 1495: /backport on PRs instead of commits should inform of proper usage [v2] In-Reply-To: References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: <8slGnCKUtZXyyL6ix50Qvvc4LUH1zEc5AF04UcTROr4=.a83285ec-a582-4c18-b630-e446b889d797@github.com> On Thu, 28 Jul 2022 20:16:10 GMT, Guoxiong Li wrote: >> But BackportCommand doesn't yet support running on a PR. That's still a feature that would need to be implemented. > > In this patch, it can be used at PRs which had been integrated. This is a main feature of this patch. Oh, I see now that PullRequestCommandWorkItem will call the handle method for commit if the PR has been integrated. That was rather surprising behavior. In that case, please align the reply with the one in PullRequestCommandWorkItem: printer.print("The command `"); printer.print(command.name()); printer.println("` can only be used in a pull request that has been integrated."); Also, if that's the case, please change the bug and PR title to make this clear. That's the main feature being added here. ------------- PR: https://git.openjdk.org/skara/pull/1341 From ihse at openjdk.org Thu Jul 28 22:30:51 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 28 Jul 2022 22:30:51 GMT Subject: RFR: 1514: Add metrics for mailing list archive polling In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 18:48:25 GMT, Erik Joelsson wrote: > This patch adds a new metrics counter tracking the polling rate for the MailmanListReader. I would like to get this live before trying to reduce the polling rate in SKARA-1513, so that any improvements can be accurately measured. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1342 From gli at openjdk.org Thu Jul 28 22:46:59 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 22:46:59 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v4] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. > > But in detail, this patch has the following feature or solves the following issues: > > - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. > - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. > - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. > - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. > > Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Add method PullRequest::commitHashMessage - Fix message in BackportCommand. ------------- Changes: - all: https://git.openjdk.org/skara/pull/1341/files - new: https://git.openjdk.org/skara/pull/1341/files/1fe72a16..9fe6447f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=02-03 Stats: 7 lines in 4 files changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1341.diff Fetch: git fetch https://git.openjdk.org/skara pull/1341/head:pull/1341 PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 22:47:00 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 22:47:00 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v2] In-Reply-To: <8slGnCKUtZXyyL6ix50Qvvc4LUH1zEc5AF04UcTROr4=.a83285ec-a582-4c18-b630-e446b889d797@github.com> References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> <8slGnCKUtZXyyL6ix50Qvvc4LUH1zEc5AF04UcTROr4=.a83285ec-a582-4c18-b630-e446b889d797@github.com> Message-ID: On Thu, 28 Jul 2022 20:41:36 GMT, Erik Joelsson wrote: > please align the reply with the one in PullRequestCommandWorkItem Fixed. > Also, if that's the case, please change the bug and PR title to make this clear. That's the main feature being added here. I revised the title just now. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Thu Jul 28 22:47:00 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 28 Jul 2022 22:47:00 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v2] In-Reply-To: References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: <5zF1xWXDlB9jBNvji0UQR1_izj8_L9bkg3ZrsdpCVGU=.f85ca9d7-6425-4a9b-969e-13ca3d1b63e7@github.com> On Thu, 28 Jul 2022 19:42:47 GMT, Erik Joelsson wrote: >> What about adding a parameter like `Pattern commitComment` to the method `findIntegratedCommitHash`? > > The drawback of that is that we then need to have a copy of the pattern everywhere we call the method. I think it's better to have something like a static method on PullRequest like `String commitHashMessage(Hash)`, which takes a hash and returns a String with the formatted message. IntegrateCommand can use that to format the relevant part of the comment. Maybe someone has another more elegant way to solve this issue. But now I can't find such way, so it is good to adopt your idea now. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Fri Jul 29 05:29:54 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 29 Jul 2022 05:29:54 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v5] In-Reply-To: References: Message-ID: > Hi all, > > This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. > > But in detail, this patch has the following feature or solves the following issues: > > - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. > - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. > - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. > - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. > > Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Add comment to the method commitHashMessage. ------------- Changes: - all: https://git.openjdk.org/skara/pull/1341/files - new: https://git.openjdk.org/skara/pull/1341/files/9fe6447f..97ed354d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1341&range=03-04 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1341.diff Fetch: git fetch https://git.openjdk.org/skara pull/1341/head:pull/1341 PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Fri Jul 29 12:34:45 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 12:34:45 GMT Subject: Integrated: 1514: Add metrics for mailing list archive polling In-Reply-To: References: Message-ID: On Thu, 28 Jul 2022 18:48:25 GMT, Erik Joelsson wrote: > This patch adds a new metrics counter tracking the polling rate for the MailmanListReader. I would like to get this live before trying to reduce the polling rate in SKARA-1513, so that any improvements can be accurately measured. This pull request has now been integrated. Changeset: 8e68f8b9 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/8e68f8b9108080d612b14547a0c5827bf35c4602 Stats: 8 lines in 3 files changed: 8 ins; 0 del; 0 mod 1514: Add metrics for mailing list archive polling Reviewed-by: ihse ------------- PR: https://git.openjdk.org/skara/pull/1342 From erikj at openjdk.org Fri Jul 29 12:48:10 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 12:48:10 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v2] In-Reply-To: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> Message-ID: <8KU_NakQlfZL9ml_ceMnGVxkPSmqeWFm4X6nD_NZIkk=.f52410ef-79a8-4fb8-939c-0f6e9340404f@github.com> On Thu, 28 Jul 2022 13:05:11 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommandExtractor.java line 55: >> >>> 53: } >>> 54: var command = commandMatcher.group(1).toLowerCase(); >>> 55: var handler = commitCommandFirst ? CommitCommandWorkItem.commandHandlers.get(command) : PullRequestCommandWorkItem.commandHandlers.get(command); >> >> What are you trying to achieve with the commitCommandFirst boolean? In what situation would it be wrong to just use one unified list? > >> In what situation would it be wrong to just use one unified list? > > The only one situation I concern about is the `help` command. But after second thought, it looks good. So I unified them. Hm, now I realize what you mean about the HelpCommand. If you invoke `/help` on a commit now, you get all the PR commands listed. That's not good. We still need some way of separating which commands should be listed for help with a commit and help with a PR. ------------- PR: https://git.openjdk.org/skara/pull/1341 From gli at openjdk.org Fri Jul 29 14:20:46 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 29 Jul 2022 14:20:46 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v2] In-Reply-To: <8KU_NakQlfZL9ml_ceMnGVxkPSmqeWFm4X6nD_NZIkk=.f52410ef-79a8-4fb8-939c-0f6e9340404f@github.com> References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> <8KU_NakQlfZL9ml_ceMnGVxkPSmqeWFm4X6nD_NZIkk=.f52410ef-79a8-4fb8-939c-0f6e9340404f@github.com> Message-ID: On Fri, 29 Jul 2022 12:45:05 GMT, Erik Joelsson wrote: >>> In what situation would it be wrong to just use one unified list? >> >> The only one situation I concern about is the `help` command. But after second thought, it looks good. So I unified them. > > Hm, now I realize what you mean about the HelpCommand. If you invoke `/help` on a commit now, you get all the PR commands listed. That's not good. We still need some way of separating which commands should be listed for help with a commit and help with a PR. > The only one situation I concern about is the help command. But after second thought, it looks good. So I unified them. In detail, the code logic of the master branch: 1. use `help` command on PR which has **not** been integrated the bot prints the commands which are **allowed in PR** and **the extranal PR command** 2. use `help` command on PR which **has been integrated** the bot prints the commands which are **allowed in commit** and **the extranal PR command** 3. use `help` command on a commit the bot prints the commands which are **allowed in commit** and **the extranal commit command** But the logic of this patch is: 1. use `help` command on PR which has **not** been integrated (unchanged) the bot prints the commands which are **allowed in PR** and **the extranal PR command** 2. use `help` command on PR which **has been integrated** or use `help` **command on a commit** the bot prints the commands which are **allowed in commit** and **the extranal commit command** So there is a little diffrence between the master branch and my patch. But the logic in my patch seems good. > Hm, now I realize what you mean about the HelpCommand. If you invoke `/help` on a commit now, you get all the PR commands listed. That's not good. We still need some way of separating which commands should be listed for help with a commit and help with a PR. >From your description, I think one among us misunderstood the code. Did I miss something? ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Fri Jul 29 17:02:19 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 17:02:19 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v5] In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 05:29:54 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. >> >> But in detail, this patch has the following feature or solves the following issues: >> >> - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. >> - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. >> - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. >> - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. >> >> Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Add comment to the method commitHashMessage. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Fri Jul 29 17:02:19 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 17:02:19 GMT Subject: RFR: 1495: /backport should be allowed in PRs which have been integrated [v2] In-Reply-To: References: <7XqhqwYHoTIKMG2xPlLhstqYbDRBNfBxlad3dQuGP1I=.5bfa46c1-af01-42b0-82c9-ad68aeef3e0a@github.com> <8KU_NakQlfZL9ml_ceMnGVxkPSmqeWFm4X6nD_NZIkk=.f52410ef-79a8-4fb8-939c-0f6e9340404f@github.com> Message-ID: On Fri, 29 Jul 2022 14:17:41 GMT, Guoxiong Li wrote: >> Hm, now I realize what you mean about the HelpCommand. If you invoke `/help` on a commit now, you get all the PR commands listed. That's not good. We still need some way of separating which commands should be listed for help with a commit and help with a PR. > >> The only one situation I concern about is the help command. But after second thought, it looks good. So I unified them. > > In detail, the code logic of the master branch: > > 1. use `help` command on PR which has **not** been integrated > > the bot prints the commands which are **allowed in PR** and **the extranal PR command** > > 2. use `help` command on PR which **has been integrated** > > the bot prints the commands which are **allowed in commit** and **the extranal PR command** > > 3. use `help` command on a commit > > the bot prints the commands which are **allowed in commit** and **the extranal commit command** > > But the logic of this patch is: > 1. use `help` command on PR which has **not** been integrated (unchanged) > > the bot prints the commands which are **allowed in PR** and **the extranal PR command** > > 2. use `help` command on PR which **has been integrated** or use `help` **command on a commit** > > the bot prints the commands which are **allowed in commit** and **the extranal commit command** > > So there is a little difference between the master branch and my patch. But the logic in my patch seems good. > >> Hm, now I realize what you mean about the HelpCommand. If you invoke `/help` on a commit now, you get all the PR commands listed. That's not good. We still need some way of separating which commands should be listed for help with a commit and help with a PR. > > From your description, I think one among us misunderstood the code. Did I miss something? You are right, I missed that you added filtering on allowedIn*. That was an elegant solution, thanks! ------------- PR: https://git.openjdk.org/skara/pull/1341 From erikj at openjdk.org Fri Jul 29 17:35:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 17:35:58 GMT Subject: RFR: 1513: Reduce polling of mailing list archives Message-ID: This patch changes the strategy used by the MailmanListReader for polling the mailman archives. The current implementation relies on the server supporting "etag" in order to trust any cached results. Recent testing has shown that etags aren't supported by mail.openjdk.org, which means no results are ever cached, we just keep spamming the mailman archives for the last 12 months over and over. My new implementation assumes that new emails will only ever appear in the current and previous months archives. (If this proves to be wrong, I still think that would be rare enough that it doesn't matter, as the full 12 months will be re-evaluated on bot restart.) So for anything older than the previous month, all successful (200) or non-existent (404) results will be cached and never re-queried. The reason mlbridge needs to query emails for up to a year back is that it needs to piece together conversations and trace them back to the original post in order to correctly identify the PR link associating the conversation with a certain PR. (It's possible that this could be made more efficient in a separate change.) The change itself is rather small, but in order to test it, I needed to expand functionality in the TestMailmanServer. The existing tests did not verify any calls to archives for months other than the current, so I needed to add support for actually handling that. I also moved the data to in memory storage in HashMaps instead of writing to temp files. My only worry here is that I messed up with the test so that it will start failing on certain days of the year. ------------- Commit messages: - SKARA-1513 Changes: https://git.openjdk.org/skara/pull/1343/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1343&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1513 Stats: 126 lines in 3 files changed: 110 ins; 6 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1343.diff Fetch: git fetch https://git.openjdk.org/skara pull/1343/head:pull/1343 PR: https://git.openjdk.org/skara/pull/1343 From gli at openjdk.org Fri Jul 29 18:27:09 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 29 Jul 2022 18:27:09 GMT Subject: Integrated: 1495: /backport should be allowed in PRs which have been integrated In-Reply-To: References: Message-ID: On Sat, 9 Jul 2022 16:14:21 GMT, Guoxiong Li wrote: > Hi all, > > This patch mainly solves the issue described at SKARA-1495 which makes the `backport` command be valid in a pull request which has been integrated. > > But in detail, this patch has the following feature or solves the following issues: > > - Currently, the commands of the pull request and the commands of the commit are not related and can't be known from each other. So when we use the commit commands, such as `tag`, in the pull request, the bot replies `Unknown command tag`. Actually, the bot should replies the message like `The command tag can not be used in pull requests. Please try to use this command on the commit`. The change is mainly at method `CommandExtractor::extractCommands`. > - Many places of the code use a duplicated method, named `resultingCommitHash`, this method could be put into class `PullRequest` to avoid the duplication. I refactor it in this patch. > - Now the `backport` command can not be used in pull requests. I revise the logic to let it available in a pull request which has been integrated, mainly removing the overrided method `allowedInPullRequest` of the class `BackportCommand`. > - The reason that these issues are not found before is that we hadn't tested all the branches of the code, especially the branches in methods `PullRequestCommandWorkItem::processCommand` and `CommitCommandWorkItem::processCommand`. So I add more test cases to test almost all the branches. And if the branch can't be tested, I add a comment to explain it. > > Although it seems that many features are not related to SKARA-1495, I put them together as an enhancement of the PullRequestBot. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 809dc978 Author: Guoxiong Li URL: https://git.openjdk.org/skara/commit/809dc978a107c65ae3b38c7d45d995eaf38e9980 Stats: 295 lines in 14 files changed: 168 ins; 110 del; 17 mod 1495: /backport should be allowed in PRs which have been integrated Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1341 From kcr at openjdk.org Fri Jul 29 18:47:01 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 29 Jul 2022 18:47:01 GMT Subject: RFR: 1513: Reduce polling of mailing list archives In-Reply-To: References: Message-ID: <3pgho_dQjZ-4bWun_vQhsbPnGcBUzWj8wh0mHXSSdZw=.82c50fff-64ba-45eb-ad90-aa08a0bfa67d@github.com> On Fri, 29 Jul 2022 17:31:23 GMT, Erik Joelsson wrote: > This patch changes the strategy used by the MailmanListReader for polling the mailman archives. The current implementation relies on the server supporting "etag" in order to trust any cached results. Recent testing has shown that etags aren't supported by mail.openjdk.org, which means no results are ever cached, we just keep spamming the mailman archives for the last 12 months over and over. > > My new implementation assumes that new emails will only ever appear in the current and previous months archives. (If this proves to be wrong, I still think that would be rare enough that it doesn't matter, as the full 12 months will be re-evaluated on bot restart.) So for anything older than the previous month, all successful (200) or non-existent (404) results will be cached and never re-queried. > > The reason mlbridge needs to query emails for up to a year back is that it needs to piece together conversations and trace them back to the original post in order to correctly identify the PR link associating the conversation with a certain PR. (It's possible that this could be made more efficient in a separate change.) > > The change itself is rather small, but in order to test it, I needed to expand functionality in the TestMailmanServer. The existing tests did not verify any calls to archives for months other than the current, so I needed to add support for actually handling that. I also moved the data to in memory storage in HashMaps instead of writing to temp files. > > My only worry here is that I messed up with the test so that it will start failing on certain days of the year. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1343 From erikj at openjdk.org Fri Jul 29 22:00:08 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 29 Jul 2022 22:00:08 GMT Subject: Integrated: 1513: Reduce polling of mailing list archives In-Reply-To: References: Message-ID: On Fri, 29 Jul 2022 17:31:23 GMT, Erik Joelsson wrote: > This patch changes the strategy used by the MailmanListReader for polling the mailman archives. The current implementation relies on the server supporting "etag" in order to trust any cached results. Recent testing has shown that etags aren't supported by mail.openjdk.org, which means no results are ever cached, we just keep spamming the mailman archives for the last 12 months over and over. > > My new implementation assumes that new emails will only ever appear in the current and previous months archives. (If this proves to be wrong, I still think that would be rare enough that it doesn't matter, as the full 12 months will be re-evaluated on bot restart.) So for anything older than the previous month, all successful (200) or non-existent (404) results will be cached and never re-queried. > > The reason mlbridge needs to query emails for up to a year back is that it needs to piece together conversations and trace them back to the original post in order to correctly identify the PR link associating the conversation with a certain PR. (It's possible that this could be made more efficient in a separate change.) > > The change itself is rather small, but in order to test it, I needed to expand functionality in the TestMailmanServer. The existing tests did not verify any calls to archives for months other than the current, so I needed to add support for actually handling that. I also moved the data to in memory storage in HashMaps instead of writing to temp files. > > My only worry here is that I messed up with the test so that it will start failing on certain days of the year. This pull request has now been integrated. Changeset: 515f2e14 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/515f2e14d99b02494fcfee4ea01203429b2f8e0b Stats: 126 lines in 3 files changed: 110 ins; 6 del; 10 mod 1513: Reduce polling of mailing list archives Reviewed-by: kcr ------------- PR: https://git.openjdk.org/skara/pull/1343 From gli at openjdk.org Sat Jul 30 12:32:27 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 30 Jul 2022 12:32:27 GMT Subject: RFR: 1463: Include starting branch in back port instructions Message-ID: Hi all, This patch adds the suggested git command about fetching the newest code from the target branch before solving the conflicts. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1463 Changes: https://git.openjdk.org/skara/pull/1344/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1344&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1463 Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1344.diff Fetch: git fetch https://git.openjdk.org/skara pull/1344/head:pull/1344 PR: https://git.openjdk.org/skara/pull/1344 From dholmes at openjdk.org Sun Jul 31 01:46:42 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 31 Jul 2022 01:46:42 GMT Subject: RFR: 1463: Include starting branch in back port instructions In-Reply-To: References: Message-ID: On Sat, 30 Jul 2022 12:27:40 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the suggested git command about fetching the newest code > from the target branch before solving the conflicts. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Having just done a couple of such backports I would have found the proposed addition to be extremely confusing. I think all you need to do is tweak: > To manually resolve these conflicts run the following commands in your personal fork of $REPO to include mention of the appropriate branch, and/or have a separate instruction telling you have to get the right branch if you don't already have it. But don't change the existing steps which worked perfectly fine. ------------- PR: https://git.openjdk.org/skara/pull/1344