From zsong at openjdk.org Tue May 2 21:25:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 2 May 2023 21:25:41 GMT Subject: RFR: 1852: Make it possible to disable backport PRs for repository [v3] In-Reply-To: References: Message-ID: > In this patch, PR bot has been added with the capability to control whether backport pr is allowed in specific repositories. > > By default, backport is enabled. > > However, if it is desired to disable backport in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "backport": false > } > } > } > } > > > If backport pr is disabled and the title of the pr matches the pattern of backport pr, the pr bot would reply a warning message to the user and prompt for the next steps. Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into SKARA-1852 # Conflicts: # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java # bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestBotFactoryTest.java - fix a problem - fix problems - Merge branch 'master' into SKARA-1852 # Conflicts: # bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java # bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java # bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestBotFactoryTest.java - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - fix a problem - SKARA-1852 ------------- Changes: https://git.openjdk.org/skara/pull/1497/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1497&range=02 Stats: 84 lines in 6 files changed: 80 ins; 2 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1497.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1497/head:pull/1497 PR: https://git.openjdk.org/skara/pull/1497 From erikj at openjdk.org Tue May 2 22:28:20 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 2 May 2023 22:28:20 GMT Subject: RFR: 1852: Make it possible to disable backport PRs for repository [v3] In-Reply-To: References: Message-ID: On Tue, 2 May 2023 21:25:41 GMT, Zhao Song wrote: >> In this patch, PR bot has been added with the capability to control whether backport pr is allowed in specific repositories. >> >> By default, backport is enabled. >> >> However, if it is desired to disable backport in a repo, the configuration can be added to the PR bot configuration as follows: >> >> { >> "pr": { >> "repositories": { >> "repo1": { >> "backport": false >> } >> } >> } >> } >> >> >> If backport pr is disabled and the title of the pr matches the pattern of backport pr, the pr bot would reply a warning message to the user and prompt for the next steps. > > Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Merge branch 'master' into SKARA-1852 > > # Conflicts: > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java > # bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestBotFactoryTest.java > - fix a problem > - fix problems > - Merge branch 'master' into SKARA-1852 > > # Conflicts: > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotBuilder.java > # bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java > # bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java > # bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestBotFactoryTest.java > - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > - fix a problem > - SKARA-1852 Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1497#pullrequestreview-1409967281 From zsong at openjdk.org Tue May 2 22:37:07 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 2 May 2023 22:37:07 GMT Subject: Integrated: 1852: Make it possible to disable backport PRs for repository In-Reply-To: References: Message-ID: On Wed, 5 Apr 2023 22:49:23 GMT, Zhao Song wrote: > In this patch, PR bot has been added with the capability to control whether backport pr is allowed in specific repositories. > > By default, backport is enabled. > > However, if it is desired to disable backport in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "backport": false > } > } > } > } > > > If backport pr is disabled and the title of the pr matches the pattern of backport pr, the pr bot would reply a warning message to the user and prompt for the next steps. This pull request has now been integrated. Changeset: 8096b491 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/8096b4914deaf6227da2b4a273cf750f8069624f Stats: 84 lines in 6 files changed: 80 ins; 2 del; 2 mod 1852: Make it possible to disable backport PRs for repository Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1497 From duke at openjdk.org Wed May 3 20:40:48 2023 From: duke at openjdk.org (duke) Date: Wed, 3 May 2023 20:40:48 GMT Subject: Withdrawn: 1827: Better handling of Error In-Reply-To: References: Message-ID: On Wed, 22 Mar 2023 20:05:37 GMT, Erik Joelsson wrote: > After some deliberation, I think this is how we should handle an `Error` being thrown when running a `WorkItem`. > > We need to attempt to log it and register it in the counters, otherwise it will be very hard to discover the problem. > > We also need to attempt to return the scratch path to the BotRunner, as well as removing the item from the active set, otherwise the BotRunner will enter a broken state. The drawback of this is that it will allow new instances of the same WorkItem to run, which will likely repeat the Error. I still think that's the better option compared to what we experienced in SKARA-1825. > > I think it's fine to skip scheduling of pending items. When an Error has been thrown in a thread, we should try to minimize any additional work in that thread to only what's necessary. Unless every WorkItem throws an Error, pending items will get scheduled eventually anyway, by some other successful WorkItem. If every WorkItem is throwing an Error, then not scheduling pending items is the least of our problems. By re-throwing the `Error` we make sure the Runnable exits as quickly as possible. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/skara/pull/1490 From zsong at openjdk.org Thu May 4 19:39:10 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 May 2023 19:39:10 GMT Subject: RFR: 1899: Stop notifiers when the PR bot fails to retrieve issue temporarily Message-ID: A user reported that skara bot was editing the links in [JDK-8306027](https://bugs.openjdk.org/browse/JDK-8306027) and generated many mail spam. As Erik said, [JDK-8306781](https://bugs.openjdk.org/browse/JDK-8306781) is the CSR of JDK-8306027. JDK-8306781 was updated few hours ago and it triggered CSRIssueWorkItem to update the pull request(https://github.com/openjdk/jdk/pull/13661). However, when updating the pr, the bot failed to retrieve JDK-8306027 and printed "?? Temporary failure when trying to retrieve information on issue 8306027" in the pr body. This update of PR body triggered PullRequestWorkItem in NotifyBot and make issueNotifier to update links to PR issues. To resolve this issue, I think we could stop the notifiers when the bot finds temporary issue failure. Once the temporary issue failure has been resolved, the pr body will be updated again and it will trigger the notifiers to work. ------------- Commit messages: - SKARA-1899 Changes: https://git.openjdk.org/skara/pull/1512/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1512&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1899 Stats: 91 lines in 6 files changed: 87 ins; 1 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1512.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1512/head:pull/1512 PR: https://git.openjdk.org/skara/pull/1512 From erikj at openjdk.org Thu May 4 21:02:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 4 May 2023 21:02:51 GMT Subject: RFR: 1899: Stop notifiers when the PR bot fails to retrieve issue temporarily In-Reply-To: References: Message-ID: On Thu, 4 May 2023 17:54:15 GMT, Zhao Song wrote: > A user reported that skara bot was editing the links in [JDK-8306027](https://bugs.openjdk.org/browse/JDK-8306027) and generated many mail spam. > > As Erik said, [JDK-8306781](https://bugs.openjdk.org/browse/JDK-8306781) is the CSR of JDK-8306027. JDK-8306781 was updated few hours ago and it triggered CSRIssueWorkItem to update the pull request(https://github.com/openjdk/jdk/pull/13661). However, when updating the pr, the bot failed to retrieve JDK-8306027 and printed "?? Temporary failure when trying to retrieve information on issue 8306027" in the pr body. This update of PR body triggered PullRequestWorkItem in NotifyBot and make issueNotifier to update links to PR issues. > > To resolve this issue, I think we could stop the notifiers when the bot finds temporary issue failure. > > Once the temporary issue failure has been resolved, the pr body will be updated again and it will trigger the notifiers to work. Seems reasonable. Thanks for figuring this out! ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1512#pullrequestreview-1413917322 From zsong at openjdk.org Thu May 4 21:18:07 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 May 2023 21:18:07 GMT Subject: RFR: 1899: Stop notifiers when the PR bot fails to retrieve issue temporarily In-Reply-To: References: Message-ID: <3D0AUWRAXt4VSgmjYuMw9YtkBqk5jwKy8CC8UkOwXMk=.19d68102-a9fc-4172-85f0-96d71258e396@github.com> On Thu, 4 May 2023 17:54:15 GMT, Zhao Song wrote: > A user reported that skara bot was editing the links in [JDK-8306027](https://bugs.openjdk.org/browse/JDK-8306027) and generated many mail spam. > > As Erik said, [JDK-8306781](https://bugs.openjdk.org/browse/JDK-8306781) is the CSR of JDK-8306027. JDK-8306781 was updated few hours ago and it triggered CSRIssueWorkItem to update the pull request(https://github.com/openjdk/jdk/pull/13661). However, when updating the pr, the bot failed to retrieve JDK-8306027 and printed "?? Temporary failure when trying to retrieve information on issue 8306027" in the pr body. This update of PR body triggered PullRequestWorkItem in NotifyBot and make issueNotifier to update links to PR issues. > > To resolve this issue, I think we could stop the notifiers when the bot finds temporary issue failure. > > Once the temporary issue failure has been resolved, the pr body will be updated again and it will trigger the notifiers to work. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1512#issuecomment-1535422635 From zsong at openjdk.org Thu May 4 21:18:07 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 May 2023 21:18:07 GMT Subject: Integrated: 1899: Stop notifiers when the PR bot fails to retrieve issue temporarily In-Reply-To: References: Message-ID: On Thu, 4 May 2023 17:54:15 GMT, Zhao Song wrote: > A user reported that skara bot was editing the links in [JDK-8306027](https://bugs.openjdk.org/browse/JDK-8306027) and generated many mail spam. > > As Erik said, [JDK-8306781](https://bugs.openjdk.org/browse/JDK-8306781) is the CSR of JDK-8306027. JDK-8306781 was updated few hours ago and it triggered CSRIssueWorkItem to update the pull request(https://github.com/openjdk/jdk/pull/13661). However, when updating the pr, the bot failed to retrieve JDK-8306027 and printed "?? Temporary failure when trying to retrieve information on issue 8306027" in the pr body. This update of PR body triggered PullRequestWorkItem in NotifyBot and make issueNotifier to update links to PR issues. > > To resolve this issue, I think we could stop the notifiers when the bot finds temporary issue failure. > > Once the temporary issue failure has been resolved, the pr body will be updated again and it will trigger the notifiers to work. This pull request has now been integrated. Changeset: 0b67e8fd Author: Zhao Song URL: https://git.openjdk.org/skara/commit/0b67e8fdcb1f8231b18491f8d2581573fa63c792 Stats: 91 lines in 6 files changed: 87 ins; 1 del; 3 mod 1899: Stop notifiers when the PR bot fails to retrieve issue temporarily Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1512 From duke at openjdk.org Thu May 4 23:26:51 2023 From: duke at openjdk.org (duke) Date: Thu, 4 May 2023 23:26:51 GMT Subject: Withdrawn: 1663: Mark integrated Pull Requests as properly merged in their repositories In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 16:55:16 GMT, Julian Waters wrote: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/skara/pull/1409 From zsong at openjdk.org Fri May 5 16:29:51 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 16:29:51 GMT Subject: RFR: 1669: Limit the amount of description copied into subsequent comment emails Message-ID: A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. In this patch, the length of **quoted** pr body or comment is limited to 2500. ------------- Commit messages: - SKARA-1669 Changes: https://git.openjdk.org/skara/pull/1511/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1511&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1669 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1511.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1511/head:pull/1511 PR: https://git.openjdk.org/skara/pull/1511 From zsong at openjdk.org Fri May 5 17:57:57 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 17:57:57 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR Message-ID: Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. To resolve this issue, we should use the domain in jcheck configuration file. ------------- Commit messages: - SKARA-1340 Changes: https://git.openjdk.org/skara/pull/1513/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1340 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1513.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/skara/pull/1513 From gli at openjdk.org Fri May 5 18:09:50 2023 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 May 2023 18:09:50 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:06:52 GMT, Zhao Song wrote: > Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. > > To resolve this issue, we should use the domain in jcheck configuration file. bots/pr/src/main/java/org/openjdk/skara/bots/pr/ContributorCommand.java line 90: > 88: > 89: if (contributor.fullName().isPresent()) { > 90: return Optional.of(EmailAddress.from(contributor.fullName().get(), contributor.username() + "@" + censusInstance.configuration.census().domain())); The `configuration` is a private field in class `CensusInstance`, so we should use the getter method `configuration()`. But it is curious that the building and testing of the `Pre-submit tests` succeeded. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1513#discussion_r1186373511 From zsong at openjdk.org Fri May 5 18:15:16 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 18:15:16 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: > Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. > > To resolve this issue, we should use the domain in jcheck configuration file. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix a problem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1513/files - new: https://git.openjdk.org/skara/pull/1513/files/cacbb932..b2bc9c37 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1513.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/skara/pull/1513 From zsong at openjdk.org Fri May 5 18:15:16 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 18:15:16 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:07:36 GMT, Guoxiong Li wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a problem > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ContributorCommand.java line 90: > >> 88: >> 89: if (contributor.fullName().isPresent()) { >> 90: return Optional.of(EmailAddress.from(contributor.fullName().get(), contributor.username() + "@" + censusInstance.configuration.census().domain())); > > The `configuration` is a private field in class `CensusInstance`, so we should use the getter method `configuration()`. But it is curious that the building and testing of the `Pre-submit tests` succeeded. Thanks for catching it! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1513#discussion_r1186375436 From gli at openjdk.org Fri May 5 18:19:15 2023 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 May 2023 18:19:15 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:15:16 GMT, Zhao Song wrote: >> Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. >> >> To resolve this issue, we should use the domain in jcheck configuration file. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fix a problem Looks good. > But it is curious that the building and testing of the Pre-submit tests succeeded. But still strange. ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/skara/pull/1513#pullrequestreview-1415246148 From zsong at openjdk.org Fri May 5 18:27:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 18:27:05 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: <7Qe7crWSTNdm3RKo7AdB27Jcdsk_sQEb4Gsaef1DWdg=.1268504f-8e59-45ee-ad14-abd27d00ac14@github.com> On Fri, 5 May 2023 18:17:00 GMT, Guoxiong Li wrote: > Looks good. > > > But it is curious that the building and testing of the Pre-submit tests succeeded. > > But still strange. The field is not private, it's protected. And `LimitedCensusInstance` and `ContributorCommand` are both under `org.openjdk.skara.bots.pr` ------------- PR Comment: https://git.openjdk.org/skara/pull/1513#issuecomment-1536617248 From zsong at openjdk.org Fri May 5 18:35:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 18:35:23 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v3] In-Reply-To: References: Message-ID: > Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. > > To resolve this issue, we should use the domain in jcheck configuration file. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add a test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1513/files - new: https://git.openjdk.org/skara/pull/1513/files/b2bc9c37..bf623cfa Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=01-02 Stats: 92 lines in 1 file changed: 92 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1513.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/skara/pull/1513 From gli at openjdk.org Fri May 5 18:37:36 2023 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 May 2023 18:37:36 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: <7Qe7crWSTNdm3RKo7AdB27Jcdsk_sQEb4Gsaef1DWdg=.1268504f-8e59-45ee-ad14-abd27d00ac14@github.com> References: <7Qe7crWSTNdm3RKo7AdB27Jcdsk_sQEb4Gsaef1DWdg=.1268504f-8e59-45ee-ad14-abd27d00ac14@github.com> Message-ID: On Fri, 5 May 2023 18:23:42 GMT, Zhao Song wrote: > The field is not private, it's protected. And `LimitedCensusInstance` and `ContributorCommand` are both under `org.openjdk.skara.bots.pr` I know why I misunderstand it. I mis-read the `CensusInstance` class of the package `org.openjdk.skara.bots.mlbridge` by using the GitHub symbol search feature. So it is also good to use the field directly. Nevermind. ------------- PR Comment: https://git.openjdk.org/skara/pull/1513#issuecomment-1536629386 From gli at openjdk.org Fri May 5 20:01:57 2023 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 May 2023 20:01:57 GMT Subject: RFR: 1669: Limit the amount of description copied into subsequent comment emails In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:21:42 GMT, Zhao Song wrote: > A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. > > In this patch, the length of **quoted** pr body or comment is limited to 2500. The test case `MailingListBridgeBotTests#archiveDirectToIntegrated` failed in the `Pre-submit tests`. The [log](https://github.com/zhaosongzs/skara/actions/runs/4876601337/jobs/8700294843) is shown below. It is not normal because the it sent a http request to get the issue which should not occur in the test code. MailingListBridgeBotTests > archiveDirectToIntegrated(TestInfo) FAILED java.lang.IllegalStateException: [0]: not a valid start of a JSON value : Error An error occurred while processing your request.

