From zsong at openjdk.org Wed Nov 1 17:06:45 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 1 Nov 2023 17:06:45 GMT Subject: RFR: 2083: Add option for omitting messages about /approval command Message-ID: We don't need to notify users about the /approval command in all cases. So we should make it optional. Also the term "maintainer approval" may confuse users in some cases and we also need to make it configurable. ------------- Commit messages: - fix test - SKARA-2083 Changes: https://git.openjdk.org/skara/pull/1580/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1580&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2083 Stats: 43 lines in 7 files changed: 22 ins; 0 del; 21 mod Patch: https://git.openjdk.org/skara/pull/1580.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1580/head:pull/1580 PR: https://git.openjdk.org/skara/pull/1580 From erikj at openjdk.org Wed Nov 1 18:09:14 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 1 Nov 2023 18:09:14 GMT Subject: RFR: 2083: Add option for omitting messages about /approval command In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 16:50:56 GMT, Zhao Song wrote: > We don't need to notify users about the /approval command in all cases. So we should make it optional. > > Also the term "maintainer approval" may confuse users in some cases and we also need to make it configurable. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1580#pullrequestreview-1708761861 From zsong at openjdk.org Wed Nov 1 22:15:43 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 1 Nov 2023 22:15:43 GMT Subject: RFR: 2083: Add option for omitting messages about /approval command In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 16:50:56 GMT, Zhao Song wrote: > We don't need to notify users about the /approval command in all cases. So we should make it optional. > > Also the term "maintainer approval" may confuse users in some cases and we also need to make it configurable. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1580#issuecomment-1789762672 From zsong at openjdk.org Wed Nov 1 22:15:43 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 1 Nov 2023 22:15:43 GMT Subject: Integrated: 2083: Add option for omitting messages about /approval command In-Reply-To: References: Message-ID: On Wed, 1 Nov 2023 16:50:56 GMT, Zhao Song wrote: > We don't need to notify users about the /approval command in all cases. So we should make it optional. > > Also the term "maintainer approval" may confuse users in some cases and we also need to make it configurable. This pull request has now been integrated. Changeset: 1b290d88 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/1b290d88e774085904f9e10f13d79cf1f2fbc156 Stats: 43 lines in 7 files changed: 22 ins; 0 del; 21 mod 2083: Add option for omitting messages about /approval command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1580 From ehelin at openjdk.org Thu Nov 2 14:15:01 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 2 Nov 2023 14:15:01 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective Message-ID: Hi all, please review this fix for [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The fix consists of adding a special value (`disable`) to the key `minimum` in the `[checks "reviewers"]` subsection. This way the functionality enabled by the `minimum` key can be disabled by `AdditionalConfiguration.java` (since INI doesn't feature a way for keys to be unset). I also made the `ReviewersCheckConfiguration` a bit more strict - the `minimum` key should never be combined with the keys `lead`, `reviewers`, `committers`, `authors` or `contributors`. Finally I added tests for the above three scenarios. Thanks, Erik ------------- Commit messages: - skara-2088 Changes: https://git.openjdk.org/skara/pull/1581/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1581&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2088 Stats: 132 lines in 4 files changed: 109 ins; 2 del; 21 mod Patch: https://git.openjdk.org/skara/pull/1581.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1581/head:pull/1581 PR: https://git.openjdk.org/skara/pull/1581 From erikj at openjdk.org Thu Nov 2 15:11:30 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 2 Nov 2023 15:11:30 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 14:10:42 GMT, Erik Duveblad wrote: > Hi all, > > please review this fix for [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The fix consists of adding a special value (`disable`) to the key `minimum` in the `[checks "reviewers"]` subsection. This way the functionality enabled by the `minimum` key can be disabled by `AdditionalConfiguration.java` (since INI doesn't feature a way for keys to be unset). > > I also made the `ReviewersCheckConfiguration` a bit more strict - the `minimum` key should never be combined with the keys `lead`, `reviewers`, `committers`, `authors` or `contributors`. > > Finally I added tests for the above three scenarios. > > Thanks, > Erik Marked as reviewed by erikj (Lead). jcheck/src/main/java/org/openjdk/skara/jcheck/ReviewersConfiguration.java line 137: > 135: for (var role : List.of("lead", "reviewers", "committers", "authors", "contributors")) { > 136: if (s.contains(role)) { > 137: throw new IllegalStateException("Cannot combine 'minimum' with '" + role + "'"); Is there any risk that existing .jcheck/conf files will become invalid because of this new failure mode? ------------- PR Review: https://git.openjdk.org/skara/pull/1581#pullrequestreview-1710542841 PR Review Comment: https://git.openjdk.org/skara/pull/1581#discussion_r1380298946 From zsong at openjdk.org Thu Nov 2 17:32:25 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 2 Nov 2023 17:32:25 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 14:10:42 GMT, Erik Duveblad wrote: > Hi all, > > please review this fix for [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The fix consists of adding a special value (`disable`) to the key `minimum` in the `[checks "reviewers"]` subsection. This way the functionality enabled by the `minimum` key can be disabled by `AdditionalConfiguration.java` (since INI doesn't feature a way for keys to be unset). > > I also made the `ReviewersCheckConfiguration` a bit more strict - the `minimum` key should never be combined with the keys `lead`, `reviewers`, `committers`, `authors` or `contributors`. > > Finally I added tests for the above three scenarios. > > Thanks, > Erik Looks good bots/pr/src/test/java/org/openjdk/skara/bots/pr/AdditionalConfigurationTests.java line 25: > 23: package org.openjdk.skara.bots.pr; > 24: > 25: import org.openjdk.skara.forge.*; This import can be removed ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1581#pullrequestreview-1710878398 PR Review Comment: https://git.openjdk.org/skara/pull/1581#discussion_r1380533194 From zsong at openjdk.org Thu Nov 2 19:35:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 2 Nov 2023 19:35:05 GMT Subject: RFR: 2091: CheckRun fails with NPE if github fullName is null Message-ID: If a user doesn't set name in the GitHub profile, when the bot is trying to get the full name of the user, the bot would get `null` and in some cases, it will trigger NPE. To solve this problem, I think if the user doesn't set name, then the bot should use his username instead. ------------- Commit messages: - SKARA-2091 Changes: https://git.openjdk.org/skara/pull/1582/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1582&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2091 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1582.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1582/head:pull/1582 PR: https://git.openjdk.org/skara/pull/1582 From zsong at openjdk.org Thu Nov 2 19:35:06 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 2 Nov 2023 19:35:06 GMT Subject: RFR: 2091: CheckRun fails with NPE if github fullName is null In-Reply-To: References: Message-ID: <7Stoa4qtFcLs-sPlTs8qQxEbMXPUrn60UtI8CeQyqpg=.f1451853-58ef-4f20-bdb7-753bee771ad5@github.com> On Thu, 2 Nov 2023 19:24:53 GMT, Zhao Song wrote: > If a user doesn't set name in the GitHub profile, when the bot is trying to get the full name of the user, the bot would get `null` and in some cases, it will trigger NPE. > > To solve this problem, I think if the user doesn't set name, then the bot should use his username instead. windows test failed because of https://bugs.openjdk.org/browse/SKARA-2057 ------------- PR Comment: https://git.openjdk.org/skara/pull/1582#issuecomment-1791427490 From erikj at openjdk.org Thu Nov 2 19:37:26 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 2 Nov 2023 19:37:26 GMT Subject: RFR: 2091: CheckRun fails with NPE if github fullName is null In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 19:24:53 GMT, Zhao Song wrote: > If a user doesn't set name in the GitHub profile, when the bot is trying to get the full name of the user, the bot would get `null` and in some cases, it will trigger NPE. > > To solve this problem, I think if the user doesn't set name, then the bot should use his username instead. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1582#pullrequestreview-1711100806 From zsong at openjdk.org Thu Nov 2 19:50:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 2 Nov 2023 19:50:53 GMT Subject: RFR: 2091: CheckRun fails with NPE if github fullName is null In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 19:24:53 GMT, Zhao Song wrote: > If a user doesn't set name in the GitHub profile, when the bot is trying to get the full name of the user, the bot would get `null` and in some cases, it will trigger NPE. > > To solve this problem, I think if the user doesn't set name, then the bot should use his username instead. Thanks for the quick review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1582#issuecomment-1791447074 From zsong at openjdk.org Thu Nov 2 19:50:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 2 Nov 2023 19:50:53 GMT Subject: Integrated: 2091: CheckRun fails with NPE if github fullName is null In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 19:24:53 GMT, Zhao Song wrote: > If a user doesn't set name in the GitHub profile, when the bot is trying to get the full name of the user, the bot would get `null` and in some cases, it will trigger NPE. > > To solve this problem, I think if the user doesn't set name, then the bot should use his username instead. This pull request has now been integrated. Changeset: 0bbb9567 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/0bbb956701f2ebb1382f28c5e5b25634c7a8884e Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 2091: CheckRun fails with NPE if github fullName is null Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1582 From ehelin at openjdk.org Thu Nov 2 20:42:57 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 2 Nov 2023 20:42:57 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective [v2] In-Reply-To: References: Message-ID: <65h7K7XH4yEK4SpgUbA9PPNYUFociSfYQokTth6iu9U=.2a1024d4-c76e-48d0-ae8b-59f8547fe03a@github.com> > Hi all, > > please review this fix for [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The fix consists of adding a special value (`disable`) to the key `minimum` in the `[checks "reviewers"]` subsection. This way the functionality enabled by the `minimum` key can be disabled by `AdditionalConfiguration.java` (since INI doesn't feature a way for keys to be unset). > > I also made the `ReviewersCheckConfiguration` a bit more strict - the `minimum` key should never be combined with the keys `lead`, `reviewers`, `committers`, `authors` or `contributors`. > > Finally I added tests for the above three scenarios. > > Thanks, > Erik Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: remove import ------------- Changes: - all: https://git.openjdk.org/skara/pull/1581/files - new: https://git.openjdk.org/skara/pull/1581/files/f7e49b61..5e46899e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1581&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1581&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1581.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1581/head:pull/1581 PR: https://git.openjdk.org/skara/pull/1581 From ehelin at openjdk.org Thu Nov 2 20:42:58 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 2 Nov 2023 20:42:58 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 17:22:24 GMT, Zhao Song wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> remove import > > bots/pr/src/test/java/org/openjdk/skara/bots/pr/AdditionalConfigurationTests.java line 25: > >> 23: package org.openjdk.skara.bots.pr; >> 24: >> 25: import org.openjdk.skara.forge.*; > > This import can be removed Thanks, done! ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1581#discussion_r1380750178 From ehelin at openjdk.org Thu Nov 2 20:53:45 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 2 Nov 2023 20:53:45 GMT Subject: RFR: 2088: Skara /reviewers command is no longer effective [v2] In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 15:08:08 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> remove import > > jcheck/src/main/java/org/openjdk/skara/jcheck/ReviewersConfiguration.java line 137: > >> 135: for (var role : List.of("lead", "reviewers", "committers", "authors", "contributors")) { >> 136: if (s.contains(role)) { >> 137: throw new IllegalStateException("Cannot combine 'minimum' with '" + role + "'"); > > Is there any risk that existing .jcheck/conf files will become invalid because of this new failure mode? Yes, but I have never seen a `.jcheck/conf` file with both `minimum` and e.g. `reviewers` set. I looked through all github.com/openjdk repositories and there are only three non-archived repos that has `minimum` set: - [jmc](https://github.com/openjdk/jmc/blob/master/.jcheck/conf#L49) - [jmc-graphics](https://github.com/openjdk/jmc-graphics/blob/master/.jcheck/conf#L48) - [jfx11u](https://github.com/openjdk/jfx11u/blob/master/.jcheck/conf#L43) None of the above has conflicting keys set, so with this patch we will be able to handle them all. So I think we are good here ? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1581#discussion_r1380759458 From ehelin at openjdk.org Thu Nov 2 20:53:46 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 2 Nov 2023 20:53:46 GMT Subject: Integrated: 2088: Skara /reviewers command is no longer effective In-Reply-To: References: Message-ID: On Thu, 2 Nov 2023 14:10:42 GMT, Erik Duveblad wrote: > Hi all, > > please review this fix for [SKARA-2088](https://bugs.openjdk.org/browse/SKARA-2088). The fix consists of adding a special value (`disable`) to the key `minimum` in the `[checks "reviewers"]` subsection. This way the functionality enabled by the `minimum` key can be disabled by `AdditionalConfiguration.java` (since INI doesn't feature a way for keys to be unset). > > I also made the `ReviewersCheckConfiguration` a bit more strict - the `minimum` key should never be combined with the keys `lead`, `reviewers`, `committers`, `authors` or `contributors`. > > Finally I added tests for the above three scenarios. > > Thanks, > Erik This pull request has now been integrated. Changeset: 410d4e59 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/410d4e59bdbebc3a7b3d394dc52a51fedb47ae57 Stats: 131 lines in 4 files changed: 108 ins; 2 del; 21 mod 2088: Skara /reviewers command is no longer effective Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1581 From ehelin at openjdk.org Fri Nov 3 12:04:25 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 12:04:25 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. > > I have added that test that passes with this patch but fails without it. > > Thanks, > Erik Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - final review - refactor - whitespace - do not throw from checkStatus - Merge branch 'master' into pr-correct-jcheck-conf - Fix .jcheck/conf parsing in multiple places - 2082 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1578/files - new: https://git.openjdk.org/skara/pull/1578/files/2fdcc0dc..9a677529 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=00-01 Stats: 1381 lines in 43 files changed: 976 ins; 163 del; 242 mod Patch: https://git.openjdk.org/skara/pull/1578.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1578/head:pull/1578 PR: https://git.openjdk.org/skara/pull/1578 From ehelin at openjdk.org Fri Nov 3 13:10:52 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 13:10:52 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. > > I have added that test that passes with this patch but fails without it. > > Thanks, > Erik Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: optimize ------------- Changes: - all: https://git.openjdk.org/skara/pull/1578/files - new: https://git.openjdk.org/skara/pull/1578/files/9a677529..ef47a259 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=01-02 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1578.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1578/head:pull/1578 PR: https://git.openjdk.org/skara/pull/1578 From ehelin at openjdk.org Fri Nov 3 13:10:53 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 13:10:53 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v2] In-Reply-To: References: Message-ID: <5ZIERnEWXba0loy5Arw4mufdk7bhEWoj0JfzV6cdSsA=.56e14c55-57a1-4add-8cc8-2bc397a3d28c@github.com> On Fri, 3 Nov 2023 12:04:25 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. >> >> I have added that test that passes with this patch but fails without it. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - final review > - refactor > - whitespace > - do not throw from checkStatus > - Merge branch 'master' into pr-correct-jcheck-conf > - Fix .jcheck/conf parsing in multiple places > - 2082 Ok, so I spent quite a bit of time going through the places where we parse `.jcheck/conf`. I figured out the following: - for merge PRs we want to always test each commit in the PR with _both_ the target branch's `.jcheck/conf` and, if any commit in the PR updates `.jcheck/conf`, the `.jcheck/conf` present in the commit. This could be optimized to only test with the `.jcheck/conf` in the commit if the current commit, or any parents of the current commit, updated `.jcheck/conf`. But that seemed like a premature optimization given that the number of merge PR that changes `.jcheck/conf` most likely will be very few. - for regular pull requests we want to ensure that we are always using the `.jcheck/conf` from the target branch _with_ any additional configuration added (or using an overriding `.jcheck/conf` is that is set up). To enable this I moved this logic into `CheckablePullRequest.parseJCheckConfiguration`. The remainder of the patch is dealing with fall-out from the above two changes and aligning the code with them. Thanks, Erik PS. The tests failed due to JBS being down ------------- PR Comment: https://git.openjdk.org/skara/pull/1578#issuecomment-1792406636 From ehelin at openjdk.org Fri Nov 3 13:10:53 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 13:10:53 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: On Fri, 27 Oct 2023 13:25:30 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java line 34: > >> 32: >> 33: public class AdditionalConfiguration { >> 34: static List get(Optional conf, HostUser botUser, List comments, boolean reviewMerge) throws IOException { > > Using Optional as parameter isn't recommended, especially since we throw if it's empty. Is it truly optional here? I would think we should just `.orElseThrow()` at the parse call. Thanks, removed the use of `Optional` in the latest version. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1259: > >> 1257: >> 1258: Hash jcheckConfHash = checkablePullRequest.targetHash(); >> 1259: PullRequestCheckIssueVisitor visitor = checkablePullRequest.createVisitor(jcheckConfHash); > > Any particular reason to spell out the types here? Nope, thanks for catching ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381656560 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381655725 From ehelin at openjdk.org Fri Nov 3 13:10:53 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 13:10:53 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: <7uBITKBGAv_nxirANySKwwMkx_CZTQLRxSxQHVB1e5o=.39c43992-0106-4a77-97d4-b07eebf84081@github.com> References: <7uBITKBGAv_nxirANySKwwMkx_CZTQLRxSxQHVB1e5o=.39c43992-0106-4a77-97d4-b07eebf84081@github.com> Message-ID: On Fri, 27 Oct 2023 17:47:14 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1274: >> >>> 1272: pr.repository().forge().currentUser(), comments, reviewMerge); >>> 1273: checkablePullRequest.executeChecks(localHash, censusInstance, visitor, additionalConfiguration, jcheckConfHash); >>> 1274: // Don't need to run the second round if confOverride is set. >> >> Strictly speaking, should we regenerate the AdditionalConfiguration for the second run where we use the merged .jcheck/conf? > > Oh, right, I overlooked it when I was implementing the second run of jcheck feature. This has been re-worked in the latest version ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381656132 From erikj at openjdk.org Fri Nov 3 14:09:48 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 3 Nov 2023 14:09:48 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 13:10:52 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. >> >> I have added that test that passes with this patch but fails without it. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: > > optimize Overall I really like this change. It makes dealing with jcheck configs a lot clearer. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1238: > 1236: var commitJCheckConf = checkablePullRequest.parseJCheckConfiguration(hash) > 1237: .orElseThrow(() -> new IllegalStateException("No .jcheck/conf present in tree for commit " + hash)); > 1238: var commitVisitor = checkablePullRequest.createVisitor(commitJCheckConf, hash); We could move the creation of these two into the if block below. Could create `messageStream = targetVisitor.messages().stream()` before the if and override it with the concatenated stream inside the block. I think it's worth trying to minimize any external calls or processes when possible to speed up WorkItem processing. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1272: > 1270: } > 1271: > 1272: var visitor = checkablePullRequest.createVisitor(targetJCheckConf, localHash); Supplying the `localHash` here seems like a dummy. It's not used for anything, because the overriding conf will be used regardless, but the current API requires a valid hash here. It took me a while and a bit of confusion before I realized this. Would it be possible to avoid that by getting rid of the unused parameter? bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 212: > 210: } > 211: > 212: Optional parseJCheckConfiguration(Hash hash) throws IOException { Every caller of this method is throwing IllegalStateException if jcheck conf isn't found. Did you consider just throwing here and not return Optional? I realize there is a bit more information in the exception message, but on the other hand, whoever reads it will have a stacktrace anyway. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 228: > 226: } > 227: > 228: void executeChecks(Hash localHash, CensusInstance censusInstance, PullRequestCheckIssueVisitor visitor, JCheckConfiguration conf) throws IOException { The parameter name `localHash` threw me off for a bit, maybe just `hash` in this context, unless I'm missing some context? ------------- PR Review: https://git.openjdk.org/skara/pull/1578#pullrequestreview-1712704346 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381694967 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381716442 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381728237 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381731872 From erikj at openjdk.org Fri Nov 3 14:19:40 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 3 Nov 2023 14:19:40 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 13:39:27 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1238: > >> 1236: var commitJCheckConf = checkablePullRequest.parseJCheckConfiguration(hash) >> 1237: .orElseThrow(() -> new IllegalStateException("No .jcheck/conf present in tree for commit " + hash)); >> 1238: var commitVisitor = checkablePullRequest.createVisitor(commitJCheckConf, hash); > > We could move the creation of these two into the if block below. Could create `messageStream = targetVisitor.messages().stream()` before the if and override it with the concatenated stream inside the block. I think it's worth trying to minimize any external calls or processes when possible to speed up WorkItem processing. Maybe we shouldn't concat the streams and instead differentiate the message between the different jcheck runs and include information about which jcheck conf was used. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1381752417 From ehelin at openjdk.org Fri Nov 3 18:18:30 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 3 Nov 2023 18:18:30 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit Message-ID: Hi all, please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. I also added a couple of new unit tests. Thanks, Erik ------------- Commit messages: - skara-2084 Changes: https://git.openjdk.org/skara/pull/1583/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1583&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2084 Stats: 445 lines in 4 files changed: 445 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1583.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1583/head:pull/1583 PR: https://git.openjdk.org/skara/pull/1583 From erikj at openjdk.org Fri Nov 3 20:43:27 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 3 Nov 2023 20:43:27 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit In-Reply-To: References: Message-ID: <8TZcsK9hwxKpH9V6iesZiIVqmCxW-mTdlPnB3r1swrM=.26dce5bf-a0ca-4879-8f0c-1bd13fac7a71@github.com> On Fri, 3 Nov 2023 18:14:07 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). > > The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. > > I also added a couple of new unit tests. > > Thanks, > Erik bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 102: > 100: localRepo.fetch(bot.repo().authenticatedUrl(), commit.hash().toString(), true); > 101: > 102: var remoteBranches = localRepo.remoteBranches(bot.repo().authenticatedUrl().toString()); I'm not sure this will contain all branches. We have had problems with repos materialized from HostedRepositoryPool, probably a bug in there (specifically in refreshSeed). Most uses fetch explicitly after to work around it, which you do here, but this usecase is different because we need every branch to be present, not just the main commit. Instead of working around it here, it would be better to fix HostedRepositoryPool before integrating this. If we could trust materialize, then the fetch after wouldn't be needed. bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 110: > 108: if (ref.isEmpty()) { > 109: throw new IllegalStateException("Cannot find hash for remote branch '" + branchName + "'"); > 110: } I think this turned out a little awkward, especially the exception that should never actually happen. Suggestion: var existingBranch = remoteBranches.stream() .filter(b -> b.name().equals(branchName)) .findAny(); if (existingBranch.isPresent()) { bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 127: > 125: log.info("Pushing branch '" + branch + "' to refer to commit: " + commit.hash().hex()); > 126: localRepo.push(commit.hash(), bot.repo().authenticatedUrl(), branch.name(), false, false); > 127: log.info(String.join(", ", localRepo.branches().stream().map(Branch::name).collect(Collectors.toList()))); This will potentially be a rather long log message. Not sure we need to list all branches in the repo. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1382168556 PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1382176611 PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1382173346 From zsong at openjdk.org Fri Nov 3 21:27:04 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 3 Nov 2023 21:27:04 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 13:10:52 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. >> >> I have added that test that passes with this patch but fails without it. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: > > optimize This patch looks pretty good, just some minor issues to address. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 225: > 223: return confOverride == null ? > 224: JCheck.parseConfiguration(localRepo, hash, additional) : > 225: JCheck.parseConfiguration(confOverride, additional); We can check whether additional is empty and if so, we just return original and don't need to parse the configuration again. jcheck/src/main/java/org/openjdk/skara/jcheck/JCheck.java line 309: > 307: null); > 308: return jcheck.checksForRange(); > 309: } After introduced this method, the previous `checksFor(ReadOnlyRepository repository, Hash hash) ` is only used in test right now, not sure whether we should remove it. ------------- PR Review: https://git.openjdk.org/skara/pull/1578#pullrequestreview-1713494322 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1382175193 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1382197725 From zsong at openjdk.org Fri Nov 3 21:27:04 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 3 Nov 2023 21:27:04 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: <2-_nQQMyqb5ElmY8K1Jmrwf5ApGadmmYPsweNjiEnZU=.02f22952-87f4-4e83-a17c-040d50c2c982@github.com> On Fri, 3 Nov 2023 14:17:25 GMT, Erik Joelsson wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1238: >> >>> 1236: var commitJCheckConf = checkablePullRequest.parseJCheckConfiguration(hash) >>> 1237: .orElseThrow(() -> new IllegalStateException("No .jcheck/conf present in tree for commit " + hash)); >>> 1238: var commitVisitor = checkablePullRequest.createVisitor(commitJCheckConf, hash); >> >> We could move the creation of these two into the if block below. Could create `messageStream = targetVisitor.messages().stream()` before the if and override it with the concatenated stream inside the block. I think it's worth trying to minimize any external calls or processes when possible to speed up WorkItem processing. > > Maybe we shouldn't concat the streams and instead differentiate the message between the different jcheck runs and include information about which jcheck conf was used. I agree with Erik here, it's better to include the jcheck conf information ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1382204131 From ehelin at openjdk.org Mon Nov 6 14:27:30 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Mon, 6 Nov 2023 14:27:30 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). > > The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. > > I also added a couple of new unit tests. > > Thanks, > Erik Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: Reviewer feedback ------------- Changes: - all: https://git.openjdk.org/skara/pull/1583/files - new: https://git.openjdk.org/skara/pull/1583/files/ef36a798..d32d69ba Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1583&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1583&range=00-01 Stats: 15 lines in 1 file changed: 6 ins; 3 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1583.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1583/head:pull/1583 PR: https://git.openjdk.org/skara/pull/1583 From ehelin at openjdk.org Mon Nov 6 14:27:30 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Mon, 6 Nov 2023 14:27:30 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v2] In-Reply-To: <8TZcsK9hwxKpH9V6iesZiIVqmCxW-mTdlPnB3r1swrM=.26dce5bf-a0ca-4879-8f0c-1bd13fac7a71@github.com> References: <8TZcsK9hwxKpH9V6iesZiIVqmCxW-mTdlPnB3r1swrM=.26dce5bf-a0ca-4879-8f0c-1bd13fac7a71@github.com> Message-ID: On Fri, 3 Nov 2023 20:37:46 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer feedback > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 110: > >> 108: if (ref.isEmpty()) { >> 109: throw new IllegalStateException("Cannot find hash for remote branch '" + branchName + "'"); >> 110: } > > I think this turned out a little awkward, especially the exception that should never actually happen. > Suggestion: > > var existingBranch = remoteBranches.stream() > .filter(b -> b.name().equals(branchName)) > .findAny(); > if (existingBranch.isPresent()) { Sure, I rewrote it a bit in the latest version. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 127: > >> 125: log.info("Pushing branch '" + branch + "' to refer to commit: " + commit.hash().hex()); >> 126: localRepo.push(commit.hash(), bot.repo().authenticatedUrl(), branch.name(), false, false); >> 127: log.info(String.join(", ", localRepo.branches().stream().map(Branch::name).collect(Collectors.toList()))); > > This will potentially be a rather long log message. Not sure we need to list all branches in the repo. Yeah, sorry, this was a left-over debug message. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1383418653 PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1383417871 From ehelin at openjdk.org Mon Nov 6 14:28:01 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Mon, 6 Nov 2023 14:28:01 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v2] In-Reply-To: <8TZcsK9hwxKpH9V6iesZiIVqmCxW-mTdlPnB3r1swrM=.26dce5bf-a0ca-4879-8f0c-1bd13fac7a71@github.com> References: <8TZcsK9hwxKpH9V6iesZiIVqmCxW-mTdlPnB3r1swrM=.26dce5bf-a0ca-4879-8f0c-1bd13fac7a71@github.com> Message-ID: On Fri, 3 Nov 2023 20:27:03 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Reviewer feedback > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 102: > >> 100: localRepo.fetch(bot.repo().authenticatedUrl(), commit.hash().toString(), true); >> 101: >> 102: var remoteBranches = localRepo.remoteBranches(bot.repo().authenticatedUrl().toString()); > > I'm not sure this will contain all branches. We have had problems with repos materialized from HostedRepositoryPool, probably a bug in there (specifically in refreshSeed). Most uses fetch explicitly after to work around it, which you do here, but this usecase is different because we need every branch to be present, not just the main commit. > > Instead of working around it here, it would be better to fix HostedRepositoryPool before integrating this. > > If we could trust materialize, then the fetch after wouldn't be needed. We actually don't need the `fetch` (we are about to push a new ref), I just left it there to "follow the pattern". I agree that we should fix the problem `HostedRepositoryPool`, but I would prefer to integrate this first, just to get if off my plate (there is no reason to hold this PR hostage over that bug ?). I opted to use `HostedRepository::branches` in the latest version which hopefully will make the code a bit clearer. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1383422892 From erikj at openjdk.org Mon Nov 6 14:47:59 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 6 Nov 2023 14:47:59 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v2] In-Reply-To: References: Message-ID: On Mon, 6 Nov 2023 14:27:30 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). >> >> The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. >> >> I also added a couple of new unit tests. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Marked as reviewed by erikj (Lead). bots/pr/src/main/java/org/openjdk/skara/bots/pr/BranchCommand.java line 123: > 121: var jcheckConf = JCheckConfiguration.from(localRepo, commit.hash()); > 122: var branchPattern = jcheckConf.isPresent() ? jcheckConf.get().repository().branches() : null; > 123: if (branchPattern != null && !branchName.matches(branchPattern)) { Can keep this functional and null free if you want: Suggestion: var branchPattern = jcheckConf.map(c -> c.repository().branches()); if (branchPattern.isPresent() && !branchName.matches(branchPattern.get())) { ------------- PR Review: https://git.openjdk.org/skara/pull/1583#pullrequestreview-1715381190 PR Review Comment: https://git.openjdk.org/skara/pull/1583#discussion_r1383451204 From zsong at openjdk.org Tue Nov 7 00:04:02 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 7 Nov 2023 00:04:02 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v2] In-Reply-To: References: Message-ID: <2TfY0cuCWlQSvDgsCEoR5-GLjLaJbkN0rjaWHzoHq7A=.c60ae80f-ab5e-42ed-8dce-045a76a18c97@github.com> On Mon, 6 Nov 2023 14:27:30 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). >> >> The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. >> >> I also added a couple of new unit tests. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: > > Reviewer feedback Marked as reviewed by zsong (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1583#pullrequestreview-1716540354 From ihse at openjdk.org Wed Nov 8 17:40:35 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 8 Nov 2023 17:40:35 GMT Subject: RFR: 2101: Change confusing requirement text Message-ID: <_9TiK5X6jvRi72rOXir9voOHGXx8wpSRUcis4Z76jpM=.1405bc8b-c635-4164-a97b-0a32ebe89036@github.com> The checkbox list in "Progress" in the PRs body says: "Commit message must refer to an issue" but it is not really talking about the commit message, but the PR title. The "refer to an issue" is also vague; especially since the only time you will be hit by this problem is when you are a newcomer, and do not understand what is expected of you. The text should be rephrased to be more helpful to newcomers. ------------- Commit messages: - 2101: Change confusing requirement text Changes: https://git.openjdk.org/skara/pull/1584/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1584&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2101 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1584.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1584/head:pull/1584 PR: https://git.openjdk.org/skara/pull/1584 From zsong at openjdk.org Wed Nov 8 22:49:05 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 8 Nov 2023 22:49:05 GMT Subject: RFR: 2101: Change confusing requirement text In-Reply-To: <_9TiK5X6jvRi72rOXir9voOHGXx8wpSRUcis4Z76jpM=.1405bc8b-c635-4164-a97b-0a32ebe89036@github.com> References: <_9TiK5X6jvRi72rOXir9voOHGXx8wpSRUcis4Z76jpM=.1405bc8b-c635-4164-a97b-0a32ebe89036@github.com> Message-ID: On Wed, 8 Nov 2023 17:36:17 GMT, Magnus Ihse Bursie wrote: > The checkbox list in "Progress" in the PRs body says: > > "Commit message must refer to an issue" > > but it is not really talking about the commit message, but the PR title. The "refer to an issue" is also vague; especially since the only time you will be hit by this problem is when you are a newcomer, and do not understand what is expected of you. > > The text should be rephrased to be more helpful to newcomers. Looks good to me, but it's better to get approval from Erik. ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1584#pullrequestreview-1721404011 From zsong at openjdk.org Wed Nov 8 23:23:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 8 Nov 2023 23:23:41 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR Message-ID: This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. ------------- Commit messages: - fix an issue - add test - SKARA-2089 Changes: https://git.openjdk.org/skara/pull/1585/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2089 Stats: 79 lines in 3 files changed: 76 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1585.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1585/head:pull/1585 PR: https://git.openjdk.org/skara/pull/1585 From kcr at openjdk.org Wed Nov 8 23:36:04 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 8 Nov 2023 23:36:04 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 22:46:19 GMT, Zhao Song wrote: > This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. There are valid cases where this could occur, so it might generate a bit of noise. I have a few questions: * Does this correctly handle a fix version of "tbd", or "NN-pool" or come other "pseudo" version? Those should be considered matching. * When you say ".jcheck/conf" version, what about repos that are configured to use a fix version from the Skara configuration? I think the main case you want to handle are in repos (e.g., mainline jdk) where the `.jcheck/conf` version is used, and has a value of NN and the JBS mainline fix version has a concrete value of "MM". Anything else seems likely to generate more noise than be hepful. ------------- PR Comment: https://git.openjdk.org/skara/pull/1585#issuecomment-1802900310 From erikj at openjdk.org Thu Nov 9 00:41:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 00:41:06 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 23:33:50 GMT, Kevin Rushforth wrote: > I have a few questions: > > * Does this correctly handle a fix version of "tbd", or "NN-pool" or come other "pseudo" version? Those should be considered matching. Yes, it's calling the same logic as the Notifier uses to find an existing backport record. If it finds a match, no warning is printed. If the main bug is not open, no warning is printed. I think this is doing what we want. > * When you say ".jcheck/conf" version, what about repos that are configured to use a fix version from the Skara configuration? The Skara configuration for fixVersion is only present in the notifier bot, so the PR bot doesn't know (unless we add this configuration option, which would be awkward to maintain for the admin). The logic here will only try to look for a mismatch if the fixVersion can be found through .jcheck/conf. This means that if a repo has a .jcheck/conf with a version defined, and we configure the Notifier with a different fixVersion, then this warning will be printed when it shouldn't be. We need some kind of configuration to prevent this. Another boolean flag in the configuration for PR bot. ------------- PR Comment: https://git.openjdk.org/skara/pull/1585#issuecomment-1802978896 From erikj at openjdk.org Thu Nov 9 00:19:27 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 00:19:27 GMT Subject: RFR: 2101: Change confusing requirement text In-Reply-To: <_9TiK5X6jvRi72rOXir9voOHGXx8wpSRUcis4Z76jpM=.1405bc8b-c635-4164-a97b-0a32ebe89036@github.com> References: <_9TiK5X6jvRi72rOXir9voOHGXx8wpSRUcis4Z76jpM=.1405bc8b-c635-4164-a97b-0a32ebe89036@github.com> Message-ID: On Wed, 8 Nov 2023 17:36:17 GMT, Magnus Ihse Bursie wrote: > The checkbox list in "Progress" in the PRs body says: > > "Commit message must refer to an issue" > > but it is not really talking about the commit message, but the PR title. The "refer to an issue" is also vague; especially since the only time you will be hit by this problem is when you are a newcomer, and do not understand what is expected of you. > > The text should be rephrased to be more helpful to newcomers. If you run the command line jcheck and get this warning, the new message will look very confusing. The problem here is that we are running jcheck, which is it's own thing as part of validating a PR and posting the jcheck errors directly in the PR body. Even if running jcheck in a PR is more common than running the cmdline, I don't think just changing the message like this is a good idea. ------------- PR Comment: https://git.openjdk.org/skara/pull/1584#issuecomment-1802964679 From zsong at openjdk.org Thu Nov 9 18:21:21 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 18:21:21 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v2] In-Reply-To: References: Message-ID: > This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: add fixVersionOverride option ------------- Changes: - all: https://git.openjdk.org/skara/pull/1585/files - new: https://git.openjdk.org/skara/pull/1585/files/f4285ec3..9a61116e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=00-01 Stats: 66 lines in 5 files changed: 60 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1585.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1585/head:pull/1585 PR: https://git.openjdk.org/skara/pull/1585 From erikj at openjdk.org Thu Nov 9 19:39:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 19:39:51 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v2] In-Reply-To: References: Message-ID: <6Napf9DdfCyRqGgeryhdkYvMVCjzH3GrzrPSb6i-xhU=.b164711a-5bf4-48b0-9e66-a0b3b2d0e2e6@github.com> On Thu, 9 Nov 2023 18:21:21 GMT, Zhao Song wrote: >> This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > add fixVersionOverride option bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 247: > 245: } > 246: > 247: if (repo.value().contains("fixVersionOverride")) { I think the config option should reflect that we are turning off this warning specifically, rather than that we have configured a different fixVersion in the notifier. There are more situations where this warning doesn't apply (see bug comments). How about `versionMismatchWarning` and I think we should even default it to `false` and selectively add it to the repos we want it on. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1585#discussion_r1388501264 From zsong at openjdk.org Thu Nov 9 20:31:17 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 20:31:17 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v2] In-Reply-To: <6Napf9DdfCyRqGgeryhdkYvMVCjzH3GrzrPSb6i-xhU=.b164711a-5bf4-48b0-9e66-a0b3b2d0e2e6@github.com> References: <6Napf9DdfCyRqGgeryhdkYvMVCjzH3GrzrPSb6i-xhU=.b164711a-5bf4-48b0-9e66-a0b3b2d0e2e6@github.com> Message-ID: On Thu, 9 Nov 2023 19:37:35 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> add fixVersionOverride option > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 247: > >> 245: } >> 246: >> 247: if (repo.value().contains("fixVersionOverride")) { > > I think the config option should reflect that we are turning off this warning specifically, rather than that we have configured a different fixVersion in the notifier. There are more situations where this warning doesn't apply (see bug comments). > > How about `versionMismatchWarning` and I think we should even default it to `false` and selectively add it to the repos we want it on. Sure, thanks ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1585#discussion_r1388549138 From zsong at openjdk.org Thu Nov 9 20:46:31 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 20:46:31 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v3] In-Reply-To: References: Message-ID: > This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: rename fixVersionOverride to versionMismatchWarning ------------- Changes: - all: https://git.openjdk.org/skara/pull/1585/files - new: https://git.openjdk.org/skara/pull/1585/files/9a61116e..4cdc4b2e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=01-02 Stats: 15 lines in 5 files changed: 1 ins; 1 del; 13 mod Patch: https://git.openjdk.org/skara/pull/1585.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1585/head:pull/1585 PR: https://git.openjdk.org/skara/pull/1585 From erikj at openjdk.org Thu Nov 9 22:51:53 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 22:51:53 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v3] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 20:46:31 GMT, Zhao Song wrote: >> This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > rename fixVersionOverride to versionMismatchWarning bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 247: > 245: } > 246: > 247: if (repo.value().contains("versionMismatchWarning")) { Can you add this to the factory tests? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1585#discussion_r1388668604 From zsong at openjdk.org Thu Nov 9 22:56:44 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 22:56:44 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v4] In-Reply-To: References: Message-ID: > This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update factory test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1585/files - new: https://git.openjdk.org/skara/pull/1585/files/4cdc4b2e..f9b6b165 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1585&range=02-03 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1585.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1585/head:pull/1585 PR: https://git.openjdk.org/skara/pull/1585 From zsong at openjdk.org Thu Nov 9 22:56:44 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 22:56:44 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v3] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 22:49:40 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> rename fixVersionOverride to versionMismatchWarning > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestBotFactory.java line 247: > >> 245: } >> 246: >> 247: if (repo.value().contains("versionMismatchWarning")) { > > Can you add this to the factory tests? Sure ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1585#discussion_r1388673151 From erikj at openjdk.org Thu Nov 9 23:00:24 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 9 Nov 2023 23:00:24 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v4] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 22:56:44 GMT, Zhao Song wrote: >> This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update factory test Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1585#pullrequestreview-1723647688 From zsong at openjdk.org Thu Nov 9 23:27:50 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 23:27:50 GMT Subject: RFR: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR [v4] In-Reply-To: References: Message-ID: On Thu, 9 Nov 2023 22:56:44 GMT, Zhao Song wrote: >> This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update factory test Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1585#issuecomment-1804836978 From zsong at openjdk.org Thu Nov 9 23:27:51 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 9 Nov 2023 23:27:51 GMT Subject: Integrated: 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR In-Reply-To: References: Message-ID: On Wed, 8 Nov 2023 22:46:19 GMT, Zhao Song wrote: > This patch tries to alert the user when the fixVersion in the issue differs from the fixVersion in .jcheck/conf, thereby preventing the creation of unwanted backports. This pull request has now been integrated. Changeset: 9d060f4a Author: Zhao Song URL: https://git.openjdk.org/skara/commit/9d060f4aa955dce796c35d7f8e68077e82b148fa Stats: 148 lines in 7 files changed: 141 ins; 0 del; 7 mod 2089: Warn when bug fixVersion doesn't match .jcheck/conf version in PR Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1585 From ehelin at openjdk.org Fri Nov 10 08:43:27 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 10 Nov 2023 08:43:27 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v3] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). > > The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. > > I also added a couple of new unit tests. > > Thanks, > Erik Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: Use null free Optional pattern Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1583/files - new: https://git.openjdk.org/skara/pull/1583/files/d32d69ba..44d9b3cb Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1583&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1583&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1583.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1583/head:pull/1583 PR: https://git.openjdk.org/skara/pull/1583 From erikj at openjdk.org Mon Nov 13 13:45:34 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 13 Nov 2023 13:45:34 GMT Subject: RFR: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit [v3] In-Reply-To: References: Message-ID: On Fri, 10 Nov 2023 08:43:27 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). >> >> The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. >> >> I also added a couple of new unit tests. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: > > Use null free Optional pattern > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1583#pullrequestreview-1727346227 From zsong at openjdk.org Wed Nov 15 19:31:57 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 15 Nov 2023 19:31:57 GMT Subject: RFR: 2016: CSRIssueBot shouldn't force CheckWorkItem to run Message-ID: Currently, all the CheckWorkItems triggered by CSRIssueBot are having some privilege, these checkWorkItems could bypass the checksum check and force the update of the PR. Even when a user add a comment to the CSR issue, it will force the bot re-evaluate the associated PR. This is bad and we don't have choice when implementing this. Now we have introduced issuePRMap in SKARA-1912, so we could fix the above issue. When creating the checkWorkItem in the CSRIssueWorkItem, we could look in the IssuePRmap. If the CSR issue is not associated with the pr, then we should force the update, otherwise we don't need to force the update. ------------- Commit messages: - SKARA-2016 Changes: https://git.openjdk.org/skara/pull/1586/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1586&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2016 Stats: 8 lines in 3 files changed: 4 ins; 1 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1586.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1586/head:pull/1586 PR: https://git.openjdk.org/skara/pull/1586 From erikj at openjdk.org Wed Nov 15 23:40:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 15 Nov 2023 23:40:18 GMT Subject: RFR: 2016: CSRIssueBot shouldn't force CheckWorkItem to run In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 18:36:50 GMT, Zhao Song wrote: > Currently, all the CheckWorkItems triggered by CSRIssueBot are having some privilege, these checkWorkItems could bypass the checksum check and force the update of the PR. Even when a user add a comment to the CSR issue, it will force the bot re-evaluate the associated PR. This is bad and we don't have choice when implementing this. > > Now we have introduced issuePRMap in SKARA-1912, so we could fix the above issue. When creating the checkWorkItem in the CSRIssueWorkItem, we could look in the IssuePRmap. If the CSR issue is not associated with the pr, then we should force the update, otherwise we don't need to force the update. Looks good! ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1586#pullrequestreview-1733225382 From zsong at openjdk.org Fri Nov 17 16:46:02 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 17 Nov 2023 16:46:02 GMT Subject: RFR: 2016: CSRIssueBot shouldn't force CheckWorkItem to run In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 18:36:50 GMT, Zhao Song wrote: > Currently, all the CheckWorkItems triggered by CSRIssueBot are having some privilege, these checkWorkItems could bypass the checksum check and force the update of the PR. Even when a user add a comment to the CSR issue, it will force the bot re-evaluate the associated PR. This is bad and we don't have choice when implementing this. > > Now we have introduced issuePRMap in SKARA-1912, so we could fix the above issue. When creating the checkWorkItem in the CSRIssueWorkItem, we could look in the IssuePRmap. If the CSR issue is not associated with the pr, then we should force the update, otherwise we don't need to force the update. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1586#issuecomment-1816748008 From zsong at openjdk.org Fri Nov 17 16:46:02 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 17 Nov 2023 16:46:02 GMT Subject: Integrated: 2016: CSRIssueBot shouldn't force CheckWorkItem to run In-Reply-To: References: Message-ID: On Wed, 15 Nov 2023 18:36:50 GMT, Zhao Song wrote: > Currently, all the CheckWorkItems triggered by CSRIssueBot are having some privilege, these checkWorkItems could bypass the checksum check and force the update of the PR. Even when a user add a comment to the CSR issue, it will force the bot re-evaluate the associated PR. This is bad and we don't have choice when implementing this. > > Now we have introduced issuePRMap in SKARA-1912, so we could fix the above issue. When creating the checkWorkItem in the CSRIssueWorkItem, we could look in the IssuePRmap. If the CSR issue is not associated with the pr, then we should force the update, otherwise we don't need to force the update. This pull request has now been integrated. Changeset: 42b9ee29 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/42b9ee295cdf5002972abd5990436ff148d2a4ff Stats: 8 lines in 3 files changed: 4 ins; 1 del; 3 mod 2016: CSRIssueBot shouldn't force CheckWorkItem to run Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1586 From erikj at openjdk.org Fri Nov 17 22:30:40 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 17 Nov 2023 22:30:40 GMT Subject: RFR: 2106: GitHub secondary rate limit causing delays for /backport command Message-ID: We are hitting weird "secondary rate limit" problems when fetching branches for the fork repository in the BackportCommand. To try to alleviate this problem, I'm replacing that call to just fetch the single branch we actually want to find (instead of iterating through all to find it). This may not look like a big change, but the number of branches in some fork repos is now forcing 5+ pagination calls, so this single call should reduce the volume significantly. It's still unclear exactly why this particular call is triggering the rate limiter. The actual problem happens around line 262, but I figured I could apply the same thing on line 187 as well. ------------- Commit messages: - SKARA-2106 Changes: https://git.openjdk.org/skara/pull/1587/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1587&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2106 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1587.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1587/head:pull/1587 PR: https://git.openjdk.org/skara/pull/1587 From zsong at openjdk.org Fri Nov 17 22:53:32 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 17 Nov 2023 22:53:32 GMT Subject: RFR: 2106: GitHub secondary rate limit causing delays for /backport command In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 22:27:25 GMT, Erik Joelsson wrote: > We are hitting weird "secondary rate limit" problems when fetching branches for the fork repository in the BackportCommand. To try to alleviate this problem, I'm replacing that call to just fetch the single branch we actually want to find (instead of iterating through all to find it). This may not look like a big change, but the number of branches in some fork repos is now forcing 5+ pagination calls, so this single call should reduce the volume significantly. It's still unclear exactly why this particular call is triggering the rate limiter. > > The actual problem happens around line 262, but I figured I could apply the same thing on line 187 as well. Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1587#pullrequestreview-1738060882 From erikj at openjdk.org Mon Nov 20 13:37:45 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 20 Nov 2023 13:37:45 GMT Subject: Integrated: 2106: GitHub secondary rate limit causing delays for /backport command In-Reply-To: References: Message-ID: On Fri, 17 Nov 2023 22:27:25 GMT, Erik Joelsson wrote: > We are hitting weird "secondary rate limit" problems when fetching branches for the fork repository in the BackportCommand. To try to alleviate this problem, I'm replacing that call to just fetch the single branch we actually want to find (instead of iterating through all to find it). This may not look like a big change, but the number of branches in some fork repos is now forcing 5+ pagination calls, so this single call should reduce the volume significantly. It's still unclear exactly why this particular call is triggering the rate limiter. > > The actual problem happens around line 262, but I figured I could apply the same thing on line 187 as well. This pull request has now been integrated. Changeset: cd68a797 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/cd68a797a514a8d2118e65198de134fb72ad17d6 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 2106: GitHub secondary rate limit causing delays for /backport command Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1587 From zsong at openjdk.org Wed Nov 22 17:58:42 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 22 Nov 2023 17:58:42 GMT Subject: RFR: 2107: Change naming of branches created by /backport command Message-ID: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> Since in [JDK-8320358](https://bugs.openjdk.org/browse/JDK-8320358), the GitHub action would ignore the branches whose name start with 'jdk', we should change the naming of branches created by backport command. ------------- Commit messages: - SKARA-2107 Changes: https://git.openjdk.org/skara/pull/1588/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1588&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2107 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1588.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1588/head:pull/1588 PR: https://git.openjdk.org/skara/pull/1588 From erikj at openjdk.org Wed Nov 22 18:09:40 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 22 Nov 2023 18:09:40 GMT Subject: RFR: 2107: Change naming of branches created by /backport command In-Reply-To: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> References: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> Message-ID: On Wed, 22 Nov 2023 00:01:18 GMT, Zhao Song wrote: > Since in [JDK-8320358](https://bugs.openjdk.org/browse/JDK-8320358), the GitHub action would ignore the branches whose name start with 'jdk', we should change the naming of branches created by backport command. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1588#pullrequestreview-1745052727 From zsong at openjdk.org Wed Nov 22 19:26:28 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 22 Nov 2023 19:26:28 GMT Subject: RFR: 2107: Change naming of branches created by /backport command In-Reply-To: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> References: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> Message-ID: On Wed, 22 Nov 2023 00:01:18 GMT, Zhao Song wrote: > Since in [JDK-8320358](https://bugs.openjdk.org/browse/JDK-8320358), the GitHub action would ignore the branches whose name start with 'jdk', we should change the naming of branches created by backport command. Thanks! ------------- PR Comment: https://git.openjdk.org/skara/pull/1588#issuecomment-1823378533 From zsong at openjdk.org Wed Nov 22 19:26:28 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 22 Nov 2023 19:26:28 GMT Subject: Integrated: 2107: Change naming of branches created by /backport command In-Reply-To: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> References: <4GlyYY1pVeTpe7NLjqyB9xnzhJNnbMBl_PC7J7SuaOE=.788a142c-6f2d-4c3d-9b51-9236aa6b82e6@github.com> Message-ID: <17_baqOEHNdVCE9W3i1n4g4Cw3h0V_T-9cHk9stJhgg=.543769ca-9de9-4228-8ce5-3726649ff8b4@github.com> On Wed, 22 Nov 2023 00:01:18 GMT, Zhao Song wrote: > Since in [JDK-8320358](https://bugs.openjdk.org/browse/JDK-8320358), the GitHub action would ignore the branches whose name start with 'jdk', we should change the naming of branches created by backport command. This pull request has now been integrated. Changeset: a1fd86f9 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/a1fd86f9494c3f6aab3a7260a204c8f04f3e4fe6 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2107: Change naming of branches created by /backport command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1588 From ehelin at openjdk.org Tue Nov 28 09:39:25 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Tue, 28 Nov 2023 09:39:25 GMT Subject: Integrated: 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 18:14:07 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that adds a `/branch` commit command. The `/branch` commit command allows an integrator to create a _new_ branch in a repository by adding the comment `/branch ` on a commit's web page. The command will check that no branch with the given name exists (i.e. it won't update a branch with that name to that commit). > > The implementation is very similar to the `/tag` command, but I don't think it makes sense to try to share code between them. They are both only around 60 lines of code, so trying to share code won't give us much. > > I also added a couple of new unit tests. > > Thanks, > Erik This pull request has now been integrated. Changeset: 4351119e Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/4351119e13911262bae8790c980a2571e4ee59aa Stats: 448 lines in 4 files changed: 448 ins; 0 del; 0 mod 2084: Add a `/branch` command similar to `/tag` to create a new branch from a commit Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1583 From ehelin at openjdk.org Tue Nov 28 13:42:34 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Tue, 28 Nov 2023 13:42:34 GMT Subject: RFR: 2109: Fix failing test BranchCommitCommandTests.nonConformingBranch Message-ID: Hi all, please review this small patch that adds a missing `.get()` in a message by the `BranchCommand`. The failing unit tests is now passing (I also removed some spurious logging from unit tests). Thanks, Erik ------------- Commit messages: - skara-2109 Changes: https://git.openjdk.org/skara/pull/1589/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1589&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2109 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1589.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1589/head:pull/1589 PR: https://git.openjdk.org/skara/pull/1589 From ehelin at openjdk.org Tue Nov 28 13:44:33 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Tue, 28 Nov 2023 13:44:33 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v4] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. > > I have added that test that passes with this patch but fails without it. > > Thanks, > Erik Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits: - Merge master - optimize - final review - refactor - whitespace - do not throw from checkStatus - Merge branch 'master' into pr-correct-jcheck-conf - Fix .jcheck/conf parsing in multiple places - 2082 ------------- Changes: https://git.openjdk.org/skara/pull/1578/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=03 Stats: 176 lines in 8 files changed: 102 ins; 7 del; 67 mod Patch: https://git.openjdk.org/skara/pull/1578.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1578/head:pull/1578 PR: https://git.openjdk.org/skara/pull/1578 From erikj at openjdk.org Tue Nov 28 13:56:00 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 28 Nov 2023 13:56:00 GMT Subject: RFR: 2109: Fix failing test BranchCommitCommandTests.nonConformingBranch In-Reply-To: References: Message-ID: <-E5HGfFM1Ma9Tyd1NS50kimSxOlYpECE1XmN9gvVQVM=.f48d9b28-8912-4bd2-9ae9-b8f08faff395@github.com> On Tue, 28 Nov 2023 13:39:00 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that adds a missing `.get()` in a message by the `BranchCommand`. The failing unit tests is now passing (I also removed some spurious logging from unit tests). > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1589#pullrequestreview-1752957600 From ehelin at openjdk.org Tue Nov 28 14:06:13 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Tue, 28 Nov 2023 14:06:13 GMT Subject: Integrated: 2109: Fix failing test BranchCommitCommandTests.nonConformingBranch In-Reply-To: References: Message-ID: On Tue, 28 Nov 2023 13:39:00 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that adds a missing `.get()` in a message by the `BranchCommand`. The failing unit tests is now passing (I also removed some spurious logging from unit tests). > > Thanks, > Erik This pull request has now been integrated. Changeset: a9727b65 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/a9727b6539558c3fd886397695f6deac30a6f2b0 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod 2109: Fix failing test BranchCommitCommandTests.nonConformingBranch Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1589 From erikj at openjdk.org Wed Nov 29 22:39:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 29 Nov 2023 22:39:32 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 Message-ID: Bumping JDK version to 21.0.1 and Gradle version to 8.4. There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. ------------- Commit messages: - new gha - Simplified unicode test - SKARA-2112 Changes: https://git.openjdk.org/skara/pull/1590/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2112 Stats: 35 lines in 4 files changed: 15 ins; 0 del; 20 mod Patch: https://git.openjdk.org/skara/pull/1590.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1590/head:pull/1590 PR: https://git.openjdk.org/skara/pull/1590 From erikj at openjdk.org Wed Nov 29 22:39:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 29 Nov 2023 22:39:32 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Triggering new GHA run as the last one hit an intermittent mercurial installation problem on mac. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832809001 From kcr at openjdk.org Wed Nov 29 22:42:48 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 29 Nov 2023 22:42:48 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. gradle 8.4 doesn't support running gradle itself on JDK 21. Do you use a separate JDK to run gradle (separate from the JDK 21 that you will use for building and testing Skara)? If not, you might be just getting lucky. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832813997 From erikj at openjdk.org Wed Nov 29 23:20:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 29 Nov 2023 23:20:31 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:40:42 GMT, Kevin Rushforth wrote: > gradle 8.4 doesn't support running gradle itself on JDK 21. Do you use a separate JDK to run gradle (separate from the JDK 21 that you will use for building and testing Skara)? If not, you might be just getting lucky. Oh, I saw that before, but didn't remember which version it was. When I looked again recently, the initial formulation fooled me: > [Java 21](https://docs.gradle.org/8.4/release-notes.html#java-21) is now supported for compiling, testing, and running such projects. But further down I see you are right: > Currently, you cannot run Gradle on Java 21 because Kotlin lacks support for JDK 21. However, support for running Gradle with Java 21 is expected in future versions. It does appear to work fine however. Our Gradle scripts aren't using Kotlin at all, it's still all Groovy. I would have expected Gradle to protest if it didn't work. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832852943 From erikj at openjdk.org Wed Nov 29 23:28:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 29 Nov 2023 23:28:22 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 23:18:26 GMT, Erik Joelsson wrote: > It does appear to work fine however. Our Gradle scripts aren't using Kotlin at all, it's still all Groovy. I would have expected Gradle to protest if it didn't work. I see others reporting that it's only a problem if you actually use Kotlin in your build scripts here: https://github.com/gradle/gradle/issues/25574 So, I think we are fine with this as long as it works. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832859238 From zsong at openjdk.org Wed Nov 29 23:36:52 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 29 Nov 2023 23:36:52 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Do we need to update README as well? ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832866690 From zsong at openjdk.org Wed Nov 29 23:47:04 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 29 Nov 2023 23:47:04 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Maybe we also need to update this line https://github.com/openjdk/skara/blob/a9727b6539558c3fd886397695f6deac30a6f2b0/build.gradle#L65 ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832875193 From erikj at openjdk.org Thu Nov 30 00:02:56 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 00:02:56 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 In-Reply-To: References: Message-ID: <0rBET4ANPDqogk8rdCxkkxWTVzm7gn-SvdAr9XcdIjc=.2a57d4f3-4e56-4f52-86ce-908a7cefc5fa@github.com> On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Good calls, will update. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1832886845 From erikj at openjdk.org Thu Nov 30 00:14:31 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 00:14:31 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v2] In-Reply-To: References: Message-ID: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Updated readme and build.gradle ------------- Changes: - all: https://git.openjdk.org/skara/pull/1590/files - new: https://git.openjdk.org/skara/pull/1590/files/67a9b615..3a0c04a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=00-01 Stats: 21 lines in 2 files changed: 4 ins; 1 del; 16 mod Patch: https://git.openjdk.org/skara/pull/1590.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1590/head:pull/1590 PR: https://git.openjdk.org/skara/pull/1590 From erikj at openjdk.org Thu Nov 30 00:17:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 00:17:32 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Spelling ------------- Changes: - all: https://git.openjdk.org/skara/pull/1590/files - new: https://git.openjdk.org/skara/pull/1590/files/3a0c04a6..b0a5be59 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1590.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1590/head:pull/1590 PR: https://git.openjdk.org/skara/pull/1590 From zsong at openjdk.org Thu Nov 30 00:33:57 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 30 Nov 2023 00:33:57 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 00:17:32 GMT, Erik Joelsson wrote: >> Bumping JDK version to 21.0.1 and Gradle version to 8.4. >> >> There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Spelling Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1590#pullrequestreview-1756442181 From alanb at openjdk.org Thu Nov 30 07:29:59 2023 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 30 Nov 2023 07:29:59 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 00:17:32 GMT, Erik Joelsson wrote: >> Bumping JDK version to 21.0.1 and Gradle version to 8.4. >> >> There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Spelling The Gradle 8.5 release notes has a section on "[Full Java 21 Support](https://docs.gradle.org/8.5/release-notes.html#full-java-21-support)". ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1833239329 From kcr at openjdk.org Thu Nov 30 13:01:06 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 30 Nov 2023 13:01:06 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 00:17:32 GMT, Erik Joelsson wrote: >> Bumping JDK version to 21.0.1 and Gradle version to 8.4. >> >> There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Spelling Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1590#pullrequestreview-1757412813 From erikj at openjdk.org Thu Nov 30 13:39:29 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 13:39:29 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 07:27:45 GMT, Alan Bateman wrote: > The Gradle 8.5 release notes has a section on "[Full Java 21 Support](https://docs.gradle.org/8.5/release-notes.html#full-java-21-support)". Wow, they released yesterday according to the page. When I checked yesterday it was still Gradle 8.4 listed as latest. I will update the patch to use 8.5 instead so we have official support. ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1833800382 From zsong at openjdk.org Thu Nov 30 16:38:49 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 30 Nov 2023 16:38:49 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v3] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 13:37:14 GMT, Erik Joelsson wrote: > > The Gradle 8.5 release notes has a section on "[Full Java 21 Support](https://docs.gradle.org/8.5/release-notes.html#full-java-21-support)". > > Wow, they released yesterday according to the page. When I checked yesterday it was still Gradle 8.4 listed as latest. I will update the patch to use 8.5 instead so we have official support. BTW, yesterday, I updated gradle in my Mac with homebrew and homebrew updated it to 8.5 ------------- PR Comment: https://git.openjdk.org/skara/pull/1590#issuecomment-1834130191 From ehelin at openjdk.org Thu Nov 30 19:34:32 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 30 Nov 2023 19:34:32 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v5] In-Reply-To: References: Message-ID: <7e0YyzqrAx3gKXiD2-KBvb9Nf77CwxEjPfV27X-3Hio=.8dbcaf5f-985b-4b6c-8119-0dd9f8dd9782@github.com> > Hi all, > > please review this patch that ensures that we pass the correct `.jcheck/conf` to [AdditionalConfiguration.java](https://github.com/openjdk/skara/blob/master/bots/pr/src/main/java/org/openjdk/skara/bots/pr/AdditionalConfiguration.java). The `.jcheck/conf` should either come from the "overriding" `.jcheck/conf` (if the PR bot is configured to use that) or the pull request's target branch. > > I have added that test that passes with this patch but fails without it. > > Thanks, > Erik Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge 'master' - Reviewer feedback - Merge master - optimize - final review - refactor - whitespace - do not throw from checkStatus - Merge branch 'master' into pr-correct-jcheck-conf - Fix .jcheck/conf parsing in multiple places - ... and 1 more: https://git.openjdk.org/skara/compare/a9727b65...f22f4878 ------------- Changes: https://git.openjdk.org/skara/pull/1578/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1578&range=04 Stats: 190 lines in 9 files changed: 110 ins; 4 del; 76 mod Patch: https://git.openjdk.org/skara/pull/1578.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1578/head:pull/1578 PR: https://git.openjdk.org/skara/pull/1578 From ehelin at openjdk.org Thu Nov 30 20:12:36 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 30 Nov 2023 20:12:36 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: On Fri, 3 Nov 2023 14:07:34 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize > > Overall I really like this change. It makes dealing with jcheck configs a lot clearer. @erikj79 and @zhaosongzs I'm finally looping back to this and _think_ I addressed all or your comments and suggestions. Please have a look at this PR again, I think it is shaping up quite niceliy. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1272: > >> 1270: } >> 1271: >> 1272: var visitor = checkablePullRequest.createVisitor(targetJCheckConf, localHash); > > Supplying the `localHash` here seems like a dummy. It's not used for anything, because the overriding conf will be used regardless, but the current API requires a valid hash here. It took me a while and a bit of confusion before I realized this. Would it be possible to avoid that by getting rid of the unused parameter? I agree, fixed in latest version > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 212: > >> 210: } >> 211: >> 212: Optional parseJCheckConfiguration(Hash hash) throws IOException { > > Every caller of this method is throwing IllegalStateException if jcheck conf isn't found. Did you consider just throwing here and not return Optional? I realize there is a bit more information in the exception message, but on the other hand, whoever reads it will have a stacktrace anyway. I changed the code to throw in the latest version, good suggestion! > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 228: > >> 226: } >> 227: >> 228: void executeChecks(Hash localHash, CensusInstance censusInstance, PullRequestCheckIssueVisitor visitor, JCheckConfiguration conf) throws IOException { > > The parameter name `localHash` threw me off for a bit, maybe just `hash` in this context, unless I'm missing some context? Sure, renamed it t to `hash` in the latest version ------------- PR Comment: https://git.openjdk.org/skara/pull/1578#issuecomment-1834473140 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1411207011 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1411207366 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1411207700 From ehelin at openjdk.org Thu Nov 30 20:12:37 2023 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 30 Nov 2023 20:12:37 GMT Subject: RFR: 2082: Use correct .jcheck/conf in AdditionalConfiguration.java [v3] In-Reply-To: References: Message-ID: <8Myom-ddti3uui5TlmH3doPhcyliwCU5itoVi4SK6X4=.dd01d641-bf73-43ba-aca4-ee766faa75c5@github.com> On Fri, 3 Nov 2023 20:35:47 GMT, Zhao Song wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckablePullRequest.java line 225: > >> 223: return confOverride == null ? >> 224: JCheck.parseConfiguration(localRepo, hash, additional) : >> 225: JCheck.parseConfiguration(confOverride, additional); > > We can check whether additional is empty and if so, we just return original and don't need to parse the configuration again. Good idea, fixed in most recent change. > jcheck/src/main/java/org/openjdk/skara/jcheck/JCheck.java line 309: > >> 307: null); >> 308: return jcheck.checksForRange(); >> 309: } > > After introduced this method, the previous `checksFor(ReadOnlyRepository repository, Hash hash) ` is only used in test right now, not sure whether we should remove it. I think I would like to keep it for the tests since those tests will be exercising slightly different code paths (especially with the most recent version) ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1411208006 PR Review Comment: https://git.openjdk.org/skara/pull/1578#discussion_r1411208655 From erikj at openjdk.org Thu Nov 30 22:32:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 22:32:52 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.4 [v4] In-Reply-To: References: Message-ID: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Bump gradle to 8.5 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1590/files - new: https://git.openjdk.org/skara/pull/1590/files/b0a5be59..a6b0242c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=02-03 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1590.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1590/head:pull/1590 PR: https://git.openjdk.org/skara/pull/1590 From erikj at openjdk.org Thu Nov 30 22:36:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 22:36:15 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.5 [v5] In-Reply-To: References: Message-ID: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Update readme ------------- Changes: - all: https://git.openjdk.org/skara/pull/1590/files - new: https://git.openjdk.org/skara/pull/1590/files/a6b0242c..276013a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1590&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1590.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1590/head:pull/1590 PR: https://git.openjdk.org/skara/pull/1590 From zsong at openjdk.org Thu Nov 30 23:05:33 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 30 Nov 2023 23:05:33 GMT Subject: RFR: 2112: Update JDK to 21 and Gradle to 8.5 [v5] In-Reply-To: References: Message-ID: On Thu, 30 Nov 2023 22:36:15 GMT, Erik Joelsson wrote: >> Bumping JDK version to 21.0.1 and Gradle version to 8.4. >> >> There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Update readme Looks good ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1590#pullrequestreview-1758639022 From erikj at openjdk.org Thu Nov 30 23:26:54 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 30 Nov 2023 23:26:54 GMT Subject: Integrated: 2112: Update JDK to 21 and Gradle to 8.5 In-Reply-To: References: Message-ID: On Wed, 29 Nov 2023 22:33:25 GMT, Erik Joelsson wrote: > Bumping JDK version to 21.0.1 and Gradle version to 8.4. > > There were two tests that needed to be updated. One was assuming iteration order on HashMap. The other was more complex as it was triggered by [JDK-8289689](https://bugs.openjdk.org/browse/JDK-8289689). My conclusion is that we can't count on unicode normalization returned from Git to match what the files in the filesystem have on mac, and so the test needs to accommodate for that. There is a longer explanation in a comment. This pull request has now been integrated. Changeset: b5752053 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/b5752053f3dd52d8f531756881345526d9d1f014 Stats: 56 lines in 6 files changed: 19 ins; 1 del; 36 mod 2112: Update JDK to 21 and Gradle to 8.5 Reviewed-by: zsong, kcr ------------- PR: https://git.openjdk.org/skara/pull/1590