From lgxbslgx at gmail.com Thu Jun 1 11:27:01 2023 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 1 Jun 2023 19:27:01 +0800 Subject: SKARA creates a backport issue unexpectedly Message-ID: Hi all, The `Fix Version` of the JDK-8288619 [1] was incorrectly set to 22. It should be 21 actually. Then when its patch [3] was integrated, the SKARA created a backport issue [2] with `Fix Version` as 21. This problem only occurs about two weeks before the Rampdown Phase One [4]. Is it intentional? Or a bug? Best Regards, -- Guoxiong [1] https://bugs.openjdk.org/browse/JDK-8288619 [2] https://bugs.openjdk.org/browse/JDK-8308818 [3] https://github.com/openjdk/jdk/pull/13888 [4] https://openjdk.org/projects/jdk/21/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Jun 1 14:21:27 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 1 Jun 2023 07:21:27 -0700 Subject: SKARA creates a backport issue unexpectedly In-Reply-To: References: Message-ID: Hello Guoxiong, Skara is acting as expected given the circumstances. If a user has set a Fix Version on an issue, Skara will not overwrite that. I don't think we can change this. /Erik On 6/1/23 04:27, Guoxiong Li wrote: > Hi all, > > The `Fix Version` of the JDK-8288619?[1] was incorrectly set to 22. > It should be 21 actually. Then when its patch [3] was integrated, > the SKARA created a backport issue [2] with `Fix Version` as 21. > > This problem only occurs about two weeks before the Rampdown Phase One > [4]. > Is it intentional? Or a bug? > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.org/browse/JDK-8288619 > [2] https://bugs.openjdk.org/browse/JDK-8308818 > [3] https://github.com/openjdk/jdk/pull/13888 > [4] https://openjdk.org/projects/jdk/21/ From lgxbslgx at gmail.com Thu Jun 1 14:27:11 2023 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 1 Jun 2023 22:27:11 +0800 Subject: SKARA creates a backport issue unexpectedly In-Reply-To: References: Message-ID: Thanks for the quick reply. Got it. Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Thu Jun 1 14:46:45 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 1 Jun 2023 07:46:45 -0700 Subject: SKARA creates a backport issue unexpectedly In-Reply-To: References: Message-ID: See the OpenJDK developer's guide [1] for more information regarding this case. -- Kevin [1] https://openjdk.org/guide/#how-to-fix-an-incorrect-backport-creation-in-jbs On 6/1/2023 7:21 AM, erik.joelsson at oracle.com wrote: > Hello Guoxiong, > > Skara is acting as expected given the circumstances. If a user has set > a Fix Version on an issue, Skara will not overwrite that. I don't > think we can change this. > > /Erik > > On 6/1/23 04:27, Guoxiong Li wrote: >> Hi all, >> >> The `Fix Version` of the JDK-8288619?[1] was incorrectly set to 22. >> It should be 21 actually. Then when its patch [3] was integrated, >> the SKARA created a backport issue [2] with `Fix Version` as 21. >> >> This problem only occurs about two weeks before the Rampdown Phase >> One [4]. >> Is it intentional? Or a bug? >> >> Best Regards, >> -- Guoxiong >> >> [1] https://bugs.openjdk.org/browse/JDK-8288619 >> [2] https://bugs.openjdk.org/browse/JDK-8308818 >> [3] https://github.com/openjdk/jdk/pull/13888 >> [4] https://openjdk.org/projects/jdk/21/ From lgxbslgx at gmail.com Thu Jun 1 15:09:32 2023 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 1 Jun 2023 23:09:32 +0800 Subject: SKARA creates a backport issue unexpectedly In-Reply-To: References: Message-ID: > See the OpenJDK developer's guide [1] for more information regarding this case. Thanks for reminding me. Done. Best Regards, -- Guoxiong -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsong at openjdk.org Thu Jun 1 22:32:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 1 Jun 2023 22:32:48 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command Message-ID: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> A user reported that there is no email generated for this comment. https://github.com/openjdk/jdk/pull/14114#issuecomment-1562126987 It is caused by the initial `/csr needed` command. The root cause is that in `ArchiveWorkItem#ignoreComment`, any command would be treated as a multiline command. The logic about filtering out commands from a comment differs between `ArchiveWorkItem#ignoreComment` and `CommandExtractor#extractCommands`. In this patch, I make the logic consistent in this two methods. 1. Any line starts with '/' followed by lowercase characters will be recognized as a command line. The command line will be stripped. 2. Check whether this command is a multiline command. If so, the following lines will be considered as arguments of the command and the argument lines will be stripped until the bot found another command line. ------------- Commit messages: - SKARA-1925 Changes: https://git.openjdk.org/skara/pull/1524/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1524&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1925 Stats: 101 lines in 5 files changed: 83 ins; 6 del; 12 mod Patch: https://git.openjdk.org/skara/pull/1524.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1524/head:pull/1524 PR: https://git.openjdk.org/skara/pull/1524 From zsong at openjdk.org Thu Jun 1 22:32:51 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 1 Jun 2023 22:32:51 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Thu, 1 Jun 2023 22:22:25 GMT, Zhao Song wrote: > A user reported that there is no email generated for this comment. > https://github.com/openjdk/jdk/pull/14114#issuecomment-1562126987 > > It is caused by the initial `/csr needed` command. The root cause is that in `ArchiveWorkItem#ignoreComment`, any command would be treated as a multiline command. > > The logic about filtering out commands from a comment differs between `ArchiveWorkItem#ignoreComment` and `CommandExtractor#extractCommands`. > > In this patch, I make the logic consistent in this two methods. > > 1. Any line starts with '/' followed by lowercase characters will be recognized as a command line. The command line will be stripped. > 2. Check whether this command is a multiline command. If so, the following lines will be considered as arguments of the command and the argument lines will be stripped until the bot found another command line. bots/common/src/main/java/org/openjdk/skara/bots/common/CommandNameEnum.java line 62: > 60: return isMultiLine; > 61: } > 62: Introduced a field called `isMultiLine` here because `CommandHandler` is coupled in PR bot and it is very difficult to extract it to the bots::common package. bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 143: > 141: } > 142: > 143: private boolean ignoreComment(HostUser author, String body, ZonedDateTime createdTime, ZonedDateTime lastDraftTime, boolean isComment) { Introduced argument `isComment` to this method because I think in any case, no review should be ignored. But according to the previous logic, if a review whose body only contains command, the review would be ignored. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1213742171 PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1213739659 From erikj at openjdk.org Fri Jun 2 15:08:21 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Jun 2023 15:08:21 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Thu, 1 Jun 2023 22:24:34 GMT, Zhao Song wrote: >> A user reported that there is no email generated for this comment. >> https://github.com/openjdk/jdk/pull/14114#issuecomment-1562126987 >> >> It is caused by the initial `/csr needed` command. The root cause is that in `ArchiveWorkItem#ignoreComment`, any command would be treated as a multiline command. >> >> The logic about filtering out commands from a comment differs between `ArchiveWorkItem#ignoreComment` and `CommandExtractor#extractCommands`. >> >> In this patch, I make the logic consistent in this two methods. >> >> 1. Any line starts with '/' followed by lowercase characters will be recognized as a command line. The command line will be stripped. >> 2. Check whether this command is a multiline command. If so, the following lines will be considered as arguments of the command and the argument lines will be stripped until the bot found another command line. > > bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 143: > >> 141: } >> 142: >> 143: private boolean ignoreComment(HostUser author, String body, ZonedDateTime createdTime, ZonedDateTime lastDraftTime, boolean isComment) { > > Introduced argument `isComment` to this method because I think in any case, no review should be ignored. But according to the previous logic, if a review whose body only contains command, the review would be ignored. I'm not sure about this. We already send email when someone approves a PR. I don't think we need to send emails with an empty review. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1214496136 From zsong at openjdk.org Fri Jun 2 16:10:43 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 2 Jun 2023 16:10:43 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Fri, 2 Jun 2023 15:06:14 GMT, Erik Joelsson wrote: >> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 143: >> >>> 141: } >>> 142: >>> 143: private boolean ignoreComment(HostUser author, String body, ZonedDateTime createdTime, ZonedDateTime lastDraftTime, boolean isComment) { >> >> Introduced argument `isComment` to this method because I think in any case, no review should be ignored. But according to the previous logic, if a review whose body only contains command, the review would be ignored. > > I'm not sure about this. We already send email when someone approves a PR. I don't think we need to send emails with an empty review. According to the previous logic, for example, if we approve a PR and the review body only contains command like "/reviewers 2", then this review will be ignored. This issue is what I want to resolve. But now I also think something in my logic is wrong. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1214565398 From erikj at openjdk.org Fri Jun 2 16:30:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Jun 2023 16:30:32 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Fri, 2 Jun 2023 16:08:31 GMT, Zhao Song wrote: >> I'm not sure about this. We already send email when someone approves a PR. I don't think we need to send emails with an empty review. > > According to the previous logic, for example, if we approve a PR and the review body only contains command like "/reviewers 2", then this review will be ignored. This issue is what I want to resolve. > > But now I also think something in my logic is wrong. See this PR that I reviewed this morning: https://github.com/openjdk/jdk/pull/14261 I didn't put any text in the review comment/body, but we still had this email sent: https://mail.openjdk.org/pipermail/build-dev/2023-June/039655.html ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1214583476 From zsong at openjdk.org Fri Jun 2 16:43:56 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 2 Jun 2023 16:43:56 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Fri, 2 Jun 2023 16:28:22 GMT, Erik Joelsson wrote: >> According to the previous logic, for example, if we approve a PR and the review body only contains command like "/reviewers 2", then this review will be ignored. This issue is what I want to resolve. >> >> But now I also think something in my logic is wrong. > > See this PR that I reviewed this morning: https://github.com/openjdk/jdk/pull/14261 > > I didn't put any text in the review comment/body, but we still had this email sent: https://mail.openjdk.org/pipermail/build-dev/2023-June/039655.html Yes, empty body is good. But if and only if the review body only contains command, it will be ignored. Just like when you are approving the pr, you put "/reviewers 2"(or any other command) in the review body. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1214593997 From erikj at openjdk.org Fri Jun 2 17:11:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Jun 2023 17:11:18 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Thu, 1 Jun 2023 22:22:25 GMT, Zhao Song wrote: > A user reported that there is no email generated for this comment. > https://github.com/openjdk/jdk/pull/14114#issuecomment-1562126987 > > It is caused by the initial `/csr needed` command. The root cause is that in `ArchiveWorkItem#ignoreComment`, any command would be treated as a multiline command. > > The logic about filtering out commands from a comment differs between `ArchiveWorkItem#ignoreComment` and `CommandExtractor#extractCommands`. > > In this patch, I make the logic consistent in this two methods. > > 1. Any line starts with '/' followed by lowercase characters will be recognized as a command line. The command line will be stripped. > 2. Check whether this command is a multiline command. If so, the following lines will be considered as arguments of the command and the argument lines will be stripped until the bot found another command line. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1524#pullrequestreview-1458066177 From erikj at openjdk.org Fri Jun 2 17:11:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Jun 2023 17:11:19 GMT Subject: RFR: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Fri, 2 Jun 2023 16:40:46 GMT, Zhao Song wrote: >> See this PR that I reviewed this morning: https://github.com/openjdk/jdk/pull/14261 >> >> I didn't put any text in the review comment/body, but we still had this email sent: https://mail.openjdk.org/pipermail/build-dev/2023-June/039655.html > > Yes, empty body is good. But if and only if the review body only contains command, it will be ignored. > > Just like when you are approving the pr, you put "/reviewers 2"(or any other command) in the review body. Ah, that's pretty bad, but I see what you mean now after having studied the code. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1524#discussion_r1214620450 From erikj at openjdk.org Fri Jun 2 20:43:57 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Jun 2023 20:43:57 GMT Subject: RFR: 1912: Show priority for bugs in pull request body [v3] In-Reply-To: References: Message-ID: On Tue, 23 May 2023 23:11:27 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 two additional commits since the last revision: > > - Change initializedPRs back to ConcurrentHashMap > - fix some problems Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1523#pullrequestreview-1458455004 From zsong at openjdk.org Mon Jun 5 16:00:22 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 16:00:22 GMT Subject: git: openjdk/skara: 1903: Verify User's repository access when processing backport command Message-ID: <3df6fc88-e68f-4969-bca4-a1b295a13124@openjdk.org> Changeset: 1ac2ffa4 Author: Zhao Song Date: 2023-06-05 15:59:56 +0000 URL: https://git.openjdk.org/skara/commit/1ac2ffa4e297eba8dec482bc524be87aa5becfa7 1903: Verify User's repository access when processing backport command Reviewed-by: erikj ! bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java ! bots/tester/src/test/java/org/openjdk/skara/bots/tester/InMemoryHostedRepository.java ! forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java ! forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java ! forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java ! test/src/main/java/org/openjdk/skara/test/TestHostedRepository.java From zsong at openjdk.org Mon Jun 5 16:02:20 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 16:02:20 GMT Subject: Integrated: 1903: Verify User's repository access 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. This pull request has now been integrated. Changeset: 1ac2ffa4 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/1ac2ffa4e297eba8dec482bc524be87aa5becfa7 Stats: 37 lines in 6 files changed: 37 ins; 0 del; 0 mod 1903: Verify User's repository access when processing backport command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1516 From zsong at openjdk.org Mon Jun 5 17:15:17 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 17:15:17 GMT Subject: RFR: 1932: Override abstract method canCreatePullRequest in BitbucketRepository Message-ID: <7uoVdtZXFgZKwijrxjr0eipA31ufGO9kBR6NJaoCeyE=.a3c3185a-48d7-4bba-8242-1e838634fb10@github.com> After integrated [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), the build of SKARA failed. The reason is that BitbucketRepository implements interface HostedRepository and in [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), a new method canCreatePullRequest was introduced in HostedRepository, so we need to override this method in BitbucketRepository. ------------- Commit messages: - SKARA-1932 Changes: https://git.openjdk.org/skara/pull/1525/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1525&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1932 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1525.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1525/head:pull/1525 PR: https://git.openjdk.org/skara/pull/1525 From erikj at openjdk.org Mon Jun 5 17:32:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 5 Jun 2023 17:32:23 GMT Subject: RFR: 1932: Override abstract method canCreatePullRequest in BitbucketRepository In-Reply-To: <7uoVdtZXFgZKwijrxjr0eipA31ufGO9kBR6NJaoCeyE=.a3c3185a-48d7-4bba-8242-1e838634fb10@github.com> References: <7uoVdtZXFgZKwijrxjr0eipA31ufGO9kBR6NJaoCeyE=.a3c3185a-48d7-4bba-8242-1e838634fb10@github.com> Message-ID: On Mon, 5 Jun 2023 16:47:20 GMT, Zhao Song wrote: > After integrated [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), the build of SKARA failed. The reason is that BitbucketRepository implements interface HostedRepository and in [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), a new method canCreatePullRequest was introduced in HostedRepository, so we need to override this method in BitbucketRepository. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1525#pullrequestreview-1463045966 From zsong at openjdk.org Mon Jun 5 17:32:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 17:32:23 GMT Subject: Integrated: 1932: Override abstract method canCreatePullRequest in BitbucketRepository In-Reply-To: <7uoVdtZXFgZKwijrxjr0eipA31ufGO9kBR6NJaoCeyE=.a3c3185a-48d7-4bba-8242-1e838634fb10@github.com> References: <7uoVdtZXFgZKwijrxjr0eipA31ufGO9kBR6NJaoCeyE=.a3c3185a-48d7-4bba-8242-1e838634fb10@github.com> Message-ID: On Mon, 5 Jun 2023 16:47:20 GMT, Zhao Song wrote: > After integrated [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), the build of SKARA failed. The reason is that BitbucketRepository implements interface HostedRepository and in [SKARA-1903](https://bugs.openjdk.org/browse/SKARA-1903), a new method canCreatePullRequest was introduced in HostedRepository, so we need to override this method in BitbucketRepository. This pull request has now been integrated. Changeset: 29dc11ea Author: Zhao Song URL: https://git.openjdk.org/skara/commit/29dc11ea177af4c0f515a279d5171f05271e663d Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 1932: Override abstract method canCreatePullRequest in BitbucketRepository Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1525 From zsong at openjdk.org Mon Jun 5 20:23:44 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 20:23:44 GMT Subject: Integrated: 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 pull request has now been integrated. Changeset: 98e89766 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/98e89766a55ff42ac54eca52a25bf57bb4040120 Stats: 1316 lines in 20 files changed: 1024 ins; 52 del; 240 mod 1912: Show priority for bugs in pull request body Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1523 From zsong at openjdk.org Mon Jun 5 20:32:59 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 5 Jun 2023 20:32:59 GMT Subject: Integrated: 1925: When archiving a comment, mlbridgeBot would strip everything after the first command In-Reply-To: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> References: <8mFyT07tC7udr5mJTMLRNNYIc2VzYzpmfaJhMEQI4v0=.807272e7-05ca-4048-8441-ae06eda717b1@github.com> Message-ID: On Thu, 1 Jun 2023 22:22:25 GMT, Zhao Song wrote: > A user reported that there is no email generated for this comment. > https://github.com/openjdk/jdk/pull/14114#issuecomment-1562126987 > > It is caused by the initial `/csr needed` command. The root cause is that in `ArchiveWorkItem#ignoreComment`, any command would be treated as a multiline command. > > The logic about filtering out commands from a comment differs between `ArchiveWorkItem#ignoreComment` and `CommandExtractor#extractCommands`. > > In this patch, I make the logic consistent in this two methods. > > 1. Any line starts with '/' followed by lowercase characters will be recognized as a command line. The command line will be stripped. > 2. Check whether this command is a multiline command. If so, the following lines will be considered as arguments of the command and the argument lines will be stripped until the bot found another command line. This pull request has now been integrated. Changeset: 86e474e7 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/86e474e7b5679f5635a2f055e7992dd7ad5d1226 Stats: 101 lines in 5 files changed: 83 ins; 6 del; 12 mod 1925: When archiving a comment, mlbridgeBot would strip everything after the first command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1524 From zsong at openjdk.org Tue Jun 6 22:16:12 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 6 Jun 2023 22:16:12 GMT Subject: RFR: 1934: Update ext.py to make test compatible with Mercurial6.4 Message-ID: Recently, I updated my mercurial version to 6.4 and `RepositoryTests#testRemoteBranches` started to fail. After investigation, I found that `ui.expandpath` is deprecated and removed. To make our tests compatible with latest mercurial, we need to update method `ls_remote` in ext.py. References: [1]:https://www.mail-archive.com/mercurial-devel at mercurial-scm.org/msg58072.html [2]:https://github.com/phacility/arcanist/commit/0fc22183e796fb8ac2e3a0a3f3f37aa964c6d7fa ------------- Commit messages: - SKARA-1934 Changes: https://git.openjdk.org/skara/pull/1526/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1526&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1934 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1526.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1526/head:pull/1526 PR: https://git.openjdk.org/skara/pull/1526 From duke at openjdk.org Tue Jun 6 22:58:53 2023 From: duke at openjdk.org (duke) Date: Tue, 6 Jun 2023 22:58:53 GMT Subject: Withdrawn: 1890: Add method deployKeyTitles In-Reply-To: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: On Tue, 25 Apr 2023 19:01:25 GMT, Zhao Song wrote: > Add a new method called getExpiredDeployKeys in HostedRepository This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/skara/pull/1508 From zsong at openjdk.org Wed Jun 7 16:30:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 16:30:41 GMT Subject: RFR: 1935: Show issue priority as Pn rather than "n" Message-ID: Show issue priority as Pn rather than "n" ------------- Commit messages: - SKARA-1935 Changes: https://git.openjdk.org/skara/pull/1527/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1527&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1935 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1527.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1527/head:pull/1527 PR: https://git.openjdk.org/skara/pull/1527 From erikj at openjdk.org Wed Jun 7 16:47:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 Jun 2023 16:47:18 GMT Subject: RFR: 1935: Show issue priority as Pn rather than "n" In-Reply-To: References: Message-ID: <11c6cOop4WVOv_ieC_FeRqbi1KkON9E_suARbZD_W28=.ae2ab16c-2b11-4241-90f4-ecebc47aa359@github.com> On Wed, 7 Jun 2023 16:26:51 GMT, Zhao Song wrote: > Show issue priority as Pn rather than "n" Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1527#pullrequestreview-1468162058 From erikj at openjdk.org Wed Jun 7 16:48:35 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 Jun 2023 16:48:35 GMT Subject: RFR: 1934: Update ext.py to make test compatible with Mercurial6.4 In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 21:58:48 GMT, Zhao Song wrote: > Recently, I updated my mercurial version to 6.4 and `RepositoryTests#testRemoteBranches` started to fail. > > After investigation, I found that `ui.expandpath` is deprecated and removed. To make our tests compatible with latest mercurial, we need to update method `ls_remote` in ext.py. > > References: > [1]:https://www.mail-archive.com/mercurial-devel at mercurial-scm.org/msg58072.html > [2]:https://github.com/phacility/arcanist/commit/0fc22183e796fb8ac2e3a0a3f3f37aa964c6d7fa Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1526#pullrequestreview-1468163845 From zsong at openjdk.org Wed Jun 7 16:52:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 16:52:05 GMT Subject: RFR: 1934: Update ext.py to make test compatible with Mercurial6.4 In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 21:58:48 GMT, Zhao Song wrote: > Recently, I updated my mercurial version to 6.4 and `RepositoryTests#testRemoteBranches` started to fail. > > After investigation, I found that `ui.expandpath` is deprecated and removed. To make our tests compatible with latest mercurial, we need to update method `ls_remote` in ext.py. > > References: > [1]:https://www.mail-archive.com/mercurial-devel at mercurial-scm.org/msg58072.html > [2]:https://github.com/phacility/arcanist/commit/0fc22183e796fb8ac2e3a0a3f3f37aa964c6d7fa Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1526#issuecomment-1581190963 From zsong at openjdk.org Wed Jun 7 16:52:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 16:52:05 GMT Subject: Integrated: 1934: Update ext.py to make test compatible with Mercurial6.4 In-Reply-To: References: Message-ID: On Tue, 6 Jun 2023 21:58:48 GMT, Zhao Song wrote: > Recently, I updated my mercurial version to 6.4 and `RepositoryTests#testRemoteBranches` started to fail. > > After investigation, I found that `ui.expandpath` is deprecated and removed. To make our tests compatible with latest mercurial, we need to update method `ls_remote` in ext.py. > > References: > [1]:https://www.mail-archive.com/mercurial-devel at mercurial-scm.org/msg58072.html > [2]:https://github.com/phacility/arcanist/commit/0fc22183e796fb8ac2e3a0a3f3f37aa964c6d7fa This pull request has now been integrated. Changeset: e378bd6e Author: Zhao Song URL: https://git.openjdk.org/skara/commit/e378bd6e6c6b1bb51e8c47d2750071032975995c Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 1934: Update ext.py to make test compatible with Mercurial6.4 Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1526 From zsong at openjdk.org Wed Jun 7 16:53:26 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 16:53:26 GMT Subject: RFR: 1935: Show issue priority as Pn rather than "n" In-Reply-To: References: Message-ID: On Wed, 7 Jun 2023 16:26:51 GMT, Zhao Song wrote: > Show issue priority as Pn rather than "n" Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1527#issuecomment-1581192335 From zsong at openjdk.org Wed Jun 7 16:53:26 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 16:53:26 GMT Subject: Integrated: 1935: Show issue priority as Pn rather than "n" In-Reply-To: References: Message-ID: <2z_HgY547y8D6sjpcSa7uu42FfKdi4NnHNOwZT3NSQ0=.e1936708-6642-46de-ad02-b09ed5d7d6e3@github.com> On Wed, 7 Jun 2023 16:26:51 GMT, Zhao Song wrote: > Show issue priority as Pn rather than "n" This pull request has now been integrated. Changeset: 159aec26 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/159aec26472c02f5cbaaa2cf203b7cd127084274 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 1935: Show issue priority as Pn rather than "n" Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1527 From zsong at openjdk.org Wed Jun 7 23:10:10 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 23:10:10 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab Message-ID: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. To resolve this issue, we need to remove the draft prefix before trying to parse the title issue. ------------- Commit messages: - SKARA-1936 Changes: https://git.openjdk.org/skara/pull/1528/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1528&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1936 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1528.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1528/head:pull/1528 PR: https://git.openjdk.org/skara/pull/1528 From kcr at openjdk.org Wed Jun 7 23:15:09 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 7 Jun 2023 23:15:09 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab In-Reply-To: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Wed, 7 Jun 2023 22:55:47 GMT, Zhao Song wrote: > In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. > > To resolve this issue, we need to remove the draft prefix before trying to parse the title issue. Is there a better place to remove the `Draft:` prefix? I'm wondering if it would be possible to generalize it by removing the "Draft:" prefix similarly to how the optional `JDK-` prefix is removed? That way it would be parsed as a valid issue for the purpose of listing the BugID + Bug tltle in the Description, checking for a CSR, etc. ------------- PR Comment: https://git.openjdk.org/skara/pull/1528#issuecomment-1581631312 From zsong at openjdk.org Wed Jun 7 23:25:42 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 7 Jun 2023 23:25:42 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab In-Reply-To: References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Wed, 7 Jun 2023 23:12:57 GMT, Kevin Rushforth wrote: > Is there a better place to remove the `Draft:` prefix? I'm wondering if it would be possible to generalize it by removing the "Draft:" prefix similarly to how the optional `JDK-` prefix is removed? That way it would be parsed as a valid issue for the purpose of listing the BugID + Bug tltle in the Description, checking for a CSR, etc. I will think about whether we could remove "Draft:" prefix in the method `GitLabMergeRequest#title`. And it's a good idea that we could also remove "Draft: " prefix when generating pr body for draft prs. In that way, as you said, the issue could be listed in the pr body and checking for CSR can be done. Thanks for the advice! ------------- PR Comment: https://git.openjdk.org/skara/pull/1528#issuecomment-1581647346 From zsong at openjdk.org Thu Jun 8 18:37:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 8 Jun 2023 18:37:48 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab [v2] In-Reply-To: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: > In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - fix typo - SKARA-1936 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1528/files - new: https://git.openjdk.org/skara/pull/1528/files/f84f29f5..1a504afe Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1528&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1528&range=00-01 Stats: 34 lines in 2 files changed: 23 ins; 7 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1528.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1528/head:pull/1528 PR: https://git.openjdk.org/skara/pull/1528 From zsong at openjdk.org Thu Jun 8 18:37:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 8 Jun 2023 18:37:48 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab In-Reply-To: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Wed, 7 Jun 2023 22:55:47 GMT, Zhao Song wrote: > In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. I have updated the solution of this issue. Now, `GitLabMergeRequest#title` would return title without draft prefix and `GitLabMergeRequest#setTitle` would check whether the pr is in draft mode, if so, it will add draft prefix to the title. Also, these two methods are called many times in the whole project. I checked every call of these two methods and I think there should be no side effects. Previous, when the user creates a pr in GitLab and set the title to "Draft: 123", the pr bot will not be able to update the title and checking for CSR etc. Now, all the behavior of draft pr in GitLab will be the same as in GitHub. Thanks to @kevinrushforth 's advice again! ------------- PR Comment: https://git.openjdk.org/skara/pull/1528#issuecomment-1583137691 From erikj at openjdk.org Thu Jun 8 20:23:29 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 Jun 2023 20:23:29 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab [v2] In-Reply-To: References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Thu, 8 Jun 2023 18:37:48 GMT, Zhao Song wrote: >> In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. > > Zhao Song has updated the pull request incrementally with two additional commits since the last revision: > > - fix typo > - SKARA-1936 Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1528#pullrequestreview-1470698889 From zsong at openjdk.org Thu Jun 8 20:55:17 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 8 Jun 2023 20:55:17 GMT Subject: RFR: 1936: IssueCommand would change pr title in GitLab [v2] In-Reply-To: References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Thu, 8 Jun 2023 18:37:48 GMT, Zhao Song wrote: >> In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. > > Zhao Song has updated the pull request incrementally with two additional commits since the last revision: > > - fix typo > - SKARA-1936 Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1528#issuecomment-1583327301 From zsong at openjdk.org Thu Jun 8 20:55:18 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 8 Jun 2023 20:55:18 GMT Subject: Integrated: 1936: IssueCommand would change pr title in GitLab In-Reply-To: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> References: <0IVYDI_gRBP9ZIM8dEvyIMXCuuXFm6TACOzd7Qw6G3U=.55fbcf11-748c-497d-b369-d6ca9d2cd4d8@github.com> Message-ID: On Wed, 7 Jun 2023 22:55:47 GMT, Zhao Song wrote: > In GitLab, when a user wants to create a PR in draft mode, they need to include the prefix "Draft: " before the title(Checked the GitLab Document, "WIP" is already deprecated and removed). However, if the user wants to use the "/issue" command to add another issue to this PR, the pr bot will not be able to parse the issue within the PR title. Therefore, the bot will modify the PR title to match the new issue the user wants to add, resulting in the removal of the draft state of the PR. This pull request has now been integrated. Changeset: 6f98d0ef Author: Zhao Song URL: https://git.openjdk.org/skara/commit/6f98d0efc50b1f7501e8074d72a07f99ccdb566b Stats: 28 lines in 1 file changed: 23 ins; 2 del; 3 mod 1936: IssueCommand would change pr title in GitLab Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1528 From erikj at openjdk.org Fri Jun 9 23:14:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 Jun 2023 23:14:15 GMT Subject: RFR: 1939: Make work item scheduling more resilient against failures Message-ID: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> When the BotRunner calls getPeriodicItems, any failure will terminate the whole loop. This means that one misconfigured repository, or problem with the forge, can prevent all other repos from being processed. I think it would be a good idea to keep trying each bot instance in the list even if some of them fail. This patch moves the catch clauses inside the loop. I'm also moving some logging and metrics gathering into a finally block. ------------- Commit messages: - MACH5-1939 Changes: https://git.openjdk.org/skara/pull/1529/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1529&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1939 Stats: 15 lines in 1 file changed: 8 ins; 7 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1529.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1529/head:pull/1529 PR: https://git.openjdk.org/skara/pull/1529 From zsong at openjdk.org Fri Jun 9 23:14:15 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 9 Jun 2023 23:14:15 GMT Subject: RFR: 1939: Make work item scheduling more resilient against failures In-Reply-To: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> References: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> Message-ID: On Fri, 9 Jun 2023 21:49:35 GMT, Erik Joelsson wrote: > When the BotRunner calls getPeriodicItems, any failure will terminate the whole loop. This means that one misconfigured repository, or problem with the forge, can prevent all other repos from being processed. I think it would be a good idea to keep trying each bot instance in the list even if some of them fail. > > This patch moves the catch clauses inside the loop. I'm also moving some logging and metrics gathering into a finally block. Looks good ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1529#pullrequestreview-1473102881 From kcr at openjdk.org Fri Jun 9 23:14:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 9 Jun 2023 23:14:15 GMT Subject: RFR: 1939: Make work item scheduling more resilient against failures In-Reply-To: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> References: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> Message-ID: On Fri, 9 Jun 2023 21:49:35 GMT, Erik Joelsson wrote: > When the BotRunner calls getPeriodicItems, any failure will terminate the whole loop. This means that one misconfigured repository, or problem with the forge, can prevent all other repos from being processed. I think it would be a good idea to keep trying each bot instance in the list even if some of them fail. > > This patch moves the catch clauses inside the loop. I'm also moving some logging and metrics gathering into a finally block. Looks good. Title should be "SKARA-1939". ------------- Marked as reviewed by kcr (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1529#pullrequestreview-1473105899 PR Comment: https://git.openjdk.org/skara/pull/1529#issuecomment-1585175848 From erikj at openjdk.org Mon Jun 12 12:48:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 Jun 2023 12:48:47 GMT Subject: Integrated: 1939: Make work item scheduling more resilient against failures In-Reply-To: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> References: <1h_Crf_tzuQcpJUetrpndc0iDtXWK7EEnDjDz65o-tM=.8a44e44c-b2c7-4a2d-b79c-a6cd0aeef91b@github.com> Message-ID: <4qt0nnXUxZ-PAURYRlKZ0CLq4m80xu95dicKK5YyBjM=.1ddebbe8-b393-4301-bd8b-a6ebdc38f674@github.com> On Fri, 9 Jun 2023 21:49:35 GMT, Erik Joelsson wrote: > When the BotRunner calls getPeriodicItems, any failure will terminate the whole loop. This means that one misconfigured repository, or problem with the forge, can prevent all other repos from being processed. I think it would be a good idea to keep trying each bot instance in the list even if some of them fail. > > This patch moves the catch clauses inside the loop. I'm also moving some logging and metrics gathering into a finally block. This pull request has now been integrated. Changeset: 91fe8655 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/91fe86559bf8f640f3176a3c08d355837ce325fd Stats: 15 lines in 1 file changed: 8 ins; 7 del; 0 mod 1939: Make work item scheduling more resilient against failures Reviewed-by: zsong, kcr ------------- PR: https://git.openjdk.org/skara/pull/1529 From zsong at openjdk.org Mon Jun 12 20:59:08 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 12 Jun 2023 20:59:08 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA Message-ID: Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. ------------- Commit messages: - SKARA-1943 Changes: https://git.openjdk.org/skara/pull/1530/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1530&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1943 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1530.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1530/head:pull/1530 PR: https://git.openjdk.org/skara/pull/1530 From zsong at openjdk.org Tue Jun 13 16:51:03 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Jun 2023 16:51:03 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 23:26:53 GMT, Zhao Song wrote: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 189: > 187: .map(HostedBranch::name) > 188: .filter(name -> !name.startsWith("pr/")) > 189: .toList(); Currently, fetching all existing branches is the main overhead in this feature. It takes about 2s for JDK repo. If this overhead is not acceptable, the other way to solve this is store the branches in bot config. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228411715 From zsong at openjdk.org Tue Jun 13 16:51:03 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Jun 2023 16:51:03 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes Message-ID: As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. In this patch, 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. ------------- Commit messages: - update - update - fix tests - fix test - update - Merge branch 'master' into SKARA-1937 - SKARA=1937 Changes: https://git.openjdk.org/skara/pull/1531/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1937 Stats: 133 lines in 9 files changed: 130 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1531.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/skara/pull/1531 From erikj at openjdk.org Tue Jun 13 18:07:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 Jun 2023 18:07:02 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: References: Message-ID: <7o0oQhb58mSG0JbeqllstcohV_O2duUEOWVYxd0Axa0=.c1bf1691-e009-4827-a7e1-c9909efba1ab@github.com> On Mon, 12 Jun 2023 23:26:53 GMT, Zhao Song wrote: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1338: > 1336: // Calculate current metadata to avoid unnecessary future checks > 1337: var metadata = workItem.getMetadata(workItem.getPRMetadata(censusInstance, title, updatedBody, pr.comments(), activeReviews, > 1338: newLabels, pr.targetRef(), pr.isDraft(), pr.targetRefJCheckConf()), workItem.getIssueMetadata(updatedBody), expiresIn); The .jcheck/conf file is already read when creating the `CensusInstance` (and may sometimes even be overridden and located in another repository). I think we should store the raw .jcheck/conf string in `LimitedCensusInstance` and get it from there in the rest of `CheckWorkItem`/`CheckRun`. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 197: > 195: } > 196: var currConf = currConfOpt.get(); > 197: if (!jCheckConfMap.containsKey(targetRef) || !jCheckConfMap.get(targetRef).equals(currConf)) { If we don't have a record of .jcheck/conf yet, then we should not schedule a WorkItem. The poller will take care of this in the first round. This logic only needs to worry about changes. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228512493 PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228499869 From erikj at openjdk.org Tue Jun 13 18:07:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 Jun 2023 18:07:03 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: References: Message-ID: <81zq_PWAyUelearfR6dvIlrDONDVDImahEGbZoW6R8c=.25f2ad7e-839b-492c-81f4-7e8c9a0e4479@github.com> On Tue, 13 Jun 2023 16:31:24 GMT, Zhao Song wrote: >> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." >> >> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. >> >> In this patch, >> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). >> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. >> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 189: > >> 187: .map(HostedBranch::name) >> 188: .filter(name -> !name.startsWith("pr/")) >> 189: .toList(); > > Currently, fetching all existing branches is the main overhead in this feature. It takes about 2s for JDK repo. If this overhead is not acceptable, the other way to solve this is store the branches in bot config. I assume this is taking a long time in mainline due to all the pr branches. We also have several update repositories (internally) with a lot of branches. With the future move to branched development in mainline, there will be even more in the main jdk repo. Those will not be filtered out either, so will add more rounds in the loop fetching .jcheck/conf below. I don't think fetching all branches and checking them for .jcheck/conf is a good idea. Instead I think we should keep a `Map` of branch names to set of PR IDs. Then we only need to iterate over the known targeted branches when looking for .jcheck/conf changes. To maintain the map, look at every PR found by the poller, if it's open, add it to the set for the branch, if it's closed, remove it. The poller will return all open PRs in the first round, so at that point we know it's up to date. After that it will catch all updates to all PRs, so we know we will catch when a PR is closed and get it removed from the map. Both GitHub and GitLab support querying for pull requests that target a specific branch, so when we get a hit on .jcheck/conf, we can fetch just the relevant pull requests. (In GitHub it's called `base`) ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228495829 From zsong at openjdk.org Tue Jun 13 18:24:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Jun 2023 18:24:41 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: <7o0oQhb58mSG0JbeqllstcohV_O2duUEOWVYxd0Axa0=.c1bf1691-e009-4827-a7e1-c9909efba1ab@github.com> References: <7o0oQhb58mSG0JbeqllstcohV_O2duUEOWVYxd0Axa0=.c1bf1691-e009-4827-a7e1-c9909efba1ab@github.com> Message-ID: On Tue, 13 Jun 2023 18:04:36 GMT, Erik Joelsson wrote: >> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." >> >> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. >> >> In this patch, >> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). >> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. >> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1338: > >> 1336: // Calculate current metadata to avoid unnecessary future checks >> 1337: var metadata = workItem.getMetadata(workItem.getPRMetadata(censusInstance, title, updatedBody, pr.comments(), activeReviews, >> 1338: newLabels, pr.targetRef(), pr.isDraft(), pr.targetRefJCheckConf()), workItem.getIssueMetadata(updatedBody), expiresIn); > > The .jcheck/conf file is already read when creating the `CensusInstance` (and may sometimes even be overridden and located in another repository). I think we should store the raw .jcheck/conf string in `LimitedCensusInstance` and get it from there in the rest of `CheckWorkItem`/`CheckRun`. Yes, it's a good point. Will fix it ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228532965 From zsong at openjdk.org Tue Jun 13 18:39:07 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Jun 2023 18:39:07 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: <81zq_PWAyUelearfR6dvIlrDONDVDImahEGbZoW6R8c=.25f2ad7e-839b-492c-81f4-7e8c9a0e4479@github.com> References: <81zq_PWAyUelearfR6dvIlrDONDVDImahEGbZoW6R8c=.25f2ad7e-839b-492c-81f4-7e8c9a0e4479@github.com> Message-ID: <80nCiwUPxbVd_ISoK7g-aSNepMCz3f_RDwHvGHiIuCU=.7f46ccb3-37d2-4cc6-a010-e8e76e0b25df@github.com> On Tue, 13 Jun 2023 17:49:32 GMT, Erik Joelsson wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBot.java line 189: >> >>> 187: .map(HostedBranch::name) >>> 188: .filter(name -> !name.startsWith("pr/")) >>> 189: .toList(); >> >> Currently, fetching all existing branches is the main overhead in this feature. It takes about 2s for JDK repo. If this overhead is not acceptable, the other way to solve this is store the branches in bot config. > > I assume this is taking a long time in mainline due to all the pr branches. We also have several update repositories (internally) with a lot of branches. With the future move to branched development in mainline, there will be even more in the main jdk repo. Those will not be filtered out either, so will add more rounds in the loop fetching .jcheck/conf below. > > I don't think fetching all branches and checking them for .jcheck/conf is a good idea. Instead I think we should keep a `Map` of branch names to set of PR IDs. Then we only need to iterate over the known targeted branches when looking for .jcheck/conf changes. > > To maintain the map, look at every PR found by the poller, if it's open, add it to the set for the branch, if it's closed, remove it. The poller will return all open PRs in the first round, so at that point we know it's up to date. After that it will catch all updates to all PRs, so we know we will catch when a PR is closed and get it removed from the map. > > Both GitHub and GitLab support querying for pull requests that target a specific branch, so when we get a hit on .jcheck/conf, we can fetch just the relevant pull requests. (In GitHub it's called `base`) Yes, it will be much better. No extra overhead will be added. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1228549811 From erikj at openjdk.org Tue Jun 13 20:27:05 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 Jun 2023 20:27:05 GMT Subject: Integrated: 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 now been integrated. Changeset: eb6c0bd1 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/eb6c0bd1bbdb09558aab159e9bae8ab86c2939ef Stats: 11 lines in 1 file changed: 8 ins; 3 del; 0 mod 1827: Better handling of Error Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1490 From zsong at openjdk.org Tue Jun 13 22:56:02 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 13 Jun 2023 22:56:02 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v2] In-Reply-To: References: Message-ID: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/skara/pull/1531/files - new: https://git.openjdk.org/skara/pull/1531/files/48581714..89ff415f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=00-01 Stats: 122 lines in 15 files changed: 66 ins; 41 del; 15 mod Patch: https://git.openjdk.org/skara/pull/1531.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/skara/pull/1531 From erikj at openjdk.org Wed Jun 14 14:23:04 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 14:23:04 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v2] In-Reply-To: References: Message-ID: <3XOCYT-Wd39UvCEdBFjpw7E25C3AEe1X-yBQ05OgMeQ=.3bf21fb8-d0ba-4d34-9374-5abe39b3a37c@github.com> On Tue, 13 Jun 2023 22:56:02 GMT, Zhao Song wrote: >> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." >> >> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. >> >> In this patch, >> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). >> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. >> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java line 226: > 224: * Returns a list of open pull requests which targets at the specific ref > 225: */ > 226: List openPullRequestsTargetsSpecificRef(String targetRef); Suggestion: List openPullRequestsWithTargetRef(String targetRef); jcheck/src/main/java/org/openjdk/skara/jcheck/JCheckConfiguration.java line 158: > 156: public static JCheckConfiguration parse(List lines) { > 157: var ini = INI.parse(lines); > 158: var rawConf = String.join("", lines); This isn't actually the raw conf anymore, since it's been split by lines and then put together, but the original line breaks are lost. If we are calling this the "rawConf" then we should at least put `\n` back in there. Alternatively, we could store just a hash of the lines to make it clear that it can't be used to compare to another raw source of .jcheck/conf in the future. I think just putting linebreaks in is enough for now. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1229671897 PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1229700208 From zsong at openjdk.org Wed Jun 14 15:56:04 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 15:56:04 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v3] In-Reply-To: References: Message-ID: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Update forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1531/files - new: https://git.openjdk.org/skara/pull/1531/files/89ff415f..81b96727 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1531.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/skara/pull/1531 From zsong at openjdk.org Wed Jun 14 15:56:13 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 15:56:13 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v2] In-Reply-To: <3XOCYT-Wd39UvCEdBFjpw7E25C3AEe1X-yBQ05OgMeQ=.3bf21fb8-d0ba-4d34-9374-5abe39b3a37c@github.com> References: <3XOCYT-Wd39UvCEdBFjpw7E25C3AEe1X-yBQ05OgMeQ=.3bf21fb8-d0ba-4d34-9374-5abe39b3a37c@github.com> Message-ID: On Wed, 14 Jun 2023 14:19:27 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> update > > jcheck/src/main/java/org/openjdk/skara/jcheck/JCheckConfiguration.java line 158: > >> 156: public static JCheckConfiguration parse(List lines) { >> 157: var ini = INI.parse(lines); >> 158: var rawConf = String.join("", lines); > > This isn't actually the raw conf anymore, since it's been split by lines and then put together, but the original line breaks are lost. If we are calling this the "rawConf" then we should at least put `\n` back in there. Alternatively, we could store just a hash of the lines to make it clear that it can't be used to compare to another raw source of .jcheck/conf in the future. > > I think just putting linebreaks in is enough for now. Will add the line breaks back. Thanks! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1531#discussion_r1229846246 From zsong at openjdk.org Wed Jun 14 16:09:33 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 16:09:33 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v4] In-Reply-To: References: Message-ID: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add line breaks back ------------- Changes: - all: https://git.openjdk.org/skara/pull/1531/files - new: https://git.openjdk.org/skara/pull/1531/files/81b96727..f6a1936d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1531&range=02-03 Stats: 8 lines in 7 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1531.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1531/head:pull/1531 PR: https://git.openjdk.org/skara/pull/1531 From erikj at openjdk.org Wed Jun 14 17:11:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 17:11:39 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 20:43:21 GMT, Zhao Song wrote: > Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. .github/workflows/ci.yml line 86: > 84: mac: > 85: name: macOS x64 > 86: runs-on: "macos-latest" We should still pick a specific version for reproducibility. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1530#discussion_r1227250426 From zsong at openjdk.org Wed Jun 14 17:17:26 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 17:17:26 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA [v2] In-Reply-To: References: Message-ID: > Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: change the platform for macos ------------- Changes: - all: https://git.openjdk.org/skara/pull/1530/files - new: https://git.openjdk.org/skara/pull/1530/files/c82f190c..fd27ed58 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1530&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1530&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1530.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1530/head:pull/1530 PR: https://git.openjdk.org/skara/pull/1530 From kcr at openjdk.org Wed Jun 14 17:19:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 17:19:38 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 17:17:26 GMT, Zhao Song wrote: >> Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > change the platform for macos Marked as reviewed by kcr (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1530#pullrequestreview-1479957881 From kcr at openjdk.org Wed Jun 14 17:19:38 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 14 Jun 2023 17:19:38 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA [v2] In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 21:15:55 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> change the platform for macos > > .github/workflows/ci.yml line 86: > >> 84: mac: >> 85: name: macOS x64 >> 86: runs-on: "macos-latest" > > We should still pick a specific version for reproducibility. FWIW, I recently switched the `jfx` workflow to use `macos-13`, but you could choose 11 or 12 if that's a better choice for Skara GHA runs. (I see you chose `macos-12` which seems like a fine choice) ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1530#discussion_r1229940075 From erikj at openjdk.org Wed Jun 14 17:55:44 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 17:55:44 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 17:17:26 GMT, Zhao Song wrote: >> Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > change the platform for macos Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1530#pullrequestreview-1480013027 From erikj at openjdk.org Wed Jun 14 17:57:09 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 17:57:09 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 16:09:33 GMT, Zhao Song wrote: >> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." >> >> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. >> >> In this patch, >> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). >> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. >> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add line breaks back Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1531#pullrequestreview-1480015224 From zsong at openjdk.org Wed Jun 14 18:03:56 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 18:03:56 GMT Subject: RFR: 1937: Re-evaulate all PRs when .jcheck/conf changes [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 16:09:33 GMT, Zhao Song wrote: >> As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." >> >> This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. >> >> In this patch, >> 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). >> 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. >> 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add line breaks back Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1531#issuecomment-1591747661 From zsong at openjdk.org Wed Jun 14 18:03:56 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 18:03:56 GMT Subject: Integrated: 1937: Re-evaulate all PRs when .jcheck/conf changes In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 23:26:53 GMT, Zhao Song wrote: > As Erik said in the issue: "When we bump the version in .jcheck/conf from N to N+1 in the jdk master branch, PRs with CSRs are often not updated to reflect this." > > This root cause of this is that changing of .jcheck/conf in target ref of the pr will not be able to trigger checkWorkItem for this pr. > > In this patch, > 1. The prBot will monitor the changes to the .jcheck/conf file in any branch(except for PR branches). > 2. If the prBot detects an update to the .jcheck/conf file in a branch, it will trigger a checkWorkItem for all open PRs whose target ref is the branch where the .jcheck/conf file was updated. > 3. To solve the problem related with bot restarting, the contents of the .jcheck/conf file in the target branch of a PR will be included in the metadata hash. This pull request has now been integrated. Changeset: ea29b37c Author: Zhao Song URL: https://git.openjdk.org/skara/commit/ea29b37c7e0e1c8b99e18a77a3193ba40ab52b89 Stats: 162 lines in 11 files changed: 155 ins; 0 del; 7 mod 1937: Re-evaulate all PRs when .jcheck/conf changes Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1531 From zsong at openjdk.org Wed Jun 14 18:42:18 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 18:42:18 GMT Subject: RFR: 1943: Update .github/workflows/ci.yml to fix GHA [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 17:17:26 GMT, Zhao Song wrote: >> Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > change the platform for macos Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1530#issuecomment-1591797626 From zsong at openjdk.org Wed Jun 14 18:42:18 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 18:42:18 GMT Subject: Integrated: 1943: Update .github/workflows/ci.yml to fix GHA In-Reply-To: References: Message-ID: On Mon, 12 Jun 2023 20:43:21 GMT, Zhao Song wrote: > Since last month, the GitHub Action for running tests on macOS has been failing consistently, and the test job always failed due to time out. It seems like that GitHub no longer supports tests on macOS-10.15, so we need to update the configuration. This pull request has now been integrated. Changeset: b6a82541 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/b6a82541e16d06e1efbbf3a51b9b695620e2e11d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1943: Update .github/workflows/ci.yml to fix GHA Reviewed-by: kcr, erikj ------------- PR: https://git.openjdk.org/skara/pull/1530 From erikj at openjdk.org Wed Jun 14 20:56:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 20:56:23 GMT Subject: RFR: 1948: User not getting push access to backport branch Message-ID: When a user creates a backport PR using the /backport command, they are supposed to get push access to the branch in the fork repository. On GitHub, this has stopped working (assuming it ever worked). Experimentation shows that for a user to be eligible for listing in a branch protection rule, that user must first have push access in the repository. Just having a pending invite is not enough. When a user issues the /backport command, an invite is automatically sent to become a collaborator with push access in the repository, but the user has to accept it before it comes into effect. Given this, I don't see a way to consistently provide branch level push access restrictions for the fork repositories. But instead of removing the feature completely, we can apply it when possible. The first /backport by a user will not get exclusive push access, but if the user accepts the invite before the next time, then from then on, any new backport branches will be protected. Not sure if this is worth it, but since we have the functionality, we may as well apply it when possible. ------------- Commit messages: - SKARA-1948 Changes: https://git.openjdk.org/skara/pull/1532/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1532&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1948 Stats: 17 lines in 2 files changed: 16 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1532.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1532/head:pull/1532 PR: https://git.openjdk.org/skara/pull/1532 From erikj at openjdk.org Wed Jun 14 20:56:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 20:56:23 GMT Subject: RFR: 1948: User not getting push access to backport branch In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 20:46:04 GMT, Erik Joelsson wrote: > When a user creates a backport PR using the /backport command, they are supposed to get push access to the branch in the fork repository. On GitHub, this has stopped working (assuming it ever worked). Experimentation shows that for a user to be eligible for listing in a branch protection rule, that user must first have push access in the repository. Just having a pending invite is not enough. When a user issues the /backport command, an invite is automatically sent to become a collaborator with push access in the repository, but the user has to accept it before it comes into effect. > > Given this, I don't see a way to consistently provide branch level push access restrictions for the fork repositories. But instead of removing the feature completely, we can apply it when possible. The first /backport by a user will not get exclusive push access, but if the user accepts the invite before the next time, then from then on, any new backport branches will be protected. Not sure if this is worth it, but since we have the functionality, we may as well apply it when possible. I seem to have messed up my local branches. Please wait with reviewing. ------------- PR Comment: https://git.openjdk.org/skara/pull/1532#issuecomment-1591959482 From zsong at openjdk.org Wed Jun 14 20:58:33 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 14 Jun 2023 20:58:33 GMT Subject: RFR: 1948: User not getting push access to backport branch In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 20:46:04 GMT, Erik Joelsson wrote: > When a user creates a backport PR using the /backport command, they are supposed to get push access to the branch in the fork repository. On GitHub, this has stopped working (assuming it ever worked). Experimentation shows that for a user to be eligible for listing in a branch protection rule, that user must first have push access in the repository. Just having a pending invite is not enough. When a user issues the /backport command, an invite is automatically sent to become a collaborator with push access in the repository, but the user has to accept it before it comes into effect. > > Given this, I don't see a way to consistently provide branch level push access restrictions for the fork repositories. But instead of removing the feature completely, we can apply it when possible. The first /backport by a user will not get exclusive push access, but if the user accepts the invite before the next time, then from then on, any new backport branches will be protected. Not sure if this is worth it, but since we have the functionality, we may as well apply it when possible. Looks good ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1532#pullrequestreview-1480292555 From erikj at openjdk.org Wed Jun 14 21:26:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 21:26:19 GMT Subject: RFR: 1948: User not getting push access to backport branch In-Reply-To: References: Message-ID: On Wed, 14 Jun 2023 20:46:04 GMT, Erik Joelsson wrote: > When a user creates a backport PR using the /backport command, they are supposed to get push access to the branch in the fork repository. On GitHub, this has stopped working (assuming it ever worked). Experimentation shows that for a user to be eligible for listing in a branch protection rule, that user must first have push access in the repository. Just having a pending invite is not enough. When a user issues the /backport command, an invite is automatically sent to become a collaborator with push access in the repository, but the user has to accept it before it comes into effect. > > Given this, I don't see a way to consistently provide branch level push access restrictions for the fork repositories. But instead of removing the feature completely, we can apply it when possible. The first /backport by a user will not get exclusive push access, but if the user accepts the invite before the next time, then from then on, any new backport branches will be protected. Not sure if this is worth it, but since we have the functionality, we may as well apply it when possible. Thanks! ------------- PR Comment: https://git.openjdk.org/skara/pull/1532#issuecomment-1592008141 From erikj at openjdk.org Wed Jun 14 21:26:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 21:26:19 GMT Subject: Integrated: 1948: User not getting push access to backport branch In-Reply-To: References: Message-ID: <-O_YBd4LkI2FEnKlbrc7_UxvotCHUWT7wAdqwnP6jTU=.5eb89d80-5f42-4fce-a390-31e4bf98e677@github.com> On Wed, 14 Jun 2023 20:46:04 GMT, Erik Joelsson wrote: > When a user creates a backport PR using the /backport command, they are supposed to get push access to the branch in the fork repository. On GitHub, this has stopped working (assuming it ever worked). Experimentation shows that for a user to be eligible for listing in a branch protection rule, that user must first have push access in the repository. Just having a pending invite is not enough. When a user issues the /backport command, an invite is automatically sent to become a collaborator with push access in the repository, but the user has to accept it before it comes into effect. > > Given this, I don't see a way to consistently provide branch level push access restrictions for the fork repositories. But instead of removing the feature completely, we can apply it when possible. The first /backport by a user will not get exclusive push access, but if the user accepts the invite before the next time, then from then on, any new backport branches will be protected. Not sure if this is worth it, but since we have the functionality, we may as well apply it when possible. This pull request has now been integrated. Changeset: 9af46280 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/9af462809a696150305935218f2501941262a7c5 Stats: 17 lines in 2 files changed: 16 ins; 1 del; 0 mod 1948: User not getting push access to backport branch Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1532 From erikj at openjdk.org Wed Jun 14 22:26:14 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 14 Jun 2023 22:26:14 GMT Subject: RFR: 1890: Add method deployKeyTitles [v3] In-Reply-To: References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: <8N3hrDgR97NiYPh31x4cIus6semU4C4jYyAcOHvW4do=.9bcaad69-1d5f-4f27-89d4-41e109b1a156@github.com> On Tue, 25 Apr 2023 22:55:31 GMT, Zhao Song wrote: >> Add a new method called getExpiredDeployKeys in HostedRepository > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update tests name Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1508#pullrequestreview-1480396697 From zsong at openjdk.org Thu Jun 15 17:14:39 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 15 Jun 2023 17:14:39 GMT Subject: RFR: 1890: Add method deployKeyTitles [v4] In-Reply-To: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: > Add a new method called getExpiredDeployKeys in HostedRepository Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge remote-tracking branch 'origin/master' into SKARA-1890 # Conflicts: # bots/tester/src/test/java/org/openjdk/skara/bots/tester/InMemoryHostedRepository.java # forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java # forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java # forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java # forge/src/test/java/org/openjdk/skara/forge/github/GitHubRestApiTests.java - update tests name - update method name - SKARA-1890 ------------- Changes: https://git.openjdk.org/skara/pull/1508/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1508&range=03 Stats: 93 lines in 7 files changed: 89 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1508.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1508/head:pull/1508 PR: https://git.openjdk.org/skara/pull/1508 From zsong at openjdk.org Thu Jun 15 17:27:01 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 15 Jun 2023 17:27:01 GMT Subject: RFR: 1890: Add method deployKeyTitles [v5] In-Reply-To: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: > Add a new method called getExpiredDeployKeys in HostedRepository Zhao Song has updated the pull request incrementally with one additional commit since the last revision: override deployKeyTitles in BitbucketRepository ------------- Changes: - all: https://git.openjdk.org/skara/pull/1508/files - new: https://git.openjdk.org/skara/pull/1508/files/b4d0e370..bdd49907 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1508&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1508&range=03-04 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1508.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1508/head:pull/1508 PR: https://git.openjdk.org/skara/pull/1508 From erikj at openjdk.org Thu Jun 15 17:36:47 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 15 Jun 2023 17:36:47 GMT Subject: RFR: 1890: Add method deployKeyTitles [v5] In-Reply-To: References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: <6CuJfTeyvSOxCIUNXQVGIM0mttWX0LwPCW6j-p8v34I=.67bebe7e-39da-469f-a8fb-8d97df35590c@github.com> On Thu, 15 Jun 2023 17:27:01 GMT, Zhao Song wrote: >> Add a new method called getExpiredDeployKeys in HostedRepository > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > override deployKeyTitles in BitbucketRepository Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1508#pullrequestreview-1482097559 From zsong at openjdk.org Thu Jun 15 18:16:13 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 15 Jun 2023 18:16:13 GMT Subject: RFR: 1890: Add method deployKeyTitles [v5] In-Reply-To: References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: <9vncNNM-ouSv9p993oZZIpmHzW7JFnUfGu2wr-_fyyk=.8c0a1baf-a648-441d-9527-5274822e9824@github.com> On Thu, 15 Jun 2023 17:27:01 GMT, Zhao Song wrote: >> Add a new method called getExpiredDeployKeys in HostedRepository > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > override deployKeyTitles in BitbucketRepository Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1508#issuecomment-1593523773 From zsong at openjdk.org Thu Jun 15 18:16:13 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 15 Jun 2023 18:16:13 GMT Subject: Integrated: 1890: Add method deployKeyTitles In-Reply-To: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> References: <8JBUbYhw6_S7MKOwm0opCEUNapohdbmJHXEw3Gx_vv8=.526a45e7-b15b-42ff-ae52-5e712f60f5c0@github.com> Message-ID: On Tue, 25 Apr 2023 19:01:25 GMT, Zhao Song wrote: > Add a new method called getExpiredDeployKeys in HostedRepository This pull request has now been integrated. Changeset: 91a03d15 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/91a03d15ead5f268daec8bcdcaa2541108b991a8 Stats: 98 lines in 8 files changed: 94 ins; 0 del; 4 mod 1890: Add method deployKeyTitles Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1508 From zsong at openjdk.org Thu Jun 15 22:12:56 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 15 Jun 2023 22:12:56 GMT Subject: RFR: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch Message-ID: [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. ------------- Commit messages: - SKARA-1950 Changes: https://git.openjdk.org/skara/pull/1533/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1533&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1950 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1533.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1533/head:pull/1533 PR: https://git.openjdk.org/skara/pull/1533 From erikj at openjdk.org Fri Jun 16 13:11:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 16 Jun 2023 13:11:51 GMT Subject: RFR: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch In-Reply-To: References: Message-ID: <7_fj8aJPUYSHMOtPq4Gdpn6yd_oKF2xe7pQBQmFFXp8=.ad230343-e02d-496b-b1ab-58427e8cf16d@github.com> On Thu, 15 Jun 2023 20:49:14 GMT, Zhao Song wrote: > [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. > > In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1373: > 1371: > 1372: private boolean isFileUpdated(String filename, Hash hash) throws IOException { > 1373: return localRepo.show(Path.of(filename), hash).isPresent() && We can make this check a bit cheaper by calling `!localRepo.files(hash, Path.of(filename)).isEmpty()` instead. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1533#discussion_r1232232508 From zsong at openjdk.org Fri Jun 16 16:05:57 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 16 Jun 2023 16:05:57 GMT Subject: RFR: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch In-Reply-To: <7_fj8aJPUYSHMOtPq4Gdpn6yd_oKF2xe7pQBQmFFXp8=.ad230343-e02d-496b-b1ab-58427e8cf16d@github.com> References: <7_fj8aJPUYSHMOtPq4Gdpn6yd_oKF2xe7pQBQmFFXp8=.ad230343-e02d-496b-b1ab-58427e8cf16d@github.com> Message-ID: <2tvny8LDNVC0hRk8oDN4wB3GOJSULaLLObCtck_a_us=.74807a5c-fd4d-4347-ae28-5557c7097d57@github.com> On Fri, 16 Jun 2023 13:09:37 GMT, Erik Joelsson wrote: >> [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. >> >> In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1373: > >> 1371: >> 1372: private boolean isFileUpdated(String filename, Hash hash) throws IOException { >> 1373: return localRepo.show(Path.of(filename), hash).isPresent() && > > We can make this check a bit cheaper by calling `!localRepo.files(hash, Path.of(filename)).isEmpty()` instead. Yes, it will be cheaper. Thanks! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1533#discussion_r1232438002 From zsong at openjdk.org Fri Jun 16 16:12:52 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 16 Jun 2023 16:12:52 GMT Subject: RFR: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch [v2] In-Reply-To: References: Message-ID: <46rxbllyq5L8zGOEHScRy76B1NuXNM7pA8EO8JLtwFQ=.641562e1-3f2b-4060-a664-8ccf0b08fd21@github.com> > [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. > > In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/skara/pull/1533/files - new: https://git.openjdk.org/skara/pull/1533/files/ae0e09d0..77a6602f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1533&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1533&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1533.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1533/head:pull/1533 PR: https://git.openjdk.org/skara/pull/1533 From erikj at openjdk.org Fri Jun 16 16:20:24 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 16 Jun 2023 16:20:24 GMT Subject: RFR: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch [v2] In-Reply-To: <46rxbllyq5L8zGOEHScRy76B1NuXNM7pA8EO8JLtwFQ=.641562e1-3f2b-4060-a664-8ccf0b08fd21@github.com> References: <46rxbllyq5L8zGOEHScRy76B1NuXNM7pA8EO8JLtwFQ=.641562e1-3f2b-4060-a664-8ccf0b08fd21@github.com> Message-ID: On Fri, 16 Jun 2023 16:12:52 GMT, Zhao Song wrote: >> [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. >> >> In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1533#pullrequestreview-1483866413 From zsong at openjdk.org Fri Jun 16 16:32:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 16 Jun 2023 16:32:24 GMT Subject: Integrated: 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch In-Reply-To: References: Message-ID: <9DPgTH8yS3pQuy8l9clcgnheVeld2xf-Cb9Lf6buPjk=.b76b42a6-1db1-4497-8795-34d85839d86b@github.com> On Thu, 15 Jun 2023 20:49:14 GMT, Zhao Song wrote: > [SKARA-1937](https://bugs.openjdk.org/browse/SKARA-1937) triggered CheckWorkItem for many ?ancient? prs and if the pr?s source branch doesn?t contain .jcheck/conf , it would trigger the second run of jcheck and then throw some exceptions. > > In this patch, before the bot runs the second round of jcheck, it will check if .jcheck/conf exists in the "merge" branch. This pull request has now been integrated. Changeset: 8a63cc27 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/8a63cc27a1041498941310ea7757fc5bd60d06d3 Stats: 7 lines in 2 files changed: 1 ins; 0 del; 6 mod 1950: Don't run the second jcheck if there is no .jcheck/conf in source branch Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1533 From erikj at openjdk.org Fri Jun 16 22:09:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 16 Jun 2023 22:09:31 GMT Subject: RFR: 1951: Refactor Issue class hierarchy Message-ID: The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. ------------- Commit messages: - copyrights - SKARA-1951 Changes: https://git.openjdk.org/skara/pull/1534/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1534&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1951 Stats: 1046 lines in 39 files changed: 484 ins; 425 del; 137 mod Patch: https://git.openjdk.org/skara/pull/1534.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/skara/pull/1534 From christoph.langer at sap.com Mon Jun 19 12:26:35 2023 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 19 Jun 2023 12:26:35 +0000 Subject: Code branch annotation missing in Skara backport emails for jdk21 Message-ID: Hi, with the new backport process from jdk->jdk21, I?m noticing that the mails regarding these backports are not prefixed like [jdk21] any more but go annotated and one needs to always look twice whether a commit is a backport or a development in head. Are you aware of that and would you consider to fix this? Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Jun 19 13:45:17 2023 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 19 Jun 2023 06:45:17 -0700 Subject: Code branch annotation missing in Skara backport emails for jdk21 In-Reply-To: References: Message-ID: <78c084b8-12ab-f968-327b-40b1f70e7d5a@oracle.com> Hi Christoph, This was unintentional. Thanks for reporting it. I filed https://bugs.openjdk.org/browse/SKARA-1952 to track this. -- Kevin On 6/19/2023 5:26 AM, Langer, Christoph wrote: > > Hi, > > with the new backport process from jdk->jdk21, I?m noticing that the > mails regarding these backports are not prefixed like [jdk21] any more > but go annotated and one needs to always look twice whether a commit > is a backport or a development in head. Are you aware of that and > would you consider to fix this? > > Thanks > > Christoph > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christoph.langer at sap.com Mon Jun 19 13:51:18 2023 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 19 Jun 2023 13:51:18 +0000 Subject: Code branch annotation missing in Skara backport emails for jdk21 In-Reply-To: <78c084b8-12ab-f968-327b-40b1f70e7d5a@oracle.com> References: <78c084b8-12ab-f968-327b-40b1f70e7d5a@oracle.com> Message-ID: Thanks, Kevin. I?ll watch the bug for resolution then. From: skara-dev On Behalf Of Kevin Rushforth Sent: Montag, 19. Juni 2023 15:45 To: skara-dev at openjdk.org Subject: Re: Code branch annotation missing in Skara backport emails for jdk21 Hi Christoph, This was unintentional. Thanks for reporting it. I filed https://bugs.openjdk.org/browse/SKARA-1952 to track this. -- Kevin On 6/19/2023 5:26 AM, Langer, Christoph wrote: Hi, with the new backport process from jdk->jdk21, I?m noticing that the mails regarding these backports are not prefixed like [jdk21] any more but go annotated and one needs to always look twice whether a commit is a backport or a development in head. Are you aware of that and would you consider to fix this? Thanks Christoph -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsong at openjdk.org Tue Jun 20 19:29:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 20 Jun 2023 19:29:38 GMT Subject: RFR: 1951: Refactor Issue class hierarchy In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 22:05:31 GMT, Erik Joelsson wrote: > The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. > > In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. > > I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. > > The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. I think this patch is good, and your design of the class hierarchy makes a lot of sense. I just have these minor suggestions. Additionally, copyrights in some updated files need to be updated. Furthermore, regarding setting or getting the state of an IssueTrackerIssue or a Pull Request, we currently utilize `Issue.State.XXX`. However, I think it might be better to use `IssueTrackerIssue.State.XXX` and `PullRequest.State.XXX`. bots/jep/src/test/java/org/openjdk/skara/bots/jep/JEPBotTests.java line 27: > 25: import org.junit.jupiter.api.Test; > 26: import org.junit.jupiter.api.TestInfo; > 27: import org.openjdk.skara.issuetracker.Issue; We could remove this ` import org.openjdk.skara.issuetracker.Issue;` bots/pr/src/main/java/org/openjdk/skara/bots/pr/JEPCommand.java line 33: > 31: import java.util.List; > 32: import java.util.Optional; > 33: import org.openjdk.skara.issuetracker.IssueTrackerIssue; `import org.openjdk.skara.issuetracker.Issue;` in line 28 can be removed bots/pr/src/test/java/org/openjdk/skara/bots/pr/IssueTests.java line 435: > 433: var editHash = CheckableRepository.appendAndCommit(localRepo); > 434: localRepo.push(editHash, author.authenticatedUrl(), "edit", true); > 435: var issue1 = (TestIssueTrackerIssue)issues.createIssue("First", List.of("Hello"), Map.of()); Suggestion: var issue1 = (TestIssueTrackerIssue) issues.createIssue("First", List.of("Hello"), Map.of()); bots/pr/src/test/java/org/openjdk/skara/bots/pr/IssueTests.java line 476: > 474: var editHash = CheckableRepository.appendAndCommit(localRepo); > 475: localRepo.push(editHash, author.authenticatedUrl(), "edit", true); > 476: var issue1 = (TestIssueTrackerIssue)issues.createIssue("First", List.of("Hello"), Map.of()); Suggestion: var issue1 = (TestIssueTrackerIssue) issues.createIssue("First", List.of("Hello"), Map.of()); jbs/src/main/java/org/openjdk/skara/jbs/Backports.java line 257: > 255: log.fine("Searching for fixed issue with fix version matching /" + versionPattern + "/ " > 256: + " for primary issue " + primary.id()); > 257: return Stream.concat(Stream.of(primary).filter(Issue::isFixed), findBackports(primary, true).stream()) I think `Issue` here could be changed to `IssueTrackerIssue`. Therefore, we don't need to import `org.openjdk.skara.issuetracker.Issue` in this class anymore. test/src/main/java/org/openjdk/skara/test/TestIssueStore.java line 59: > 57: this.title = title; > 58: this.body = String.join("\n", body); > 59: Maybe this line is extra test/src/main/java/org/openjdk/skara/test/TestPullRequest.java line 69: > 67: protected TestPullRequest copy() { > 68: return new TestPullRequest(store(), targetRepository); > 69: } Do we still need this method? There is no usage of this method ------------- PR Review: https://git.openjdk.org/skara/pull/1534#pullrequestreview-1488676752 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235657242 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235717885 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235720607 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235721454 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235602742 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235645147 PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235650313 From zsong at openjdk.org Tue Jun 20 19:29:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 20 Jun 2023 19:29:38 GMT Subject: RFR: 1951: Refactor Issue class hierarchy In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 19:15:06 GMT, Zhao Song wrote: >> The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. >> >> In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. >> >> I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. >> >> The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. > > bots/pr/src/test/java/org/openjdk/skara/bots/pr/IssueTests.java line 435: > >> 433: var editHash = CheckableRepository.appendAndCommit(localRepo); >> 434: localRepo.push(editHash, author.authenticatedUrl(), "edit", true); >> 435: var issue1 = (TestIssueTrackerIssue)issues.createIssue("First", List.of("Hello"), Map.of()); > > Suggestion: > > var issue1 = (TestIssueTrackerIssue) issues.createIssue("First", List.of("Hello"), Map.of()); It's my fault, I forgot to add the whitespace when writing the tests ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1534#discussion_r1235723284 From erikj at openjdk.org Wed Jun 21 08:57:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 Jun 2023 08:57:39 GMT Subject: RFR: 1951: Refactor Issue class hierarchy In-Reply-To: References: Message-ID: On Tue, 20 Jun 2023 19:27:08 GMT, Zhao Song wrote: > Furthermore, regarding setting or getting the state of an IssueTrackerIssue or a Pull Request, we currently utilize `Issue.State.XXX`. However, I think it might be better to use `IssueTrackerIssue.State.XXX` and `PullRequest.State.XXX`. Not sure if you mean that we should have separate state enums for `IssueTrackerIssue` and `PullRequest` or if you are just wanting to save an import by referencing the enum through the sub interfaces. If the former, then if we need to express different states in issues vs pull requests, then yes we should have different enums, but I don't think we do right now at least. If the later, I don't think optimizing or reducing imports is something to strive for. They are handled automatically by the IDE. Another variant of this change would be to remove the common super interface between issue and pull request completely. It really is a false abstraction to begin with. ------------- PR Comment: https://git.openjdk.org/skara/pull/1534#issuecomment-1600454762 From erikj at openjdk.org Wed Jun 21 09:38:38 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 Jun 2023 09:38:38 GMT Subject: RFR: 1951: Refactor Issue class hierarchy [v2] In-Reply-To: References: Message-ID: <1juVNdyi1mzoRvmxH4L8DDqBNTpRL4fUmE42-f5qcuM=.b6dbd88a-ebaf-458c-847a-eb0c6d3fec99@github.com> > The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. > > In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. > > I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. > > The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: More copyrights and review comments ------------- Changes: - all: https://git.openjdk.org/skara/pull/1534/files - new: https://git.openjdk.org/skara/pull/1534/files/6097c019..d1c0fc33 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1534&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1534&range=00-01 Stats: 28 lines in 22 files changed: 0 ins; 8 del; 20 mod Patch: https://git.openjdk.org/skara/pull/1534.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1534/head:pull/1534 PR: https://git.openjdk.org/skara/pull/1534 From zsong at openjdk.org Wed Jun 21 17:00:08 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 21 Jun 2023 17:00:08 GMT Subject: RFR: 1951: Refactor Issue class hierarchy [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jun 2023 08:55:13 GMT, Erik Joelsson wrote: > > Furthermore, regarding setting or getting the state of an IssueTrackerIssue or a Pull Request, we currently utilize `Issue.State.XXX`. However, I think it might be better to use `IssueTrackerIssue.State.XXX` and `PullRequest.State.XXX`. > > Not sure if you mean that we should have separate state enums for `IssueTrackerIssue` and `PullRequest` or if you are just wanting to save an import by referencing the enum through the sub interfaces. If the former, then if we need to express different states in issues vs pull requests, then yes we should have different enums, but I don't think we do right now at least. If the later, I don't think optimizing or reducing imports is something to strive for. They are handled automatically by the IDE. > > Another variant of this change would be to remove the common super interface between issue and pull request completely. It really is a false abstraction to begin with. What I mean was the later one. I was thinking using a specific subtype of `Issue` would be better. It could help us to distinguish between an Issue and a pull request. And also, if later we want to separate state enums for `IssueTrackerIssue` and `PullRequest`, it could save us some work. ------------- PR Comment: https://git.openjdk.org/skara/pull/1534#issuecomment-1601222831 From zsong at openjdk.org Wed Jun 21 17:00:08 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 21 Jun 2023 17:00:08 GMT Subject: RFR: 1951: Refactor Issue class hierarchy [v2] In-Reply-To: <1juVNdyi1mzoRvmxH4L8DDqBNTpRL4fUmE42-f5qcuM=.b6dbd88a-ebaf-458c-847a-eb0c6d3fec99@github.com> References: <1juVNdyi1mzoRvmxH4L8DDqBNTpRL4fUmE42-f5qcuM=.b6dbd88a-ebaf-458c-847a-eb0c6d3fec99@github.com> Message-ID: On Wed, 21 Jun 2023 09:38:38 GMT, Erik Joelsson wrote: >> The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. >> >> In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. >> >> I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. >> >> The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > More copyrights and review comments Looks good now ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1534#pullrequestreview-1491263117 From erikj at openjdk.org Wed Jun 21 17:15:38 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 Jun 2023 17:15:38 GMT Subject: RFR: 1951: Refactor Issue class hierarchy [v2] In-Reply-To: <1juVNdyi1mzoRvmxH4L8DDqBNTpRL4fUmE42-f5qcuM=.b6dbd88a-ebaf-458c-847a-eb0c6d3fec99@github.com> References: <1juVNdyi1mzoRvmxH4L8DDqBNTpRL4fUmE42-f5qcuM=.b6dbd88a-ebaf-458c-847a-eb0c6d3fec99@github.com> Message-ID: On Wed, 21 Jun 2023 09:38:38 GMT, Erik Joelsson wrote: >> The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. >> >> In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. >> >> I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. >> >> The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > More copyrights and review comments Thanks for review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1534#issuecomment-1601255873 From erikj at openjdk.org Wed Jun 21 17:15:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 Jun 2023 17:15:39 GMT Subject: Integrated: 1951: Refactor Issue class hierarchy In-Reply-To: References: Message-ID: On Fri, 16 Jun 2023 22:05:31 GMT, Erik Joelsson wrote: > The class hierarchy around the (org.openjdk.skara.issuetracker.)Issue interface is weird and cumbersome to work with. This interface is representing an Issue as returned from an IssueTracker. It's implemented by `JiraIssue` (and `TestIssue` for testing purposes). It's also extended by `PullRequest`, which makes it awkward to add Jira/bug tracker specific functionality to it since we must then also implement that for all `PullRequest` implementations (usually by just throwing a runtime exception). It's rare to use `Issue` as something that can be either a `PullRequest` or an actual issue, so sharing this interface isn't adding much value. > > In addition to this, there is also an unrelated class called Issue (org.openjdk.skara.vcs.openjdk.Issue) in the vcs module. This class just represents the OpenJDK interpretation of an issue in the context of a commit message. These classes are however used together sometimes, which is causing a lot of confusion. > > I would like to improve this situation. My proposal is to introduce a new interface `IssueTrackerIssue` which is a sub type of `Issue` that contains methods specific to bug trackers (or at least Jira). In practice right now this is links and properties. The name reflects that this is the kind of issue returned from an `IssueTracker` as opposed to an Issue from just any kind of `Forge`. Having that in an interface enables us to also define a specific test implementation `TestIssueTrackerIssue` that mimics our `JiraIssue` implementation without clashing with `PullRequest` and its implementations. With this new type name, we can also get around the clash when having to deal with the vcs Issue type. This solution retains the shared super interface `Issue` between `IssueTrackerIssue` and `PullRequest`. I'm also refactoring `TestIssue` and its subclasses to reflect this new hierarchy. > > The patch is pretty big, which is why I'm doing this in isolation. No functionality should change. This pull request has now been integrated. Changeset: 0eab93ee Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/0eab93eefd1159efc59a88a1f5f1a7ad7ef54907 Stats: 1068 lines in 39 files changed: 482 ins; 431 del; 155 mod 1951: Refactor Issue class hierarchy Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1534 From erikj at openjdk.org Mon Jun 26 14:37:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Jun 2023 14:37:41 GMT Subject: RFR: 1554: Fold JEPBot into PR bot Message-ID: This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In the CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the check run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite of this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. ------------- Commit messages: - All defaults in same place - SKARA-1554 Changes: https://git.openjdk.org/skara/pull/1535/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1535&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1554 Stats: 1044 lines in 21 files changed: 185 ins; 716 del; 143 mod Patch: https://git.openjdk.org/skara/pull/1535.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1535/head:pull/1535 PR: https://git.openjdk.org/skara/pull/1535 From erikj at openjdk.org Mon Jun 26 15:01:13 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Jun 2023 15:01:13 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v2] In-Reply-To: References: Message-ID: > This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. > > The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. > > Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. > > The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. > > The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Remove jep module ------------- Changes: - all: https://git.openjdk.org/skara/pull/1535/files - new: https://git.openjdk.org/skara/pull/1535/files/0c9b9eaa..256d519f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1535&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1535&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1535.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1535/head:pull/1535 PR: https://git.openjdk.org/skara/pull/1535 From erikj at openjdk.org Mon Jun 26 16:22:44 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Jun 2023 16:22:44 GMT Subject: RFR: 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun Message-ID: This patch adds a cache for `IssueTrackerIssue` in `CheckWorkItem`. This will ensure that we only ever fetch issues from the issue project once in each work item. I'm also inlining the rather common `IssueProject` null check wherever possible. Note that this patch is built on top of #1535 so will go in after that one. Doing this also fixes a flaw with the current metadata hash logic. At the end of a check run, the metadata hash is updated. The current implementation fetches all issues again at that point, which means that we may store an updated version of an issue, that hasn't been part of the check run, in the hash. With this change, we are guaranteed to store the same issue state as was used in the check run. ------------- Depends on: https://git.openjdk.org/skara/pull/1535 Commit messages: - SKARA-1963 Changes: https://git.openjdk.org/skara/pull/1536/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1536&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1963 Stats: 28 lines in 2 files changed: 14 ins; 4 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1536.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1536/head:pull/1536 PR: https://git.openjdk.org/skara/pull/1536 From zsong at openjdk.org Mon Jun 26 23:18:09 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 26 Jun 2023 23:18:09 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 15:01:13 GMT, Erik Joelsson wrote: >> This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. >> >> The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. >> >> Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. >> >> The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. >> >> The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove jep module Looks good. Just two trivial issues. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 330: > 328: > 329: var issueProject = issueProject(); > 330: if (issueProject != null) { Do we still need to check `issueProject ` here? bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1399: > 1397: > 1398: var resolution = csr.properties().get("resolution"); > 1399: if (resolution == null || resolution.isNull()) { We could also use `csr.resolution()` here. But the logic here is a little bit complex. Maybe I could do it in a later patch. test/src/main/java/org/openjdk/skara/test/TestHost.java line 30: > 28: import org.openjdk.skara.issuetracker.*; > 29: import org.openjdk.skara.json.JSON; > 30: import org.openjdk.skara.json.JSONObject; These imports are never used. ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1535#pullrequestreview-1499580265 PR Review Comment: https://git.openjdk.org/skara/pull/1535#discussion_r1242876538 PR Review Comment: https://git.openjdk.org/skara/pull/1535#discussion_r1242874652 PR Review Comment: https://git.openjdk.org/skara/pull/1535#discussion_r1242907801 From zsong at openjdk.org Mon Jun 26 23:28:09 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 26 Jun 2023 23:28:09 GMT Subject: RFR: 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 16:13:57 GMT, Erik Joelsson wrote: > This patch adds a cache for `IssueTrackerIssue` in `CheckWorkItem`. This will ensure that we only ever fetch issues from the issue project once in each work item. I'm also inlining the rather common `IssueProject` null check wherever possible. > > Note that this patch is built on top of #1535 so will go in after that one. > > Doing this also fixes a flaw with the current metadata hash logic. At the end of a check run, the metadata hash is updated. The current implementation fetches all issues again at that point, which means that we may store an updated version of an issue, that hasn't been part of the check run, in the hash. With this change, we are guaranteed to store the same issue state as was used in the check run. Looks good bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 35: > 33: import org.openjdk.skara.issuetracker.Issue; > 34: import org.openjdk.skara.issuetracker.IssueTrackerIssue; > 35: import org.openjdk.skara.json.JSONValue; `import org.openjdk.skara.issuetracker.Issue;` and `import org.openjdk.skara.json.JSONValue;` can be removed ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1536#pullrequestreview-1499697268 PR Review Comment: https://git.openjdk.org/skara/pull/1536#discussion_r1242919418 From erikj at openjdk.org Tue Jun 27 13:08:10 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 13:08:10 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v3] In-Reply-To: References: Message-ID: > This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. > > The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. > > Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. > > The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. > > The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - Review followup - Review followup ------------- Changes: - all: https://git.openjdk.org/skara/pull/1535/files - new: https://git.openjdk.org/skara/pull/1535/files/256d519f..f8724909 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1535&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1535&range=01-02 Stats: 19 lines in 3 files changed: 0 ins; 14 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1535.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1535/head:pull/1535 PR: https://git.openjdk.org/skara/pull/1535 From erikj at openjdk.org Tue Jun 27 13:08:10 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 13:08:10 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 22:25:46 GMT, Zhao Song wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove jep module > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 330: > >> 328: >> 329: var issueProject = issueProject(); >> 330: if (issueProject != null) { > > Do we still need to check `issueProject ` here? I'm not completely sure, but if we don't, there is a risk that we change behavior when a bot is configured without an issue tracker/project. It would be a good followup to really investigate if that should be a valid configuration and how that is supposed to work. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1535#discussion_r1243698575 From erikj at openjdk.org Tue Jun 27 13:11:30 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 13:11:30 GMT Subject: RFR: 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun [v2] In-Reply-To: References: Message-ID: > This patch adds a cache for `IssueTrackerIssue` in `CheckWorkItem`. This will ensure that we only ever fetch issues from the issue project once in each work item. I'm also inlining the rather common `IssueProject` null check wherever possible. > > Note that this patch is built on top of #1535 so will go in after that one. > > Doing this also fixes a flaw with the current metadata hash logic. At the end of a check run, the metadata hash is updated. The current implementation fetches all issues again at that point, which means that we may store an updated version of an issue, that hasn't been part of the check run, in the hash. With this change, we are guaranteed to store the same issue state as was used in the check run. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'SKARA-1554-jepbot' into SKARA-1963-fetch-issue-once - SKARA-1963 ------------- Changes: https://git.openjdk.org/skara/pull/1536/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1536&range=01 Stats: 28 lines in 2 files changed: 14 ins; 4 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1536.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1536/head:pull/1536 PR: https://git.openjdk.org/skara/pull/1536 From zsong at openjdk.org Tue Jun 27 16:08:11 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 27 Jun 2023 16:08:11 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 13:01:44 GMT, Erik Joelsson wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 330: >> >>> 328: >>> 329: var issueProject = issueProject(); >>> 330: if (issueProject != null) { >> >> Do we still need to check `issueProject ` here? > > I'm not completely sure, but if we don't, there is a risk that we change behavior when a bot is configured without an issue tracker/project. It would be a good followup to really investigate if that should be a valid configuration and how that is supposed to work. Sure. It's no harm to keep the check here. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1535#discussion_r1244001411 From zsong at openjdk.org Tue Jun 27 16:14:40 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 27 Jun 2023 16:14:40 GMT Subject: RFR: 1554: Fold JEPBot into PR bot [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jun 2023 13:08:10 GMT, Erik Joelsson wrote: >> This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. >> >> The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. >> >> Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. >> >> The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. >> >> The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Review followup > - Review followup New commits are good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1535#pullrequestreview-1501371466 From erikj at openjdk.org Tue Jun 27 16:20:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 16:20:17 GMT Subject: Integrated: 1554: Fold JEPBot into PR bot In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 14:30:40 GMT, Erik Joelsson wrote: > This patch removes the JEPBot and moves the functionality into the pr bot module, similar to what SKARA-1851 did for CSRBot. Instead of introducing a new JEPBot in the pr bot module, I'm using the existing `IssueBot` from SKARA-1912 to poll for updated JEPs to process PRs for. > > The handling of different kinds of "Issues" in CheckRun was (and still to some extent is) rather messy. I've tried to tidy it up a bit in this patch, but didn't want to take it too far in a single change. In CheckRun, all issues are fetched in one place and stored in maps which are then used throughout the run. This also limits the amount of places where failure handling is needed. Hopefully SKARA-1963 can improve this aspect further. I also didn't want to change too much of the CSR issue handling in this patch, but I see some room for improvement there too. > > Now that all JEP issue handling is done in the pr bot module, we don't need to communicate between bots using labels. Despite this, I chose to leave the `jep` label working the same way as before: Adding it when the jep command is issued for adding a jep requirement and removing it when that requirement has been fulfilled, and also re-adding it if the requirement for some reason is no longer fulfilled. I think this will be the least confusing to users. However, one could also imagine the `jep` label just staying around signaling that this was a JEP PR, even after a PR has been integrated. > > The JEP test in `CheckTests` has been enhanced to verify that updates to the JEP issue are detected and handled, and that the label is updated accordingly by `CheckRun`. > > The issue metadata hash has been extended to include issue state and resolution, so that CheckRun will re-evaluate if any of those fields change for a JEP issue. Since we now have a separate `IssueTrackerIssue` interface, I chose to expose these fields directly through two new accessor methods instead of having to deal with complex and untyped properties everywhere. I've also added default values for status, priority and type for `TestIssueTrackerIssue` so that it mimics `JiraIssue` better in regards to those fields, and removed the null checks in the metadata hash calculation. This pull request has now been integrated. Changeset: 84922949 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/84922949fb3b4a175aeb6a283aaba12b864706fd Stats: 1055 lines in 22 files changed: 178 ins; 725 del; 152 mod 1554: Fold JEPBot into PR bot Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1535 From erikj at openjdk.org Tue Jun 27 17:00:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 17:00:39 GMT Subject: RFR: 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun [v3] In-Reply-To: References: Message-ID: <3Cr-kGfgHUVGia622PDUjgY_CqA_3CKs22k7HkaxxNA=.158552b3-5231-4eae-9e0a-3c1fa97c395e@github.com> > This patch adds a cache for `IssueTrackerIssue` in `CheckWorkItem`. This will ensure that we only ever fetch issues from the issue project once in each work item. I'm also inlining the rather common `IssueProject` null check wherever possible. > > Note that this patch is built on top of #1535 so will go in after that one. > > Doing this also fixes a flaw with the current metadata hash logic. At the end of a check run, the metadata hash is updated. The current implementation fetches all issues again at that point, which means that we may store an updated version of an issue, that hasn't been part of the check run, in the hash. With this change, we are guaranteed to store the same issue state as was used in the check run. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge remote-tracking branch 'upstream/master' into SKARA-1963-fetch-issue-once - Merge branch 'SKARA-1554-jepbot' into SKARA-1963-fetch-issue-once - Review followup - Review followup - SKARA-1963 - Remove jep module - All defaults in same place - SKARA-1554 ------------- Changes: https://git.openjdk.org/skara/pull/1536/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1536&range=02 Stats: 28 lines in 2 files changed: 14 ins; 4 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1536.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1536/head:pull/1536 PR: https://git.openjdk.org/skara/pull/1536 From erikj at openjdk.org Tue Jun 27 17:02:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 Jun 2023 17:02:54 GMT Subject: Integrated: 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun In-Reply-To: References: Message-ID: On Mon, 26 Jun 2023 16:13:57 GMT, Erik Joelsson wrote: > This patch adds a cache for `IssueTrackerIssue` in `CheckWorkItem`. This will ensure that we only ever fetch issues from the issue project once in each work item. I'm also inlining the rather common `IssueProject` null check wherever possible. > > Note that this patch is built on top of #1535 so will go in after that one. > > Doing this also fixes a flaw with the current metadata hash logic. At the end of a check run, the metadata hash is updated. The current implementation fetches all issues again at that point, which means that we may store an updated version of an issue, that hasn't been part of the check run, in the hash. With this change, we are guaranteed to store the same issue state as was used in the check run. This pull request has now been integrated. Changeset: ce35e09a Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/ce35e09a9cdadc3498fea543650953bb9048b853 Stats: 28 lines in 2 files changed: 14 ins; 4 del; 10 mod 1963: Reduce the frequency of fetching the same issue from IssueProject in CheckRun Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1536 From zsong at openjdk.org Tue Jun 27 22:28:00 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 27 Jun 2023 22:28:00 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects Message-ID: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> As Erik said in the description of this issue, currently, this issue only cares about tracking approval labels in the related bugs. If a repository is set up with the "approval" configuration, pull requests in that repository will require the maintainer's approval in JBS. Otherwise, the pull request will not be considered ready. Erik has also provided a design outlining how to configure the "approval" for a repository. The simple case, where the labels are the same for every branch in a repository: "approval": { "request": "jdk17u-fix-request", "approved": "jdk17u-fix-yes", "rejected": "jdk17u-fix-no", } To reduce the need for changing multiple strings when copying a configuration for a new repository, there is an optional "prefix" field: "approval": { "prefix": "jdk17u-fix-", "request": "request", "approved": "yes", "rejected": "no", } When there are multiple branches with different labels, having the prefix set per branch can help reduce the size of the configuration significantly: "approval": { "request": "-critical-request", "approved": "-critical-approved", "rejected": "-critical-rejected", "branches": [ "jdk20\.0\.1": { "prefix": "CPU23_04" } ] } ------------- Commit messages: - SKARA-1199 Changes: https://git.openjdk.org/skara/pull/1537/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1537&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1199 Stats: 265 lines in 9 files changed: 244 ins; 2 del; 19 mod Patch: https://git.openjdk.org/skara/pull/1537.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1537/head:pull/1537 PR: https://git.openjdk.org/skara/pull/1537 From erikj at openjdk.org Wed Jun 28 13:22:01 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 Jun 2023 13:22:01 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> Message-ID: On Tue, 27 Jun 2023 21:37:35 GMT, Zhao Song wrote: > As Erik said in the description of this issue, currently, this issue only cares about tracking approval labels in the related bugs. > > If a repository is set up with the "approval" configuration, pull requests in that repository will require the maintainer's approval in JBS. Otherwise, the pull request will not be considered ready. > > Erik has also provided a design outlining how to configure the "approval" for a repository. > > > The simple case, where the labels are the same for every branch in a repository: > > "approval": { > "request": "jdk17u-fix-request", > "approved": "jdk17u-fix-yes", > "rejected": "jdk17u-fix-no", > } > > To reduce the need for changing multiple strings when copying a configuration for a new repository, there is an optional "prefix" field: > > "approval": { > "prefix": "jdk17u-fix-", > "request": "request", > "approved": "yes", > "rejected": "no", > } > > When there are multiple branches with different labels, having the prefix set per branch can help reduce the size of the configuration significantly: > > "approval": { > "request": "-critical-request", > "approved": "-critical-approved", > "rejected": "-critical-rejected", > "branches": [ > "jdk20\.0\.1": { "prefix": "CPU23_04" } > ] > } When I looked at this again, I realized I missed a key functionality in my description. I've updated the bug and added a [comment](https://bugs.openjdk.org/browse/SKARA-1199?focusedCommentId=14592499&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14592499). bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 278: > 276: var labelNames = issue.labelNames(); > 277: if (labelNames.contains(approval.approvedLabel(pr.targetRef()))) { > 278: ret.put("[" + issue.id() + "](" + issue.webUrl() + ") needs maintainer approval in JBS", true); No need to reference JBS since we are already linking to the issue tracker with the issue id. In general we should avoid referencing specific issue tracker instances in source code. Suggestion: ret.put("[" + issue.id() + "](" + issue.webUrl() + ") needs maintainer approval", true); bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 280: > 278: ret.put("[" + issue.id() + "](" + issue.webUrl() + ") needs maintainer approval in JBS", true); > 279: } else { > 280: ret.put("[" + issue.id() + "](" + issue.webUrl() + ") needs maintainer approval in JBS", false); Suggestion: ret.put("[" + issue.id() + "](" + issue.webUrl() + ") needs maintainer approval", false); bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 712: > 710: status = "Requested"; > 711: } > 712: if (!status.isEmpty() && !status.isBlank()) { Checking just for empty should be enough here. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 182: > 180: issueData.append(properties.get("issuetype").asString()); > 181: } > 182: issueData.append(String.join("", issue.labelNames())); This is currently adding another query to the issue tracker, but that can actually be fixed, and I think it's worth doing that in this patch. You can override `Issue::labelNames` in `JiraIssue` and just read the names from the json. There is a labels field with the names in it. I had this in a local patch for a while but it didn't fit with the thing I was working on at the time, and then I forgot. ------------- PR Review: https://git.openjdk.org/skara/pull/1537#pullrequestreview-1503019313 PR Review Comment: https://git.openjdk.org/skara/pull/1537#discussion_r1245167449 PR Review Comment: https://git.openjdk.org/skara/pull/1537#discussion_r1245167944 PR Review Comment: https://git.openjdk.org/skara/pull/1537#discussion_r1245176010 PR Review Comment: https://git.openjdk.org/skara/pull/1537#discussion_r1245185515 From erikj at openjdk.org Wed Jun 28 13:38:42 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 Jun 2023 13:38:42 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> Message-ID: <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> On Tue, 27 Jun 2023 21:37:35 GMT, Zhao Song wrote: > As Erik said in the description of this issue, currently, this issue only cares about tracking approval labels in the related bugs. > > If a repository is set up with the "approval" configuration, pull requests in that repository will require the maintainer's approval in JBS. Otherwise, the pull request will not be considered ready. > > Erik has also provided a design outlining how to configure the "approval" for a repository. > > > The simple case, where the labels are the same for every branch in a repository: > > "approval": { > "request": "jdk17u-fix-request", > "approved": "jdk17u-fix-yes", > "rejected": "jdk17u-fix-no", > } > > To reduce the need for changing multiple strings when copying a configuration for a new repository, there is an optional "prefix" field: > > "approval": { > "prefix": "jdk17u-fix-", > "request": "request", > "approved": "yes", > "rejected": "no", > } > > When there are multiple branches with different labels, having the prefix set per branch can help reduce the size of the configuration significantly: > > "approval": { > "request": "-critical-request", > "approved": "-critical-approved", > "rejected": "-critical-rejected", > "branches": [ > "jdk20\.0\.1": { "prefix": "CPU23_04" } > ] > } When a PR is ready with everything but approval, we should also update the status comment with a helpful message linking to the approval process. This is the same comment where the "ready to integrate" message is posted. That link needs to be configurable. ------------- PR Comment: https://git.openjdk.org/skara/pull/1537#issuecomment-1611428897 From zsong at openjdk.org Thu Jun 29 16:30:12 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 29 Jun 2023 16:30:12 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v2] In-Reply-To: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> Message-ID: > As Erik said in the description of this issue, currently, this issue only cares about tracking approval labels in the related bugs. > > If a repository is set up with the "approval" configuration, pull requests in that repository will require the maintainer's approval in JBS. Otherwise, the pull request will not be considered ready. > > Erik has also provided a design outlining how to configure the "approval" for a repository. > > > The simple case, where the labels are the same for every branch in a repository: > > "approval": { > "request": "jdk17u-fix-request", > "approved": "jdk17u-fix-yes", > "rejected": "jdk17u-fix-no", > } > > To reduce the need for changing multiple strings when copying a configuration for a new repository, there is an optional "prefix" field: > > "approval": { > "prefix": "jdk17u-fix-", > "request": "request", > "approved": "yes", > "rejected": "no", > } > > When there are multiple branches with different labels, having the prefix set per branch can help reduce the size of the configuration significantly: > > "approval": { > "request": "-critical-request", > "approved": "-critical-approved", > "rejected": "-critical-rejected", > "branches": [ > "jdk20\.0\.1": { "prefix": "CPU23_04" } > ] > } Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1537/files - new: https://git.openjdk.org/skara/pull/1537/files/a5eb7f35..83196d1a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1537&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1537&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1537.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1537/head:pull/1537 PR: https://git.openjdk.org/skara/pull/1537 From zsong at openjdk.org Thu Jun 29 16:46:29 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 29 Jun 2023 16:46:29 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> Message-ID: On Wed, 28 Jun 2023 13:36:34 GMT, Erik Joelsson wrote: > When a PR is ready with everything but approval, we should also update the status comment with a helpful message linking to the approval process. This is the same comment where the "ready to integrate" message is posted. That link needs to be configurable. Do you mean the `mergeReadyComment`?(I saw your comment in the issue description) But currently, the maintainer approval is a `progress`. The PR would not be considered ready without maintainer approval label in the related issue, and the mergeReadyComment would not be posted unless the PR is considered ready. ------------- PR Comment: https://git.openjdk.org/skara/pull/1537#issuecomment-1613516298 From zsong at openjdk.org Thu Jun 29 18:12:31 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 29 Jun 2023 18:12:31 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v3] In-Reply-To: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> Message-ID: > As Erik said in the description of this issue, currently, this issue only cares about tracking approval labels in the related bugs. > > If a repository is set up with the "approval" configuration, pull requests in that repository will require the maintainer's approval in JBS. Otherwise, the pull request will not be considered ready. > > Erik has also provided a design outlining how to configure the "approval" for a repository. > > > The simple case, where the labels are the same for every branch in a repository: > > "approval": { > "request": "jdk17u-fix-request", > "approved": "jdk17u-fix-yes", > "rejected": "jdk17u-fix-no", > } > > To reduce the need for changing multiple strings when copying a configuration for a new repository, there is an optional "prefix" field: > > "approval": { > "prefix": "jdk17u-fix-", > "request": "request", > "approved": "yes", > "rejected": "no", > } > > When there are multiple branches with different labels, having the prefix set per branch can help reduce the size of the configuration significantly: > > "approval": { > "request": "-critical-request", > "approved": "-critical-approved", > "rejected": "-critical-rejected", > "branches": [ > "jdk20\.0\.1": { "prefix": "CPU23_04" } > ] > } 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/1537/files - new: https://git.openjdk.org/skara/pull/1537/files/83196d1a..9f682b0f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1537&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1537&range=01-02 Stats: 96 lines in 5 files changed: 91 ins; 0 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1537.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1537/head:pull/1537 PR: https://git.openjdk.org/skara/pull/1537 From erikj at openjdk.org Fri Jun 30 08:27:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 Jun 2023 08:27:54 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> Message-ID: <-4m8oumK55DajuDbPhFIz1I9n2P-K6elV6VoY6xVTlM=.470ebe58-9127-44c4-8900-ca7daf9acf90@github.com> On Thu, 29 Jun 2023 16:44:08 GMT, Zhao Song wrote: > > When a PR is ready with everything but approval, we should also update the status comment with a helpful message linking to the approval process. This is the same comment where the "ready to integrate" message is posted. That link needs to be configurable. > > Do you mean the `mergeReadyComment`?(I saw your comment in the issue description) But currently, the maintainer approval is a `progress`. The PR would not be considered ready without maintainer approval label in the related issue, and the mergeReadyComment would not be posted unless the PR is considered ready. That's what I meant. This would mean that we post the comment earlier and that we should rename the concept of that comment to something like `nextStepComment`. But maybe we shouldn't use the same comment, but instead introduce a new `approvalNeededComment`. Otherwise there is risk that it gets lost in the list of comments after a while. This new comment would be added when only the approval is left to do. Later in [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), the contents of this comment would be expanded to contain instructions for how to apply for maintainer approval using Skara commands. For now it can only reference the process documentation. ------------- PR Comment: https://git.openjdk.org/skara/pull/1537#issuecomment-1614311305 From zsong at openjdk.org Fri Jun 30 17:21:11 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 30 Jun 2023 17:21:11 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: <-4m8oumK55DajuDbPhFIz1I9n2P-K6elV6VoY6xVTlM=.470ebe58-9127-44c4-8900-ca7daf9acf90@github.com> References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> <-4m8oumK55DajuDbPhFIz1I9n2P-K6elV6VoY6xVTlM=.470ebe58-9127-44c4-8900-ca7daf9acf90@github.com> Message-ID: On Fri, 30 Jun 2023 08:25:47 GMT, Erik Joelsson wrote: > > > When a PR is ready with everything but approval, we should also update the status comment with a helpful message linking to the approval process. This is the same comment where the "ready to integrate" message is posted. That link needs to be configurable. > > > > > > Do you mean the `mergeReadyComment`?(I saw your comment in the issue description) But currently, the maintainer approval is a `progress`. The PR would not be considered ready without maintainer approval label in the related issue, and the mergeReadyComment would not be posted unless the PR is considered ready. > > That's what I meant. This would mean that we post the comment earlier and that we should rename the concept of that comment to something like `nextStepComment`. But maybe we shouldn't use the same comment, but instead introduce a new `approvalNeededComment`. Otherwise there is risk that it gets lost in the list of comments after a while. This new comment would be added when only the approval is left to do. Later in [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), the contents of this comment would be expanded to contain instructions for how to apply for maintainer approval using Skara commands. For now it can only reference the process documentation. Ah, got it! Would add the comment. ------------- PR Comment: https://git.openjdk.org/skara/pull/1537#issuecomment-1614949527 From zsong at openjdk.org Fri Jun 30 18:01:57 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 30 Jun 2023 18:01:57 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: References: <12R_tIUizQijaH9F4FNvDZCSMU7h2ePygV58rXyvtso=.0da22dd7-1142-48bb-8d8a-4b2ea56c4b61@github.com> <1AioH3sPuTPZ78kj1S5IvNIlw_TouAG3knl8qEqgono=.46cc3394-9555-41d3-ab9c-eda10504e401@github.com> <-4m8oumK55DajuDbPhFIz1I9n2P-K6elV6VoY6xVTlM=.470ebe58-9127-44c4-8900-ca7daf9acf90@github.com> Message-ID: <0zbdMxgfJd5QFcQhSq_YYYIMqhgXdmlDhId15Dv6paI=.968f35a7-8ed5-48ec-a884-7ac7f5beaa6e@github.com> On Fri, 30 Jun 2023 17:19:01 GMT, Zhao Song wrote: > > > When a PR is ready with everything but approval, we should also update the status comment with a helpful message linking to the approval process. This is the same comment where the "ready to integrate" message is posted. That link needs to be configurable. > > > > > > Do you mean the `mergeReadyComment`?(I saw your comment in the issue description) But currently, the maintainer approval is a `progress`. The PR would not be considered ready without maintainer approval label in the related issue, and the mergeReadyComment would not be posted unless the PR is considered ready. > > That's what I meant. This would mean that we post the comment earlier and that we should rename the concept of that comment to something like `nextStepComment`. But maybe we shouldn't use the same comment, but instead introduce a new `approvalNeededComment`. Otherwise there is risk that it gets lost in the list of comments after a while. This new comment would be added when only the approval is left to do. Later in [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), the contents of this comment would be expanded to contain instructions for how to apply for maintainer approval using Skara commands. For now it can only reference the process documentation. And now I am thinking why we only post `approvalNeededComment` when a PR is ready with everything but approval? What about posting `approvalNeededComment` when approval is missing? In this way, user could see the instructions earlier and they would have the time to apply for approval. ------------- PR Comment: https://git.openjdk.org/skara/pull/1537#issuecomment-1614991595