Reference #27.d86bdc17.1683148864.42e2c0b9 at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.failure(JSONParser.java:43) at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.parseValue(JSONParser.java:444) at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.parse(JSONParser.java:464) at org.openjdk.skara.json/org.openjdk.skara.json.JSON.parse(JSON.java:27) at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest.parseResponse(RestRequest.java:369) at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest.execute(RestRequest.java:492) at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest$QueryBuilder.execute(RestRequest.java:213)//here at org.openjdk.skara.issuetracker/org.openjdk.skara.issuetracker.jira.JiraProject.issue(JiraProject.java:439) // <-- here at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage.generateHTML(WebrevStorage.java:115) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage.createAndArchive(WebrevStorage.java:316) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage$1.generate(WebrevStorage.java:338) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveItem.lambda$from$10(ArchiveItem.java:220) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveItem.footer(ArchiveItem.java:471) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ReviewArchive.generateNewEmails(ReviewArchive.java:359) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveWorkItem.run(ArchiveWorkItem.java:381) at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:56) at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:43) at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:38) at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.MailingListBridgeBotTests.archiveDirectToIntegrated(MailingListBridgeBotTests.java:531) The reason about the failed test is: The method `WebrevStorage#generateHTML` uses the real `JIRA` uri instead of the test config. And the `JIRA` is down at that time and returns unexpected `Error` which is the `html` format instead of the `json` format, so SKARA can't parse it. The method `WebrevStorage#generateHTML` needs to be adjusted and the failed test case is not related to this patch. // method WebrevStorage#generateHTML IssueTracker issueTracker = null; try { issueTracker = IssueTracker.from("jira", URI.create("https://bugs.openjdk.org")); } catch (RuntimeException e) { log.warning("Failed to create Jira issue tracker"); } ------------- PR Comment: https://git.openjdk.org/skara/pull/1511#issuecomment-1536713910 From zsong at openjdk.org Fri May 5 20:12:28 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 20:12:28 GMT Subject: RFR: 1669: Limit the amount of description copied into subsequent comment emails In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:21:42 GMT, Zhao Song wrote: > A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. > > In this patch, the length of **quoted** pr body or comment is limited to 2500. > The test case `MailingListBridgeBotTests#archiveDirectToIntegrated` failed in the `Pre-submit tests`. The [log](https://github.com/zhaosongzs/skara/actions/runs/4876601337/jobs/8700294843) is shown below. It is not normal because the it sent a http request to get the issue which should not occur in the test code. > > ``` > MailingListBridgeBotTests > archiveDirectToIntegrated(TestInfo) FAILED > java.lang.IllegalStateException: [0]: not a valid start of a JSON value : Error > An error occurred while processing your request.

> Reference #27.d86bdc17.1683148864.42e2c0b9 > > at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.failure(JSONParser.java:43) > at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.parseValue(JSONParser.java:444) > at org.openjdk.skara.json/org.openjdk.skara.json.JSONParser.parse(JSONParser.java:464) > at org.openjdk.skara.json/org.openjdk.skara.json.JSON.parse(JSON.java:27) > at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest.parseResponse(RestRequest.java:369) > at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest.execute(RestRequest.java:492) > at org.openjdk.skara.network/org.openjdk.skara.network.RestRequest$QueryBuilder.execute(RestRequest.java:213)//here > at org.openjdk.skara.issuetracker/org.openjdk.skara.issuetracker.jira.JiraProject.issue(JiraProject.java:439) // <-- here > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage.generateHTML(WebrevStorage.java:115) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage.createAndArchive(WebrevStorage.java:316) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.WebrevStorage$1.generate(WebrevStorage.java:338) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveItem.lambda$from$10(ArchiveItem.java:220) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveItem.footer(ArchiveItem.java:471) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ReviewArchive.generateNewEmails(ReviewArchive.java:359) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.ArchiveWorkItem.run(ArchiveWorkItem.java:381) > at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:56) > at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:43) > at org.openjdk.skara.test/org.openjdk.skara.test.TestBotRunner.runPeriodicItems(TestBotRunner.java:38) > at org.openjdk.skara.bots.mlbridge/org.openjdk.skara.bots.mlbridge.MailingListBridgeBotTests.archiveDirectToIntegrated(MailingListBridgeBotTests.java:531) > ``` > > The reason about the failed test is: The method `WebrevStorage#generateHTML` uses the real `JIRA` uri instead of the test config. And the `JIRA` is down at that time and returns unexpected `Error` which is the `html` format instead of the `json` format, so SKARA can't parse it. The method `WebrevStorage#generateHTML` needs to be adjusted and the failed test case is not related to this patch. > > ``` > // method WebrevStorage#generateHTML > IssueTracker issueTracker = null; > try { > issueTracker = IssueTracker.from("jira", URI.create("https://bugs.openjdk.org")); > } catch (RuntimeException e) { > log.warning("Failed to create Jira issue tracker"); > } > ``` Yes, it's a known issue and some colleagues are trying to resolve it. Thanks for investigating! ------------- PR Comment: https://git.openjdk.org/skara/pull/1511#issuecomment-1536724749 From gli at openjdk.org Fri May 5 20:17:57 2023 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 5 May 2023 20:17:57 GMT Subject: RFR: 1669: Limit the amount of description copied into subsequent comment emails In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:21:42 GMT, Zhao Song wrote: > A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. > > In this patch, the length of **quoted** pr body or comment is limited to 2500. LGTM ------------- Marked as reviewed by gli (Committer). PR Review: https://git.openjdk.org/skara/pull/1511#pullrequestreview-1415404264 From erikj at openjdk.org Fri May 5 21:18:05 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 21:18:05 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v3] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 18:35:23 GMT, Zhao Song wrote: >> Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. >> >> To resolve this issue, we should use the domain in jcheck configuration file. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add a test Marked as reviewed by erikj (Lead). bots/pr/src/main/java/org/openjdk/skara/bots/pr/ContributorCommand.java line 90: > 88: > 89: if (contributor.fullName().isPresent()) { > 90: return Optional.of(EmailAddress.from(contributor.fullName().get(), contributor.username() + "@" + censusInstance.configuration().census().domain())); Could do with a line break here to make it more readable, especially in diffs. ------------- PR Review: https://git.openjdk.org/skara/pull/1513#pullrequestreview-1415463233 PR Review Comment: https://git.openjdk.org/skara/pull/1513#discussion_r1186503001 From erikj at openjdk.org Fri May 5 21:22:28 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 21:22:28 GMT Subject: RFR: 1669: Limit the amount of description copied into subsequent comment emails In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:21:42 GMT, Zhao Song wrote: > A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. > > In this patch, the length of **quoted** pr body or comment is limited to 2500. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1511#pullrequestreview-1415471102 From erikj at openjdk.org Fri May 5 21:47:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 May 2023 21:47:31 GMT Subject: RFR: 1902: Log response code when response body cannot be parsed Message-ID: This patch adds better logging of response status codes when things fail. ------------- Commit messages: - SKARA-1902 Changes: https://git.openjdk.org/skara/pull/1514/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1514&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1902 Stats: 15 lines in 3 files changed: 9 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1514.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/skara/pull/1514 From zsong at openjdk.org Fri May 5 23:07:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 23:07:23 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v3] In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:10:31 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> add a test > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/ContributorCommand.java line 90: > >> 88: >> 89: if (contributor.fullName().isPresent()) { >> 90: return Optional.of(EmailAddress.from(contributor.fullName().get(), contributor.username() + "@" + censusInstance.configuration().census().domain())); > > Could do with a line break here to make it more readable, especially in diffs. Sure ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1513#discussion_r1186549092 From zsong at openjdk.org Fri May 5 23:13:21 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 5 May 2023 23:13:21 GMT Subject: RFR: 1340: Correct email domain not always used when adding a contributor to a PR [v4] In-Reply-To: References: Message-ID: > Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. > > To resolve this issue, we should use the domain in jcheck configuration file. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add a linebreaker ------------- Changes: - all: https://git.openjdk.org/skara/pull/1513/files - new: https://git.openjdk.org/skara/pull/1513/files/bf623cfa..d5fa1188 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1513&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1513.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1513/head:pull/1513 PR: https://git.openjdk.org/skara/pull/1513 From zsong at openjdk.org Mon May 8 17:22:50 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 17:22:50 GMT Subject: RFR: 1902: Log response code when response body cannot be parsed In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:43:38 GMT, Erik Joelsson wrote: > This patch adds better logging of response status codes when things fail. LGTM ------------- Marked as reviewed by zsong (Committer). PR Review: https://git.openjdk.org/skara/pull/1514#pullrequestreview-1417193880 From zsong at openjdk.org Mon May 8 19:59:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 19:59:24 GMT Subject: RFR: 1332: Skara sometimes fails to detect that a backport was clean Message-ID: The pr bot sometimes fails to detect a backport is clean. This issue for GitHub part was resolved by Guoxiong Li in [SKARA-1406](https://bugs.openjdk.org/browse/SKARA-1406). This issue for GitLab part will be resolved in this patch. Investigated some GitLab MR examples, I found that although the GitLab UI shows there are diffs in some files, when the bot queries changes of the pr, GitLab would tell the bot there are no diffs in some files. After reading the GitLab Api document, I found that we should set `access_raw_diffs` to `true` to get all the diffs. https://docs.gitlab.com/ee/api/merge_requests.html#get-single-merge-request-changes ------------- Commit messages: - SKARA-1332 Changes: https://git.openjdk.org/skara/pull/1515/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1515&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1332 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1515.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1515/head:pull/1515 PR: https://git.openjdk.org/skara/pull/1515 From zsong at openjdk.org Mon May 8 20:03:32 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 20:03:32 GMT Subject: Integrated: 1669: Limit the amount of description copied into subsequent comment emails In-Reply-To: References: Message-ID: On Wed, 3 May 2023 21:21:42 GMT, Zhao Song wrote: > A user complains about that sometimes the pr body can be very long and this very long pr body will be included in every email about this pr. The user will need to scroll down many times to the bottom of the email to find the useful information. > > In this patch, the length of **quoted** pr body or comment is limited to 2500. This pull request has now been integrated. Changeset: 20d89591 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/20d89591308f06d1ce9d6e929535c30a47603911 Stats: 99 lines in 2 files changed: 99 ins; 0 del; 0 mod 1669: Limit the amount of description copied into subsequent comment emails Reviewed-by: gli, erikj ------------- PR: https://git.openjdk.org/skara/pull/1511 From zsong at openjdk.org Mon May 8 20:04:04 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 20:04:04 GMT Subject: Integrated: 1340: Correct email domain not always used when adding a contributor to a PR In-Reply-To: References: Message-ID: On Fri, 5 May 2023 17:06:52 GMT, Zhao Song wrote: > Now, the email domain for additional contributors is always the default "openjdk.org" domain because we hardcoded it. > > To resolve this issue, we should use the domain in jcheck configuration file. This pull request has now been integrated. Changeset: 53328fdb Author: Zhao Song URL: https://git.openjdk.org/skara/commit/53328fdbacdc59a9bdc928022f43de232be332af Stats: 94 lines in 2 files changed: 93 ins; 0 del; 1 mod 1340: Correct email domain not always used when adding a contributor to a PR Reviewed-by: gli, erikj ------------- PR: https://git.openjdk.org/skara/pull/1513 From erikj at openjdk.org Mon May 8 20:31:20 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 8 May 2023 20:31:20 GMT Subject: RFR: 1332: Skara sometimes fails to detect that a backport was clean In-Reply-To: References: Message-ID: <-Vlv60fCD-f8vtOP5EUpBynM0zYbLrMe3EgHwZF3akU=.f7d23c1a-cbdf-4b81-9cd6-1f6c0006d3df@github.com> On Mon, 8 May 2023 19:45:59 GMT, Zhao Song wrote: > The pr bot sometimes fails to detect a backport is clean. > > This issue for GitHub part was resolved by Guoxiong Li in [SKARA-1406](https://bugs.openjdk.org/browse/SKARA-1406). > > This issue for GitLab part will be resolved in this patch. > > Investigated some GitLab MR examples, I found that although the GitLab UI shows there are diffs in some files, when the bot queries changes of the pr, GitLab would tell the bot there are no diffs in some files. > > After reading the GitLab Api document, I found that we should set `access_raw_diffs` to `true` to get all the diffs. > > https://docs.gitlab.com/ee/api/merge_requests.html#get-single-merge-request-changes Good investigation. This should get more diffs classified as clean. Reading the doc, there may still be limitations at play, and in the end we may end up having to perform the comparison with local repos, but this is definitely worth trying first. ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1515#pullrequestreview-1417468726 From zsong at openjdk.org Mon May 8 21:05:29 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 21:05:29 GMT Subject: RFR: 1332: Skara sometimes fails to detect that a backport was clean In-Reply-To: References: Message-ID: <0kSbscWPDEIGPHlu-LFmYcl0uNf0YxVCDLZadQuBkVQ=.97363044-d4bd-4c42-96cd-d97af217bf0a@github.com> On Mon, 8 May 2023 19:45:59 GMT, Zhao Song wrote: > The pr bot sometimes fails to detect a backport is clean. > > This issue for GitHub part was resolved by Guoxiong Li in [SKARA-1406](https://bugs.openjdk.org/browse/SKARA-1406). > > This issue for GitLab part will be resolved in this patch. > > Investigated some GitLab MR examples, I found that although the GitLab UI shows there are diffs in some files, when the bot queries changes of the pr, GitLab would tell the bot there are no diffs in some files. > > After reading the GitLab Api document, I found that we should set `access_raw_diffs` to `true` to get all the diffs. > > https://docs.gitlab.com/ee/api/merge_requests.html#get-single-merge-request-changes Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1515#issuecomment-1539046217 From zsong at openjdk.org Mon May 8 21:05:29 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 8 May 2023 21:05:29 GMT Subject: Integrated: 1332: Skara sometimes fails to detect that a backport was clean In-Reply-To: References: Message-ID: On Mon, 8 May 2023 19:45:59 GMT, Zhao Song wrote: > The pr bot sometimes fails to detect a backport is clean. > > This issue for GitHub part was resolved by Guoxiong Li in [SKARA-1406](https://bugs.openjdk.org/browse/SKARA-1406). > > This issue for GitLab part will be resolved in this patch. > > Investigated some GitLab MR examples, I found that although the GitLab UI shows there are diffs in some files, when the bot queries changes of the pr, GitLab would tell the bot there are no diffs in some files. > > After reading the GitLab Api document, I found that we should set `access_raw_diffs` to `true` to get all the diffs. > > https://docs.gitlab.com/ee/api/merge_requests.html#get-single-merge-request-changes This pull request has now been integrated. Changeset: 0043fdf3 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/0043fdf3aab5a5dee4ad6e35915bb7962b39ce2e Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1332: Skara sometimes fails to detect that a backport was clean Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1515 From erik.joelsson at oracle.com Tue May 9 13:06:03 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 9 May 2023 06:06:03 -0700 Subject: CFV: New Skara Reviewer: Zhao Song Message-ID: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> I hereby nominate Zhao Song to Skara Reviewer. Zhao is a member of the infrastructure team at Oracle and has been hard at work improving Skara. He has so far contributed 81 changes to the Skara project [3], covering multiple areas and aspects of the tools. Votes are due by 2023-05-23 6:05 PDT. Only current Skara Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. Erik Joelsson [1] https://openjdk.org/census [2] https://openjdk.org/projects/#reviewer-vote [3] https://github.com/openjdk/skara/commits?author=zhaosongzs From kevin.rushforth at oracle.com Tue May 9 13:25:27 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 9 May 2023 06:25:27 -0700 Subject: CFV: New Skara Reviewer: Zhao Song In-Reply-To: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> References: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> Message-ID: <5b5a7d4a-cd0e-dc6e-6cc5-fa7b6c15f5fc@oracle.com> Vote: YES -- Kevin On 5/9/2023 6:06 AM, erik.joelsson at oracle.com wrote: > I hereby nominate Zhao Song to Skara Reviewer. From tim.bell at oracle.com Tue May 9 13:42:31 2023 From: tim.bell at oracle.com (tim.bell at oracle.com) Date: Tue, 9 May 2023 06:42:31 -0700 Subject: CFV: New Skara Reviewer: Zhao Song In-Reply-To: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> References: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> Message-ID: <614aac94-0a90-f11c-b430-62c948110dd0@oracle.com> Vote: yes Tim On 5/9/23 06:06, erik.joelsson at oracle.com wrote: > I hereby nominate Zhao Song to Skara Reviewer. From erik.joelsson at oracle.com Tue May 9 15:50:58 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 9 May 2023 08:50:58 -0700 Subject: CFV: New Skara Reviewer: Zhao Song In-Reply-To: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> References: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> Message-ID: Vote: yes /Erik On 5/9/23 06:06, erik.joelsson at oracle.com wrote: > I hereby nominate Zhao Song to Skara Reviewer. > > Zhao is a member of the infrastructure team at Oracle and has been > hard at work improving Skara. He has so far contributed 81 changes to > the Skara project [3], covering multiple areas and aspects of the tools. > > Votes are due by 2023-05-23 6:05 PDT. > > Only current Skara Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Joelsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/skara/commits?author=zhaosongzs > From joe.darcy at oracle.com Tue May 9 16:48:47 2023 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 9 May 2023 09:48:47 -0700 Subject: CFV: New Skara Reviewer: Zhao Song In-Reply-To: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> References: <4d38fae8-e3db-c232-370d-f7b02afbf8d5@oracle.com> Message-ID: <8fdc1b52-07de-13a8-211f-de9ca16e2e6a@oracle.com> Vote: yes On 5/9/2023 6:06 AM, erik.joelsson at oracle.com wrote: > I hereby nominate Zhao Song to Skara Reviewer. > > Zhao is a member of the infrastructure team at Oracle and has been > hard at work improving Skara. He has so far contributed 81 changes to > the Skara project [3], covering multiple areas and aspects of the tools. > > Votes are due by 2023-05-23 6:05 PDT. > > Only current Skara Reviewers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Three-Vote Consensus voting instructions, see [2]. > > Erik Joelsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#reviewer-vote > [3] https://github.com/openjdk/skara/commits?author=zhaosongzs > From zsong at openjdk.org Tue May 9 21:23:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 21:23:41 GMT Subject: RFR: 1903: Verify User's group membership when processing backport command Message-ID: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. ------------- Commit messages: - SKARA-1903 Changes: https://git.openjdk.org/skara/pull/1516/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1903 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1516.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1516/head:pull/1516 PR: https://git.openjdk.org/skara/pull/1516 From erikj at openjdk.org Tue May 9 22:05:12 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 22:05:12 GMT Subject: RFR: 1903: Verify User's group membership when processing backport command In-Reply-To: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: On Tue, 9 May 2023 21:05:01 GMT, Zhao Song wrote: > In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. > > However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. > > For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. > > To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 393: > 391: } > 392: > 393: private boolean verifyGroupMembership(HostedRepository targetRepo, HostUser user, PrintWriter reply) { The name of this method is misleading as we aren't actually checking group membership, in this patch we are checking write access, which may or may not be indicative of group membership. What actually matters is that the right access is available though. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 398: > 396: if (!targetRepo.forge().name().equals("GitHub") && !targetRepo.forge().name().equals("Test")) { > 397: hasGroupMembership = targetRepo.canPush(user); > 398: } This is too much of a hack for me. There needs to be a method on the repository that each relevant implementation of the `HostedRepository` interface has a valid implementation for that answers the question we need to ask. I think that question is something like "is the user allowed to open pull requests against this repo"? For `GitHubRepository` that is probably always true, at least in our context. For `TestHostedRepository` I would assume it's always true, unless you wanted to make it false for testing purposes. In that case you could make it possible to toggle from a test. For `GitLabRepository` the method can probably delegate to `canPush`, but I would like to have that verified. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 400: > 398: } > 399: if (!hasGroupMembership) { > 400: reply.println("The backport can not be created because you don't have group membership in the target repository!"); Suggestion: reply.println("The backport can not be created because you don't have access to the target repository."); ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189168147 PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189172246 PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189173084 From zsong at openjdk.org Tue May 9 22:18:20 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 22:18:20 GMT Subject: RFR: 1903: Verify User's group membership when processing backport command [v2] In-Reply-To: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: > In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. > > However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. > > For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. > > To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1516/files - new: https://git.openjdk.org/skara/pull/1516/files/88f81e3c..0bb6a3a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1516.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1516/head:pull/1516 PR: https://git.openjdk.org/skara/pull/1516 From zsong at openjdk.org Tue May 9 22:18:20 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 22:18:20 GMT Subject: RFR: 1903: Verify User's group membership when processing backport command [v2] In-Reply-To: References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: On Tue, 9 May 2023 21:54:02 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java >> >> Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 393: > >> 391: } >> 392: >> 393: private boolean verifyGroupMembership(HostedRepository targetRepo, HostUser user, PrintWriter reply) { > > The name of this method is misleading as we aren't actually checking group membership, in this patch we are checking write access, which may or may not be indicative of group membership. What actually matters is that the right access is available though. Will change the name to `checkWriteAccess`. Thanks! > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 398: > >> 396: if (!targetRepo.forge().name().equals("GitHub") && !targetRepo.forge().name().equals("Test")) { >> 397: hasGroupMembership = targetRepo.canPush(user); >> 398: } > > This is too much of a hack for me. There needs to be a method on the repository that each relevant implementation of the `HostedRepository` interface has a valid implementation for that answers the question we need to ask. I think that question is something like "is the user allowed to open pull requests against this repo"? For `GitHubRepository` that is probably always true, at least in our context. For `TestHostedRepository` I would assume it's always true, unless you wanted to make it false for testing purposes. In that case you could make it possible to toggle from a test. For `GitLabRepository` the method can probably delegate to `canPush`, but I would like to have that verified. It's quite a good idea. Will do it. Thanks! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189180192 PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189180287 From zsong at openjdk.org Tue May 9 22:38:37 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 22:38:37 GMT Subject: RFR: 1903: Verify User's repository access when processing backport command [v3] In-Reply-To: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: > In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. > > However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. > > For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. > > To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix some problems ------------- Changes: - all: https://git.openjdk.org/skara/pull/1516/files - new: https://git.openjdk.org/skara/pull/1516/files/0bb6a3a6..bb3546f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=01-02 Stats: 43 lines in 6 files changed: 29 ins; 12 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1516.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1516/head:pull/1516 PR: https://git.openjdk.org/skara/pull/1516 From erikj at openjdk.org Tue May 9 22:42:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 9 May 2023 22:42:03 GMT Subject: RFR: 1903: Verify User's repository access when processing backport command [v3] In-Reply-To: References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: On Tue, 9 May 2023 22:13:31 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 393: >> >>> 391: } >>> 392: >>> 393: private boolean verifyGroupMembership(HostedRepository targetRepo, HostUser user, PrintWriter reply) { >> >> The name of this method is misleading as we aren't actually checking group membership, in this patch we are checking write access, which may or may not be indicative of group membership. What actually matters is that the right access is available though. > > Will change the name to `checkWriteAccess`. Thanks! Thinking some more on this, I think it should be something like `canCreatePullRequest`. Write access implies being able to push to the repo, something we disable through various means most of the time. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189194138 From zsong at openjdk.org Tue May 9 22:46:26 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 22:46:26 GMT Subject: RFR: 1903: Verify User's repository access when processing backport command [v3] In-Reply-To: References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: On Tue, 9 May 2023 22:39:50 GMT, Erik Joelsson wrote: >> Will change the name to `checkWriteAccess`. Thanks! > > Thinking some more on this, I think it should be something like `canCreatePullRequest`. Write access implies being able to push to the repo, something we disable through various means most of the time. Just deleted this whole method. I added a method called 'hasRepoAccess' in 'HostedRepository', I could rename this method to `canCreatePullRequest` ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1516#discussion_r1189196397 From zsong at openjdk.org Tue May 9 22:59:02 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 May 2023 22:59:02 GMT Subject: RFR: 1903: Verify User's repository access when processing backport command [v4] In-Reply-To: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: > In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. > > However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. > > For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. > > To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: rename method ------------- Changes: - all: https://git.openjdk.org/skara/pull/1516/files - new: https://git.openjdk.org/skara/pull/1516/files/bb3546f8..692e00d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1516&range=02-03 Stats: 11 lines in 6 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/skara/pull/1516.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1516/head:pull/1516 PR: https://git.openjdk.org/skara/pull/1516 From erikj at openjdk.org Wed May 10 13:06:43 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 13:06:43 GMT Subject: RFR: 1903: Verify User's repository access when processing backport command [v4] In-Reply-To: References: <4WFDWXjbuL20hRL71n78yp6QcRpPrGrvWnG38qiZh3k=.e0d13b43-a794-4f05-afba-3afde303275a@github.com> Message-ID: On Tue, 9 May 2023 22:59:02 GMT, Zhao Song wrote: >> In GitLab, every project is under a group. If a user doesn't have access to the group, then the user will not be able to see any project under the group. >> >> However, when processing backport command, the bot will not verify user's group membership, so that it's possible for the bot to create a pull request that is invisible to the user. >> >> For example, if a user has access to "groupA" but not "groupB", then he can issue the "/backport groupB/repo2" command on one of the commits in "groupA/repo1". In this case, Skara bot would create a PR that is invisible to the user. >> >> To fix this issue, we need to verify user's membership after we get the targetRepo. `GitLabRepository#canPush` is very helpful. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > rename method Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1516#pullrequestreview-1420599000 From zsong at openjdk.org Wed May 10 18:20:52 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 May 2023 18:20:52 GMT Subject: RFR: 1907: Notifiers should not be stopped due to temporary issue failure when pr is integrated Message-ID: In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. In this patch, the conditions for stopping notifiers have been tightened. ------------- Commit messages: - SKARA-1907 Changes: https://git.openjdk.org/skara/pull/1518/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1518&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1907 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1518.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1518/head:pull/1518 PR: https://git.openjdk.org/skara/pull/1518 From erikj at openjdk.org Wed May 10 19:59:26 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 May 2023 19:59:26 GMT Subject: RFR: 1907: Notifiers should not be stopped due to temporary issue failure when pr is integrated In-Reply-To: References: Message-ID: On Wed, 10 May 2023 18:12:20 GMT, Zhao Song wrote: > In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. > > In this patch, the conditions for stopping notifiers have been tightened. This would fix the problem of not retargeting dependent PRs, but if an integrated PR is left with `TEMPORARY_ISSUE_FAILURE_MARKER`, then we will never resolve the Jira issue, because the notifier can't find the correct set of Jira issues associated with the PR. I think we need to attack this in the PR bot somehow, to make sure we keep trying until we are able to resolve the jira issue link. ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1542729548 From zsong at openjdk.org Wed May 10 20:42:10 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 May 2023 20:42:10 GMT Subject: RFR: 1907: Notifiers should not be stopped due to temporary issue failure when pr is integrated In-Reply-To: References: Message-ID: On Wed, 10 May 2023 19:57:19 GMT, Erik Joelsson wrote: > This would fix the problem of not retargeting dependent PRs, but if an integrated PR is left with `TEMPORARY_ISSUE_FAILURE_MARKER`, then we will never resolve the Jira issue, because the notifier can't find the correct set of Jira issues associated with the PR. > > I think we need to attack this in the PR bot somehow, to make sure we keep trying until we are able to resolve the jira issue link. Exactly. I will do some change to pr bot. ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1542780254 From zsong at openjdk.org Wed May 10 23:33:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 May 2023 23:33:53 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure [v2] In-Reply-To: References: Message-ID: > In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. > > Also, if the pr is integrated with the temporary issue failure, it would make the issue never get resolved. > > In this patch, the conditions for stopping notifiers have been tightened. Besides, the pr bot would not mark a pr as ready is the pr body contains `TEMPORARY_ISSUE_FAILURE_MARKER` Zhao Song has updated the pull request incrementally with one additional commit since the last revision: SKARA-1907 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1518/files - new: https://git.openjdk.org/skara/pull/1518/files/9d42fb7d..33232890 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1518&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1518&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1518.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1518/head:pull/1518 PR: https://git.openjdk.org/skara/pull/1518 From zsong at openjdk.org Wed May 10 23:33:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 May 2023 23:33:53 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure In-Reply-To: References: Message-ID: On Wed, 10 May 2023 18:12:20 GMT, Zhao Song wrote: > In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. > > Also, if the pr is integrated with the temporary issue failure, it would make the issue never get resolved. > > In this patch, the conditions for stopping notifiers have been tightened. Besides, the pr bot would not mark a pr as ready is the pr body contains `TEMPORARY_ISSUE_FAILURE_MARKER` Now, I think the pr bot should not mark the pr as ready if the temporary issue failure happens. And it's the easiest way to ensure the issue notifier would work well after the pr is integrated. ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1542844938 From erikj at openjdk.org Thu May 11 13:19:27 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 13:19:27 GMT Subject: RFR: 1909: Empty GET calls should be left empty Message-ID: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> Over the last week, we have had issues with JBS returning weird errors seemingly randomly, which has caused a lot of problems with the bots. It turns out our hosting provider has become more stringent with handling http/2 requests and no longer likes GET requests with a request body. Skara currently always fills in the body of a request, regardless of type, with an empty JSON document '{}' when the body is empty. This seems to be faulty behavior and we should let empty GET calls be empty instead. I have been running staging with this patch over night and there were no errors. ------------- Commit messages: - Try forcing GET body to null Changes: https://git.openjdk.org/skara/pull/1519/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1519&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1909 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1519.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1519/head:pull/1519 PR: https://git.openjdk.org/skara/pull/1519 From kcr at openjdk.org Thu May 11 13:51:42 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 11 May 2023 13:51:42 GMT Subject: RFR: 1909: Empty GET calls should be left empty In-Reply-To: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> References: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> Message-ID: On Thu, 11 May 2023 13:15:34 GMT, Erik Joelsson wrote: > Over the last week, we have had issues with JBS returning weird errors seemingly randomly, which has caused a lot of problems with the bots. It turns out our hosting provider has become more stringent with handling http/2 requests and no longer likes GET requests with a request body. Skara currently always fills in the body of a request, regardless of type, with an empty JSON document '{}' when the body is empty. This seems to be faulty behavior and we should let empty GET calls be empty instead. > > I have been running staging with this patch over night and there were no errors. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1519#pullrequestreview-1422631309 From tbell at openjdk.org Thu May 11 14:57:18 2023 From: tbell at openjdk.org (Tim Bell) Date: Thu, 11 May 2023 14:57:18 GMT Subject: RFR: 1909: Empty GET calls should be left empty In-Reply-To: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> References: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> Message-ID: On Thu, 11 May 2023 13:15:34 GMT, Erik Joelsson wrote: > Over the last week, we have had issues with JBS returning weird errors seemingly randomly, which has caused a lot of problems with the bots. It turns out our hosting provider has become more stringent with handling http/2 requests and no longer likes GET requests with a request body. Skara currently always fills in the body of a request, regardless of type, with an empty JSON document '{}' when the body is empty. This seems to be faulty behavior and we should let empty GET calls be empty instead. > > I have been running staging with this patch over night and there were no errors. Marked as reviewed by tbell (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1519#pullrequestreview-1422808754 From erikj at openjdk.org Thu May 11 15:26:34 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 15:26:34 GMT Subject: Integrated: 1909: Empty GET calls should be left empty In-Reply-To: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> References: <55kpSaqAKoJZ7bfDCYqsa9cOGRRTd_Phmm6LoCmfowA=.daf9f3ae-9ccc-4d4b-b54e-0b143372f78b@github.com> Message-ID: On Thu, 11 May 2023 13:15:34 GMT, Erik Joelsson wrote: > Over the last week, we have had issues with JBS returning weird errors seemingly randomly, which has caused a lot of problems with the bots. It turns out our hosting provider has become more stringent with handling http/2 requests and no longer likes GET requests with a request body. Skara currently always fills in the body of a request, regardless of type, with an empty JSON document '{}' when the body is empty. This seems to be faulty behavior and we should let empty GET calls be empty instead. > > I have been running staging with this patch over night and there were no errors. This pull request has now been integrated. Changeset: d62a0c07 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/d62a0c0702c06020f00b603aef2a6553c7912c63 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 1909: Empty GET calls should be left empty Reviewed-by: kcr, tbell ------------- PR: https://git.openjdk.org/skara/pull/1519 From erikj at openjdk.org Thu May 11 20:10:33 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 20:10:33 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure In-Reply-To: References: Message-ID: On Wed, 10 May 2023 21:42:20 GMT, Zhao Song wrote: > Now, I think the pr bot should not mark the pr as ready if the temporary issue failure happens. And it's the easiest way to ensure the issue notifier would work well after the pr is integrated. That's probably a good idea, but not enough to cover us here. When the ready label is added, this will trigger another `CheckWorkItem` (PullRequestBot will find the PR updated) and `CheckRun` (label change invalidates the cached metadata). It looks like that after `IntegrateCommand` is run, the `PullRequestCommandWorkItem` will not schedule another `CheckWorkItem`. Also the `PullRequestBot` will never schedule `CheckWorkItem` for a PR that isn't open, and the `CheckWorkItem` has an early exit if the PR is integrated. So, I think we need to make sure the PR cannot integrate with the TEMPORARY_ISSUE_FAILURE_MARKER present. ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1544608554 From erikj at openjdk.org Thu May 11 20:34:48 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 20:34:48 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 23:33:53 GMT, Zhao Song wrote: >> In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. >> >> Also, if the pr is integrated with the temporary issue failure, it would make the issue never get resolved. >> >> In this patch, the conditions for stopping notifiers have been tightened. Besides, the pr bot would not mark a pr as ready is the pr body contains `TEMPORARY_ISSUE_FAILURE_MARKER` > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > SKARA-1907 Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1518#pullrequestreview-1423389405 From zsong at openjdk.org Thu May 11 20:34:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 May 2023 20:34:48 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure [v2] In-Reply-To: References: Message-ID: On Wed, 10 May 2023 23:33:53 GMT, Zhao Song wrote: >> In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. >> >> Also, if the pr is integrated with the temporary issue failure, it would make the issue never get resolved. >> >> In this patch, the conditions for stopping notifiers have been tightened. Besides, the pr bot would not mark a pr as ready is the pr body contains `TEMPORARY_ISSUE_FAILURE_MARKER` > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > SKARA-1907 Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1544638706 From erikj at openjdk.org Thu May 11 20:34:48 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 20:34:48 GMT Subject: RFR: 1907: PR should not be integrated with the temporary issue failure In-Reply-To: References: Message-ID: On Thu, 11 May 2023 20:08:20 GMT, Erik Joelsson wrote: > > Now, I think the pr bot should not mark the pr as ready if the temporary issue failure happens. And it's the easiest way to ensure the issue notifier would work well after the pr is integrated. > > That's probably a good idea, but not enough to cover us here. When the ready label is added, this will trigger another `CheckWorkItem` (PullRequestBot will find the PR updated) and `CheckRun` (label change invalidates the cached metadata). It looks like that after `IntegrateCommand` is run, the `PullRequestCommandWorkItem` will not schedule another `CheckWorkItem`. Also the `PullRequestBot` will never schedule `CheckWorkItem` for a PR that isn't open, and the `CheckWorkItem` has an early exit if the PR is integrated. So, I think we need to make sure the PR cannot integrate with the TEMPORARY_ISSUE_FAILURE_MARKER present. >From our offline discussion you rightly pointed out that `CheckRun` will remove the `ready` label if the PR is ever considered not ready again, and there is no way for the `IntegrateCommand` to get to run unless the `ready` label is present, so your patch should be enough. ------------- PR Comment: https://git.openjdk.org/skara/pull/1518#issuecomment-1544636365 From zsong at openjdk.org Thu May 11 20:34:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 May 2023 20:34:48 GMT Subject: Integrated: 1907: PR should not be integrated with the temporary issue failure In-Reply-To: References: Message-ID: On Wed, 10 May 2023 18:12:20 GMT, Zhao Song wrote: > In SKARA-1899, we stopped all notifiers if the bot found temporary issue failure because we think it's just temporary issue failure and once the failure got resolved, the notifiers will be triggered again. However, it will introduce a new problem. If the pr is integrated when the temporary issue failure is happening, the notifiers will not be trigger again because the pr bot will not update integrated pr body. > > Also, if the pr is integrated with the temporary issue failure, it would make the issue never get resolved. > > In this patch, the conditions for stopping notifiers have been tightened. Besides, the pr bot would not mark a pr as ready is the pr body contains `TEMPORARY_ISSUE_FAILURE_MARKER` This pull request has now been integrated. Changeset: f4b77000 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/f4b7700009405aaf8c0d142cc3687f8c4fa95284 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 1907: PR should not be integrated with the temporary issue failure Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1518 From erikj at openjdk.org Thu May 11 21:09:07 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 May 2023 21:09:07 GMT Subject: RFR: 1905: Notify graal mailing list for JVMCI related PRs Message-ID: Add the new `graal` label to the auto label configuration for jvmci related paths. This will include the graal-dev mailinglist in PRs touching files in those paths. ------------- Commit messages: - SKARA-1905 Changes: https://git.openjdk.org/skara/pull/1520/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1520&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1905 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1520.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1520/head:pull/1520 PR: https://git.openjdk.org/skara/pull/1520 From dholmes at openjdk.org Fri May 12 06:51:09 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 12 May 2023 06:51:09 GMT Subject: RFR: 1905: Notify graal mailing list for JVMCI related PRs In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:05:23 GMT, Erik Joelsson wrote: > Add the new `graal` label to the auto label configuration for jvmci related paths. This will include the graal-dev mailinglist in PRs touching files in those paths. Just to be clear the mail will go to both graal and hotspot-compiler lists for the jvmci changes? ------------- PR Comment: https://git.openjdk.org/skara/pull/1520#issuecomment-1545258350 From erikj at openjdk.org Fri May 12 12:52:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 12:52:03 GMT Subject: RFR: 1905: Notify graal mailing list for JVMCI related PRs In-Reply-To: References: Message-ID: On Fri, 12 May 2023 06:49:01 GMT, David Holmes wrote: > Just to be clear the mail will go to both graal and hotspot-compiler lists for the jvmci changes? Yes, that is the intention. ------------- PR Comment: https://git.openjdk.org/skara/pull/1520#issuecomment-1545695171 From kcr at openjdk.org Fri May 12 17:53:40 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 12 May 2023 17:53:40 GMT Subject: RFR: 1905: Notify graal mailing list for JVMCI related PRs In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:05:23 GMT, Erik Joelsson wrote: > Add the new `graal` label to the auto label configuration for jvmci related paths. This will include the graal-dev mailinglist in PRs touching files in those paths. Marked as reviewed by kcr (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1520#pullrequestreview-1424934352 From iris at openjdk.org Fri May 12 18:03:25 2023 From: iris at openjdk.org (Iris Clark) Date: Fri, 12 May 2023 18:03:25 GMT Subject: RFR: 1905: Notify graal mailing list for JVMCI related PRs In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:05:23 GMT, Erik Joelsson wrote: > Add the new `graal` label to the auto label configuration for jvmci related paths. This will include the graal-dev mailinglist in PRs touching files in those paths. The changes themselves are fine. Looking at the graal-dev archives, I'm not seeing evidence that skara is currently sending e-mail to that list. Let me know if the poster password needs to be set. ------------- Marked as reviewed by iris (no project role). PR Review: https://git.openjdk.org/skara/pull/1520#pullrequestreview-1424947340 From erikj at openjdk.org Fri May 12 18:17:01 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 18:17:01 GMT Subject: Integrated: 1905: Notify graal mailing list for JVMCI related PRs In-Reply-To: References: Message-ID: On Thu, 11 May 2023 21:05:23 GMT, Erik Joelsson wrote: > Add the new `graal` label to the auto label configuration for jvmci related paths. This will include the graal-dev mailinglist in PRs touching files in those paths. This pull request has now been integrated. Changeset: 9ef33917 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/9ef3391701cf806e3674aa4b0625d093e7b59c10 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 1905: Notify graal mailing list for JVMCI related PRs Reviewed-by: kcr, iris ------------- PR: https://git.openjdk.org/skara/pull/1520 From erikj at openjdk.org Fri May 12 20:15:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 20:15:31 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge Message-ID: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. ------------- Commit messages: - SKARA-1910 Changes: https://git.openjdk.org/skara/pull/1521/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1521&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1910 Stats: 533 lines in 8 files changed: 485 ins; 43 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1521.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1521/head:pull/1521 PR: https://git.openjdk.org/skara/pull/1521 From zsong at openjdk.org Fri May 12 22:12:55 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 12 May 2023 22:12:55 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge In-Reply-To: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> Message-ID: On Fri, 12 May 2023 20:11:24 GMT, Erik Joelsson wrote: > This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. > > In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. In general, this patch looks good to me! Just a few minor problems. First, I think the new files need copyright header. Then, the GHA failed due to compile error, we need to import `org.openjdk.skara.cli.ForgeUtils` in `GitPrCreate` explicitly. Additionally, have you attempted to run a mirror bot using a BitBucket repo as the source on your local machine? If so, I believe this patch will work fine! ------------- PR Review: https://git.openjdk.org/skara/pull/1521#pullrequestreview-1425206546 From erikj at openjdk.org Fri May 12 23:00:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 23:00:41 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> Message-ID: <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> > This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. > > In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/skara/pull/1521/files - new: https://git.openjdk.org/skara/pull/1521/files/fd47ca78..0a81c6f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1521&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1521&range=00-01 Stats: 192 lines in 6 files changed: 139 ins; 51 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1521.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1521/head:pull/1521 PR: https://git.openjdk.org/skara/pull/1521 From erikj at openjdk.org Fri May 12 23:00:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 May 2023 23:00:47 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> Message-ID: On Fri, 12 May 2023 22:10:46 GMT, Zhao Song wrote: > In general, this patch looks good to me! Just a few minor problems. First, I think the new files need copyright header. Then, the GHA failed due to compile error, we need to import `org.openjdk.skara.cli.ForgeUtils` in `GitPrCreate` explicitly. Additionally, have you attempted to run a mirror bot using a BitBucket repo as the source on your local machine? If so, I believe this patch will work fine! Thanks the feedback! Added copyright, completely forgot about that. To fix ForgeUtils, I moved it to a new package called "internal" instead. It's not meant to be exported to other modules. Yes, I have run a local mirror configuration to verify the functionality. There isn't much of this that we have a model for automatic testing for. ------------- PR Comment: https://git.openjdk.org/skara/pull/1521#issuecomment-1546410866 From zsong at openjdk.org Tue May 16 15:27:31 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 16 May 2023 15:27:31 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> Message-ID: On Fri, 12 May 2023 23:00:41 GMT, Erik Joelsson wrote: >> This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. >> >> In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments LGTM ------------- Marked as reviewed by zsong (Committer). PR Review: https://git.openjdk.org/skara/pull/1521#pullrequestreview-1428854558 From ehelin at openjdk.org Tue May 16 19:08:26 2023 From: ehelin at openjdk.org (Erik Helin) Date: Tue, 16 May 2023 19:08:26 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> Message-ID: On Fri, 12 May 2023 23:00:41 GMT, Erik Joelsson wrote: >> This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. >> >> In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments A general comment regarding `ForgeUtils.configureSshKey`: I know this existing code, but I think a cleaner (and safer) solution would have been to stored the configuration in a separate file per host and then use `ssh -F /path/to/hosts/ssh/config/file`. Not worth thinking in this patch, but could be something for the future. Otherwise just stylistic nits and minor style suggestions. Overall nice work and cool to see it how easy it was to add a minimal new forge! forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketForgeFactory.java line 59: > 57: sshport = configuration.get("sshport").asInt(); > 58: } > 59: if (credential != null) { I would probably have used an `ssh` object in the config here, as in: if (configuration != null && configuration.contains("ssh")) { var ssh = configuration.get("ssh"); var key = ssh.get("key").asString(); var port = ssh.contains("port") ? ssh.get("port").asInt() : 22; } forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketHost.java line 55: > 53: this.sshPort = sshPort; > 54: this.credential = null; > 55: } It seems like credential cannot be `null` when `useSsh` is `true` (see the method `sshHostString`). Maybe the constructors should reflect this? Or use static factory methods like `BitBucketHost.withSSH` and/or `BitBucketHost.withPAT`? forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketRepository.java line 51: > 49: > 50: public class BitbucketRepository implements HostedRepository { > 51: private final BitbucketHost bitbucketHost; I would have named the field just `host`. forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketRepository.java line 52: > 50: public class BitbucketRepository implements HostedRepository { > 51: private final BitbucketHost bitbucketHost; > 52: private final String repositoryName; And here I would have just used the field `name` ? ------------- Marked as reviewed by ehelin (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1521#pullrequestreview-1429220805 PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195575871 PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195578593 PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195579327 PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195579689 From ehelin at openjdk.org Tue May 16 19:10:46 2023 From: ehelin at openjdk.org (Erik Helin) Date: Tue, 16 May 2023 19:10:46 GMT Subject: RFR: 1902: Log response code when response body cannot be parsed In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:43:38 GMT, Erik Joelsson wrote: > This patch adds better logging of response status codes when things fail. Looks good! ------------- Marked as reviewed by ehelin (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1514#pullrequestreview-1429237320 From erikj at openjdk.org Tue May 16 20:06:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 May 2023 20:06:23 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> Message-ID: <3u3weGD3ISLIQcpJ8M05G06vo_ab342Uo3YAMtLs0Eo=.dc43ffba-0c2c-4b14-87de-3c27b544df8a@github.com> On Tue, 16 May 2023 18:57:12 GMT, Erik Helin wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketForgeFactory.java line 59: > >> 57: sshport = configuration.get("sshport").asInt(); >> 58: } >> 59: if (credential != null) { > > I would probably have used an `ssh` object in the config here, as in: > > > if (configuration != null && configuration.contains("ssh")) { > var ssh = configuration.get("ssh"); > var key = ssh.get("key").asString(); > var port = ssh.contains("port") ? ssh.get("port").asInt() : 22; > } I did think of that, but decided against changing the config format in this change. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195640362 From erikj at openjdk.org Tue May 16 20:14:28 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 May 2023 20:14:28 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> Message-ID: On Tue, 16 May 2023 19:00:01 GMT, Erik Helin wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketHost.java line 55: > >> 53: this.sshPort = sshPort; >> 54: this.credential = null; >> 55: } > > It seems like credential cannot be `null` when `useSsh` is `true` (see the method `sshHostString`). Maybe the constructors should reflect this? Or use static factory methods like `BitBucketHost.withSSH` and/or `BitBucketHost.withPAT`? I more or less copy pasted the existing gitlab implementation here so this is following the same existing patterns. The same relationship between useSsh and credential are present there too. I agree it could be made neater with a builder pattern like most other factories do, or static factory methods. > forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketRepository.java line 51: > >> 49: >> 50: public class BitbucketRepository implements HostedRepository { >> 51: private final BitbucketHost bitbucketHost; > > I would have named the field just `host`. Right, again copy paste and just mindlessly modifying the field names. This I will adjust. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195646665 PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195647115 From erikj at openjdk.org Tue May 16 20:33:21 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 May 2023 20:33:21 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v3] In-Reply-To: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> Message-ID: <5l3rN15oF-mOHt848ODt3q6qN4cWCDrbdpfnisHceU0=.3f4ea01e-9a8e-4184-86d6-ccd8dab59835@github.com> > This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. > > In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Review followup ------------- Changes: - all: https://git.openjdk.org/skara/pull/1521/files - new: https://git.openjdk.org/skara/pull/1521/files/0a81c6f6..c3977cc1 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1521&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1521&range=01-02 Stats: 34 lines in 3 files changed: 5 ins; 12 del; 17 mod Patch: https://git.openjdk.org/skara/pull/1521.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1521/head:pull/1521 PR: https://git.openjdk.org/skara/pull/1521 From erikj at openjdk.org Tue May 16 20:33:21 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 May 2023 20:33:21 GMT Subject: RFR: 1910: Basic support for Bitbucket as a Forge [v2] In-Reply-To: References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> <2wdGyd8yztGTlBX2cqc6aAIvdiG2I1FSuQXGj0J4nzw=.a6455aa4-123d-4520-afba-05b91526efb6@github.com> Message-ID: <9wp28ucTvSFlCUIxK6pud_5RVp-ArNnRItoEukwG4DE=.d68403c2-e993-4426-864b-caa625358d06@github.com> On Tue, 16 May 2023 20:11:42 GMT, Erik Joelsson wrote: >> forge/src/main/java/org/openjdk/skara/forge/bitbucket/BitbucketHost.java line 55: >> >>> 53: this.sshPort = sshPort; >>> 54: this.credential = null; >>> 55: } >> >> It seems like credential cannot be `null` when `useSsh` is `true` (see the method `sshHostString`). Maybe the constructors should reflect this? Or use static factory methods like `BitBucketHost.withSSH` and/or `BitBucketHost.withPAT`? > > I more or less copy pasted the existing gitlab implementation here so this is following the same existing patterns. The same relationship between useSsh and credential are present there too. I agree it could be made neater with a builder pattern like most other factories do, or static factory methods. I decided to make it simpler by just removing the second constructor and let the factory deal with requiring credentials for ssh. Having two constructors didn't really make sense anymore as no API calls to bitbucket were needed. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1521#discussion_r1195662560 From erikj at openjdk.org Tue May 16 20:37:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 16 May 2023 20:37:03 GMT Subject: RFR: 1902: Log response code when response body cannot be parsed [v2] In-Reply-To: References: Message-ID: <7Hu3uqA32l_UCvHa9PfveRR9upR4hnNUa8bbjSPOixU=.94691327-dd95-4da2-8dd8-81f0d87a4b5d@github.com> > This patch adds better logging of response status codes when things fail. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Improve logging of UncheckedRestException in BotRunner - Merge branch 'master' into SKARA-1902-status-code-json - SKARA-1902 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1514/files - new: https://git.openjdk.org/skara/pull/1514/files/7a480353..42472474 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1514&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1514&range=00-01 Stats: 735 lines in 37 files changed: 588 ins; 38 del; 109 mod Patch: https://git.openjdk.org/skara/pull/1514.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1514/head:pull/1514 PR: https://git.openjdk.org/skara/pull/1514 From erikj at openjdk.org Wed May 17 14:05:33 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 17 May 2023 14:05:33 GMT Subject: Integrated: 1902: Log response code when response body cannot be parsed In-Reply-To: References: Message-ID: On Fri, 5 May 2023 21:43:38 GMT, Erik Joelsson wrote: > This patch adds better logging of response status codes when things fail. This pull request has now been integrated. Changeset: ca9a5c5e Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/ca9a5c5e870755a15976dd2350bbc6bbfef94021 Stats: 15 lines in 3 files changed: 9 ins; 0 del; 6 mod 1902: Log response code when response body cannot be parsed Reviewed-by: zsong, ehelin ------------- PR: https://git.openjdk.org/skara/pull/1514 From erikj at openjdk.org Wed May 17 14:06:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 17 May 2023 14:06:47 GMT Subject: Integrated: 1910: Basic support for Bitbucket as a Forge In-Reply-To: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> References: <91UtQprMmpS5G4QmLN7ndqjkUbXtqlmT4TZ3XKyauhg=.0da2cae0-687c-474c-893d-2faf843d63ae@github.com> Message-ID: On Fri, 12 May 2023 20:11:24 GMT, Erik Joelsson wrote: > This patch adds very basic support for Bitbucket as a Forge, just enough to be able to use a Bitbucket repo as the source for mirroring. > > In order to support ssh for bitbucket, I moved the `configureSshKey` method from `GitLabForgeFactory` to a new utility class, so that it could be shared more easily. This pull request has now been integrated. Changeset: 0c0b5069 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/0c0b5069ded931a912d2dc910b8b8af9880b423f Stats: 614 lines in 8 files changed: 566 ins; 43 del; 5 mod 1910: Basic support for Bitbucket as a Forge Reviewed-by: zsong, ehelin ------------- PR: https://git.openjdk.org/skara/pull/1521 From zsong at openjdk.org Fri May 19 18:22:14 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 May 2023 18:22:14 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled Message-ID: When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. Erik investigated it and found the root cause. In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. In this patch, some fields will be filtered out before comparing the jsons. ------------- Commit messages: - SKARA-1914 Changes: https://git.openjdk.org/skara/pull/1522/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1522&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1914 Stats: 33 lines in 2 files changed: 30 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1522.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/skara/pull/1522 From erikj at openjdk.org Fri May 19 20:41:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 May 2023 20:41:18 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled In-Reply-To: References: Message-ID: On Fri, 19 May 2023 18:16:24 GMT, Zhao Song wrote: > When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. > > Erik investigated it and found the root cause. > > In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. > > Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. > > In this patch, some fields will be filtered out before comparing the jsons. I think this looks ok, but do you think you could write at least a manual test in `JiraProjectTests`? Let me know if you need helping setting up the environment to get such a test running. ------------- PR Review: https://git.openjdk.org/skara/pull/1522#pullrequestreview-1435087784 From zsong at openjdk.org Fri May 19 20:46:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 May 2023 20:46:23 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled In-Reply-To: References: Message-ID: On Fri, 19 May 2023 20:39:11 GMT, Erik Joelsson wrote: > I think this looks ok, but do you think you could write at least a manual test in `JiraProjectTests`? Let me know if you need helping setting up the environment to get such a test running. I have tried this patch in staging, but I think you are right, it's better to add a manual test. ------------- PR Comment: https://git.openjdk.org/skara/pull/1522#issuecomment-1555226190 From zsong at openjdk.org Fri May 19 22:29:35 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 May 2023 22:29:35 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled [v2] In-Reply-To: References: Message-ID: > When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. > > Erik investigated it and found the root cause. > > In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. > > Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. > > In this patch, some fields will be filtered out before comparing the jsons. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1522/files - new: https://git.openjdk.org/skara/pull/1522/files/15c157d1..16ff6694 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1522&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1522&range=00-01 Stats: 22 lines in 3 files changed: 18 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1522.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/skara/pull/1522 From zsong at openjdk.org Fri May 19 23:18:50 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 May 2023 23:18:50 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled [v3] In-Reply-To: References: Message-ID: <09E5DilS6bhUKqhHpI9H_VMewFUNxeMOt8jGxdA9gJo=.58948131-53a2-4f40-bde4-18987d26722d@github.com> > When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. > > Erik investigated it and found the root cause. > > In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. > > Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. > > In this patch, some fields will be filtered out before comparing the jsons. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1522/files - new: https://git.openjdk.org/skara/pull/1522/files/16ff6694..dd45d5b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1522&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1522&range=01-02 Stats: 16 lines in 2 files changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1522.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1522/head:pull/1522 PR: https://git.openjdk.org/skara/pull/1522 From erikj at openjdk.org Mon May 22 12:55:33 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 22 May 2023 12:55:33 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled [v3] In-Reply-To: <09E5DilS6bhUKqhHpI9H_VMewFUNxeMOt8jGxdA9gJo=.58948131-53a2-4f40-bde4-18987d26722d@github.com> References: <09E5DilS6bhUKqhHpI9H_VMewFUNxeMOt8jGxdA9gJo=.58948131-53a2-4f40-bde4-18987d26722d@github.com> Message-ID: On Fri, 19 May 2023 23:18:50 GMT, Zhao Song wrote: >> When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. >> >> Erik investigated it and found the root cause. >> >> In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. >> >> Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. >> >> In this patch, some fields will be filtered out before comparing the jsons. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fix test Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1522#pullrequestreview-1436568266 From zsong at openjdk.org Mon May 22 16:16:33 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 22 May 2023 16:16:33 GMT Subject: RFR: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled [v3] In-Reply-To: <09E5DilS6bhUKqhHpI9H_VMewFUNxeMOt8jGxdA9gJo=.58948131-53a2-4f40-bde4-18987d26722d@github.com> References: <09E5DilS6bhUKqhHpI9H_VMewFUNxeMOt8jGxdA9gJo=.58948131-53a2-4f40-bde4-18987d26722d@github.com> Message-ID: <1e5EdjaYJYo_XfBviNHI8JUj0f5C_-sG81AzfuNSeXc=.bc065061-8a38-4fd0-b38e-b9fa50c3ab91@github.com> On Fri, 19 May 2023 23:18:50 GMT, Zhao Song wrote: >> When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. >> >> Erik investigated it and found the root cause. >> >> In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. >> >> Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. >> >> In this patch, some fields will be filtered out before comparing the jsons. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fix test Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1522#issuecomment-1557516999 From zsong at openjdk.org Mon May 22 16:16:34 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 22 May 2023 16:16:34 GMT Subject: Integrated: 1914: IssuePoller always returns the most recently updated issue even if it has already been handled In-Reply-To: References: Message-ID: On Fri, 19 May 2023 18:16:24 GMT, Zhao Song wrote: > When I was testing with [SKARA-1912](https://bugs.openjdk.org/browse/SKARA-1912), I observed an issue in the IssuePoller. Although some updated csr issues has been handled in the previous round, the most recently updated csr issue would be returned again in the next round. Therefore, this would trigger the CSRIssueWorkItem and CheckWorkItem to update the PR very frequently. > > Erik investigated it and found the root cause. > > In the IssuePoller#updatedIssues, the poller first queries for updated issues (which may include some handled issues due to the imprecise timestamp, measured in minutes). Subsequently, the poller checks whether the issues have been really updated by comparing them with their copies using JiraIssue#equals. In this method, we compare the json of the issue with our own copy. If the issues are really updated, the poller returns them. > > Originally, the JiraIssue#equals method worked well. However, now, when the poller uses the REST API to retrieve the JSON of the issue, it includes a field called "customfield_11700," which represents the "Development" field used by Jira to display data quickly and easily in the issues. Within this field, there are various objects, such as "[SummaryItemBean at 5e105688](mailto:SummaryItemBean at 5e105688)." These objects change each time the poller makes a query. Therefore, even if the issue has not actually been updated, the JiraIssue#equals method will return false. > > In this patch, some fields will be filtered out before comparing the jsons. This pull request has now been integrated. Changeset: 63d149ad Author: Zhao Song URL: https://git.openjdk.org/skara/commit/63d149adb0a4b4640875f9a6462f6bc2c5f60340 Stats: 63 lines in 5 files changed: 56 ins; 0 del; 7 mod 1914: IssuePoller always returns the most recently updated issue even if it has already been handled Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1522 From zsong at openjdk.org Mon May 22 22:48:01 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 22 May 2023 22:48:01 GMT Subject: RFR: 1912: Show priority for bugs in pull request body Message-ID: The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. ------------- Commit messages: - fix log - fix a problem - fix some problems - fix a problem - fix a problem - Merge branch 'master' into SKARA-1912 - fix some problems - fix a problem - SKARA-1912 version1 Changes: https://git.openjdk.org/skara/pull/1523/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1523&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1912 Stats: 1388 lines in 20 files changed: 1097 ins; 52 del; 239 mod Patch: https://git.openjdk.org/skara/pull/1523.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1523/head:pull/1523 PR: https://git.openjdk.org/skara/pull/1523 From erikj at openjdk.org Tue May 23 16:39:50 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 16:39:50 GMT Subject: RFR: 1912: Show priority for bugs in pull request body In-Reply-To: References: Message-ID: On Mon, 22 May 2023 21:53:03 GMT, Zhao Song wrote: > The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). > > As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. > > To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. > > So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. > > Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. This is a big change that will likely take a few rounds of review before we get it right. I have made a first pass and left comments mostly about higher level structural issues. In addition to the below, I think it may be worth thinking about how we can minimize the amount of times we fetch the same issue from an IssueProject. Can we perhaps cache them in CheckWorkItem to avoid repeated fetching? (accidental double post) bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRIssueWorkItem.java line 102: > 100: .flatMap(id -> bot.repositories().stream() > 101: .filter(r -> r.name().equals(id.split("#")[0])) > 102: .map(r -> r.pullRequest(id.split("#")[1])) I would suggest storing a better type than `String` in the issuePRMap so we don't have to parse it. Storing the full PullRequest object is a bit wasteful and could get confusing, but you could create a small `record` with just the repository name and pull request id. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 707: > 705: } else { > 706: progressBody.append(" (?? Uncommon issue type: " + issueType.asString() + ")"); > 707: currentIssues.add(iss.get().id()); This should all just be in one `else` clause where the priority is printed. The issue types `CSR` and `JEP` are the only exceptions where we don't need to print priority. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 324: > 322: > 323: private void initializeIssuePRMap() { > 324: // When bot restarts, the issuePRMap needs to get updated with this pr I'm not sure about this comment. This mapping needs to be updated every time there is a change to the associations, or if the map is currently missing associations for this PR. I don't think it makes sense to maintain an `initializedPRs` map, we should just always update the map. This update process needs to be synchronized. The map is a `ConcurrentHashMap`, which is good, but we need to synchronize on the list value before trying to manipulate it. bots/pr/src/main/java/org/openjdk/skara/bots/pr/IssueWorkItem.java line 82: > 80: > 81: @Override > 82: public Collection run(Path scratchPath) { I don't think we need a separate IssueWorkItem. The reason for the `CSRIssueWorkItem` is that we need to do potentially expensive work for each CSR issue found to translate them into `CheckWorkItem` (follow multiple issue links through queries). In this IssueWorkItem, all we need to do is look up the issue ID in an in-memory map, which is very cheap. That can easily be done in a loop in `bot.getPeriodicItems` without risking it taking too long. ------------- PR Review: https://git.openjdk.org/skara/pull/1523#pullrequestreview-1439642252 PR Review: https://git.openjdk.org/skara/pull/1523#pullrequestreview-1440169869 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202283150 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202311811 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202672067 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202680765 From zsong at openjdk.org Tue May 23 16:56:47 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 16:56:47 GMT Subject: RFR: 1912: Show priority for bugs in pull request body In-Reply-To: References: Message-ID: On Tue, 23 May 2023 12:57:42 GMT, Erik Joelsson wrote: >> The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). >> >> As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. >> >> To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. >> >> So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. >> >> Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRIssueWorkItem.java line 102: > >> 100: .flatMap(id -> bot.repositories().stream() >> 101: .filter(r -> r.name().equals(id.split("#")[0])) >> 102: .map(r -> r.pullRequest(id.split("#")[1])) > > I would suggest storing a better type than `String` in the issuePRMap so we don't have to parse it. Storing the full PullRequest object is a bit wasteful and could get confusing, but you could create a small `record` with just the repository name and pull request id. It's a good idea. Will do it. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202711692 From zsong at openjdk.org Tue May 23 16:59:12 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 16:59:12 GMT Subject: RFR: 1912: Show priority for bugs in pull request body In-Reply-To: References: Message-ID: <2-l00Fud6W0JhIjM8mMYg-e2s3R17hZ6CACfyNucWWE=.a209506a-5d1d-4087-a85a-86867410685f@github.com> On Tue, 23 May 2023 13:15:05 GMT, Erik Joelsson wrote: >> The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). >> >> As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. >> >> To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. >> >> So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. >> >> Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 707: > >> 705: } else { >> 706: progressBody.append(" (?? Uncommon issue type: " + issueType.asString() + ")"); >> 707: currentIssues.add(iss.get().id()); > > This should all just be in one `else` clause where the priority is printed. The issue types `CSR` and `JEP` are the only exceptions where we don't need to print priority. Ah, I do this because in the bug description, Erik D's demo code only show priority for `Bug`. I will fix it. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202714997 From zsong at openjdk.org Tue May 23 17:13:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 17:13:05 GMT Subject: RFR: 1912: Show priority for bugs in pull request body In-Reply-To: References: Message-ID: On Tue, 23 May 2023 16:26:13 GMT, Erik Joelsson wrote: >> The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). >> >> As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. >> >> To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. >> >> So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. >> >> Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 324: > >> 322: >> 323: private void initializeIssuePRMap() { >> 324: // When bot restarts, the issuePRMap needs to get updated with this pr > > I'm not sure about this comment. This mapping needs to be updated every time there is a change to the associations, or if the map is currently missing associations for this PR. I don't think it makes sense to maintain an `initializedPRs` map, we should just always update the map. > > This update process needs to be synchronized. The map is a `ConcurrentHashMap`, which is good, but we need to synchronize on the list value before trying to manipulate it. I make the bot maintaining the` initializedPRs` map because I think there is no need to always update the map here. We only need to update the map here when the bot restarts and it's the first time for the bot to see this pr. Otherwise, the update is extra work. The real update for the map located in `CheckRun#getStatusMessage` from line 744 to 768. And yes, I need to synchronize on the list value before trying to manipulate it. Thanks for catching! > bots/pr/src/main/java/org/openjdk/skara/bots/pr/IssueWorkItem.java line 82: > >> 80: >> 81: @Override >> 82: public Collection run(Path scratchPath) { > > I don't think we need a separate IssueWorkItem. The reason for the `CSRIssueWorkItem` is that we need to do potentially expensive work for each CSR issue found to translate them into `CheckWorkItem` (follow multiple issue links through queries). In this IssueWorkItem, all we need to do is look up the issue ID in an in-memory map, which is very cheap. That can easily be done in a loop in `bot.getPeriodicItems` without risking it taking too long. Yes, it makes sense. Will fix it. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202729733 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202732518 From zsong at openjdk.org Tue May 23 21:08:55 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 21:08:55 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: > The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). > > As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. > > To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. > > So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. > > Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. Zhao Song has updated the pull request incrementally with seven additional commits since the last revision: - fix some problems - fix a problem - delete IssueWorkItem - change initializedPR to set - fix synchronization - print priority for all issues except CSR and JEP - introduce PRRecord ------------- Changes: - all: https://git.openjdk.org/skara/pull/1523/files - new: https://git.openjdk.org/skara/pull/1523/files/03b5dd6e..bceec0e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1523&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1523&range=00-01 Stats: 296 lines in 14 files changed: 102 ins; 140 del; 54 mod Patch: https://git.openjdk.org/skara/pull/1523.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1523/head:pull/1523 PR: https://git.openjdk.org/skara/pull/1523 From zsong at openjdk.org Tue May 23 21:08:55 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 21:08:55 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 16:37:23 GMT, Erik Joelsson wrote: > This is a big change that will likely take a few rounds of review before we get it right. I have made a first pass and left comments mostly about higher level structural issues. > > In addition to the below, I think it may be worth thinking about how we can minimize the amount of times we fetch the same issue from an IssueProject. Can we perhaps cache them in CheckWorkItem to avoid repeated fetching? I think I have resolved most of the issues mentioned by you. And yes, it's possible for us to cache the issues, but I need more time to think about it, also, I think this patch is big enough. If you don't mind, I prefer to file a separate issue for this. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 77: > >> 75: private final boolean enableBackport; >> 76: private final Map> issuePRMap; >> 77: private final Map initializedPRs = new ConcurrentHashMap<>(); > > This could just be a `Set`. Also it doesn't need to be concurrent as it's local to just this PullRequestBot, and we don't run WorkItems for the same PR in parallel. Ah, right! Thanks! ------------- PR Comment: https://git.openjdk.org/skara/pull/1523#issuecomment-1560121276 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202812618 From erikj at openjdk.org Tue May 23 21:08:56 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 21:08:56 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 17:08:41 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 324: >> >>> 322: >>> 323: private void initializeIssuePRMap() { >>> 324: // When bot restarts, the issuePRMap needs to get updated with this pr >> >> I'm not sure about this comment. This mapping needs to be updated every time there is a change to the associations, or if the map is currently missing associations for this PR. I don't think it makes sense to maintain an `initializedPRs` map, we should just always update the map. >> >> This update process needs to be synchronized. The map is a `ConcurrentHashMap`, which is good, but we need to synchronize on the list value before trying to manipulate it. > > I make the bot maintaining the` initializedPRs` map because I think there is no need to always update the map here. We only need to update the map here when the bot restarts and it's the first time for the bot to see this pr. Otherwise, the update is extra work. > > The real update for the map located in `CheckRun#getStatusMessage` from line 744 to 768. > > And yes, I need to synchronize on the list value before trying to manipulate it. Thanks for catching! Ah, I missed that part, that's good. With multiple locations doing updates to the map, I would recommend adding methods `addIssuePrMapping` and `removeIssuePrMapping` to `PullRequestBot` so you can encapsulate the dealing with lists and synchronization. Probably also `getIssuePrMapping`. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202771907 From erikj at openjdk.org Tue May 23 21:08:56 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 21:08:56 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 21:04:28 GMT, Zhao Song wrote: >> The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). >> >> As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. >> >> To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. >> >> So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. >> >> Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. > > Zhao Song has updated the pull request incrementally with seven additional commits since the last revision: > > - fix some problems > - fix a problem > - delete IssueWorkItem > - change initializedPR to set > - fix synchronization > - print priority for all issues except CSR and JEP > - introduce PRRecord bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 77: > 75: private final boolean enableBackport; > 76: private final Map> issuePRMap; > 77: private final Map initializedPRs = new ConcurrentHashMap<>(); This could just be a `Set`. Also it doesn't need to be concurrent as it's local to just this PullRequestBot, and we don't run WorkItems for the same PR in parallel. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1202797620 From erikj at openjdk.org Tue May 23 22:15:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 22:15:15 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 21:08:55 GMT, Zhao Song wrote: >> The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). >> >> As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. >> >> To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. >> >> So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. >> >> Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. > > Zhao Song has updated the pull request incrementally with seven additional commits since the last revision: > > - fix some problems > - fix a problem > - delete IssueWorkItem > - change initializedPR to set > - fix synchronization > - print priority for all issues except CSR and JEP > - introduce PRRecord bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java line 44: > 42: } > 43: > 44: public static Set parseIssues(String body) { If this method is made public in the common module, then it needs a bit of documentation about what it does (parses issues from PR body and filters out JEP and CSR) and what it returns (list of issue IDs). bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 756: > 754: } > 755: } > 756: log.info("Map after updated: " + workItem.bot.issuePRMap()); Logging the whole map here is probably not a good idea in production. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 331: > 329: } > 330: bot.initializedPRs().add(prId); > 331: log.info("Map after initialization with pr " + pr.id() + " : " + bot.issuePRMap()); Same here regarding logging. The map will get huge in production. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PRRecord.java line 65: > 63: return repoName + "#" + prId; > 64: } > 65: } With record I meant actually using the new record feature. It's pretty neat. Suggestion: public record PRRecord(String repoName, String prId); bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 339: > 337: issuePRMap.putIfAbsent(issueId, new LinkedList<>()); > 338: synchronized (issuePRMap.get(issueId)) { > 339: List prRecords = issuePRMap.get(issueId); I would suggest only fetching the list once and then synchronizing on it. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203063932 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203076801 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203079797 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203066945 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203068522 From erikj at openjdk.org Tue May 23 22:15:14 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 22:15:14 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 21:03:51 GMT, Zhao Song wrote: > > This is a big change that will likely take a few rounds of review before we get it right. I have made a first pass and left comments mostly about higher level structural issues. > > In addition to the below, I think it may be worth thinking about how we can minimize the amount of times we fetch the same issue from an IssueProject. Can we perhaps cache them in CheckWorkItem to avoid repeated fetching? > > I think I have resolved most of the issues mentioned by you. And yes, it's possible for us to cache the issues, but I need more time to think about it, also, I think this patch is big enough. If you don't mind, I prefer to file a separate issue for this. That's ok, we can leave that as an optimization for later. ------------- PR Comment: https://git.openjdk.org/skara/pull/1523#issuecomment-1560195699 From zsong at openjdk.org Tue May 23 22:23:08 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 22:23:08 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 21:55:25 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with seven additional commits since the last revision: >> >> - fix some problems >> - fix a problem >> - delete IssueWorkItem >> - change initializedPR to set >> - fix synchronization >> - print priority for all issues except CSR and JEP >> - introduce PRRecord > > bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java line 44: > >> 42: } >> 43: >> 44: public static Set parseIssues(String body) { > > If this method is made public in the common module, then it needs a bit of documentation about what it does (parses issues from PR body and filters out JEP and CSR) and what it returns (list of issue IDs). Sure. Will add some comments > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 756: > >> 754: } >> 755: } >> 756: log.info("Map after updated: " + workItem.bot.issuePRMap()); > > Logging the whole map here is probably not a good idea in production. Ok, I will remove it. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PRRecord.java line 65: > >> 63: return repoName + "#" + prId; >> 64: } >> 65: } > > With record I meant actually using the new record feature. It's pretty neat. > Suggestion: > > public record PRRecord(String repoName, String prId); Oh, I didn't know Java had this feature before. I will use it! Thanks! > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 339: > >> 337: issuePRMap.putIfAbsent(issueId, new LinkedList<>()); >> 338: synchronized (issuePRMap.get(issueId)) { >> 339: List prRecords = issuePRMap.get(issueId); > > I would suggest only fetching the list once and then synchronizing on it. Sure ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203087858 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203091012 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203089495 PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203090368 From zsong at openjdk.org Tue May 23 22:43:30 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 22:43:30 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 18:15:40 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 77: >> >>> 75: private final boolean enableBackport; >>> 76: private final Map> issuePRMap; >>> 77: private final Map initializedPRs = new ConcurrentHashMap<>(); >> >> This could just be a `Set`. Also it doesn't need to be concurrent as it's local to just this PullRequestBot, and we don't run WorkItems for the same PR in parallel. > > Ah, right! Thanks! Think again about this, It's possible that CheckWorkItems for different PRs in the same repo run in parallel. Every CheckWorkItem is possible to modify `initializedPRs`. So we still need synchronize it. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203110581 From erikj at openjdk.org Tue May 23 23:03:24 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 23 May 2023 23:03:24 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 22:41:11 GMT, Zhao Song wrote: >> Ah, right! Thanks! > > Think again about this, It's possible that CheckWorkItems for different PRs in the same repo run in parallel. Every CheckWorkItem is possible to modify `initializedPRs`. So we still need to synchronize it. You are right, the map will be concurrently modified, just not the same element, and that requires a `ConcurrentHashMap` or synchronization to avoid corrupting data. I think `ConcurrentHashMap` is preferred here as I don't think there is a concurrent Set. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203124773 From zsong at openjdk.org Tue May 23 23:03:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 23:03:24 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v2] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 22:58:36 GMT, Erik Joelsson wrote: >> Think again about this, It's possible that CheckWorkItems for different PRs in the same repo run in parallel. Every CheckWorkItem is possible to modify `initializedPRs`. So we still need to synchronize it. > > You are right, the map will be concurrently modified, just not the same element, and that requires a `ConcurrentHashMap` or synchronization to avoid corrupting data. I think `ConcurrentHashMap` is preferred here as I don't think there is a concurrent Set. Yes, I will change it back ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1523#discussion_r1203126861 From zsong at openjdk.org Tue May 23 23:11:27 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 23 May 2023 23:11:27 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v3] In-Reply-To: References: Message-ID: > The initial purpose of this issue is to show priority for bugs in the issue list in the pull request body. However, with current pr bot, if the user changes the type of the issue or the priority of the issue in the JBS, the changes will not be reflected in the PR body unless there is something could trigger the CheckWorkItem(like user edits the PR title and user issues some commands). > > As Erik.J suggested, we could maintain a map(from JBS issue to the PRs related with this issue) in memory, so if the issue gets updated, we could know which pr needs to be updated. > > To query updated issues and handle them, a new bot called `IssueBot` is introduced. This bot would query for updated issues(exclude CSR and JEP) in JBS, and it will read the in memory map to know whether there is any pr needs to be updated. If so, it will generate `CheckWorkItem` for that pr. > > So currently, there are two ways to generate `CheckWorkItem`. Updated issues and updated pull requests. Previously, in the `CheckWorkItem`, we would check the metadata of the pull request and if the metadata is up to date, `jcheck` would not be triggered. Now, we could check the metadata of the pull request and the issues related to this pr, but it would be too expensive because if only the pull request is updated, we also need to fetch all the issues from JBS to just generate the metadata. Therefore, in this patch, metadata is split to two parts, one part for pull request and one part for issues. If the `CheckWorkItem` is spawned from an updated pull request, we will only check pr metadata. On the other hand, if the `CheckWorkItem` is spawned from an updated issue, we will only check issues metadata. > > Besides, since the map is in-memory, so if the bot restarts, the map needs to be initialized. When bot restarts, a `CheckWorkItem` would be generated for each pr, so the initialization is in `CheckWorkItem`. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - Change initializedPRs back to ConcurrentHashMap - fix some problems ------------- Changes: - all: https://git.openjdk.org/skara/pull/1523/files - new: https://git.openjdk.org/skara/pull/1523/files/bceec0e8..530d910b Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1523&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1523&range=01-02 Stats: 58 lines in 5 files changed: 6 ins; 41 del; 11 mod Patch: https://git.openjdk.org/skara/pull/1523.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1523/head:pull/1523 PR: https://git.openjdk.org/skara/pull/1523 From erik.joelsson at oracle.com Wed May 24 14:19:13 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 24 May 2023 07:19:13 -0700 Subject: Result: New Skara Reviewer: Zhao Song Message-ID: <65e53530-2818-74d9-89e3-eda8d3873118@oracle.com> Voting for Zhao Song [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Erik Joelsson [1] https://mail.openjdk.org/pipermail/skara-dev/2023-May/007870.html