From gli at openjdk.java.net Wed Dec 1 08:00:15 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 08:00:15 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. > > All the existing tests passed. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Improve the encapsulation and use the methods of the 'Optional' instead of direct null check ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1248/files - new: https://git.openjdk.java.net/skara/pull/1248/files/2f640bd7..5d7e353f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=01-02 Stats: 27 lines in 3 files changed: 11 ins; 4 del; 12 mod Patch: https://git.openjdk.java.net/skara/pull/1248.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1248/head:pull/1248 PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 08:04:38 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 08:04:38 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v2] In-Reply-To: <8OpTN3tBiODIDDN32eKNw7W7VieYJDZUJBiT0yEN7p0=.5b6906b2-67aa-4f7a-b5f1-f80277be3da0@github.com> References: <8OpTN3tBiODIDDN32eKNw7W7VieYJDZUJBiT0yEN7p0=.5b6906b2-67aa-4f7a-b5f1-f80277be3da0@github.com> Message-ID: <3Ypq1ee3zpBBcbtscqLGRLinZw1mxSt_mOj6eqmEw8Q=.94b5cf1d-c7d0-4485-a0f2-8cf394ac70c8@github.com> On Tue, 30 Nov 2021 23:18:25 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Use stream api instead of the encapsulated method. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 165: > >> 163: } >> 164: >> 165: var csr = jbsIssue.get().links().stream() > > This particular pattern now occurs twice in this file. Perhaps worth moving to a private method at least, to reduce some duplication. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 142: > >> 140: .filter(link -> link.relationship().isPresent() && "csr for".equals(link.relationship().get())) >> 141: .findAny().flatMap(Link::issue).orElse(null); >> 142: if (csr == null) { > > I just noticed this pattern being used a lot. Instead of .orElse(null), I would prefer if you let `csr` be an optional and used `csr.isPresent()` in the if statement. You will then need to use `csr.get()` to actually get the value, but this is safe as it's protected by the condition on isPresent(). If the variable in question is used a lot, you can choose resolve it with .get() into a new variable at the top of the if/else block. > > This applies to several places where the same pattern is used. Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 11:11:43 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 11:11:43 GMT Subject: RFR: 1254: Add a checkbox for CSR requirement [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds a checkbox for CSR requirement in the `Progress` and adds the corresponding test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - If the csr request is not required, it is no need to add the csr progress. And add more test cases - Merge branch 'master' into SKARA-1254-NEW - 1254: Add a checkbox for CSR requirement ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1246/files - new: https://git.openjdk.java.net/skara/pull/1246/files/80a06741..fab52124 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1246&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1246&range=00-01 Stats: 319 lines in 6 files changed: 278 ins; 14 del; 27 mod Patch: https://git.openjdk.java.net/skara/pull/1246.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1246/head:pull/1246 PR: https://git.openjdk.java.net/skara/pull/1246 From gli at openjdk.java.net Wed Dec 1 11:37:51 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 11:37:51 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: <0yXi1sLLIzWeSEP1FA5jPF_pfHB4JjNoOS-VD_E_MFM=.8783e2c8-82e7-401a-9b9c-cc1004df2a63@github.com> References: <0yXi1sLLIzWeSEP1FA5jPF_pfHB4JjNoOS-VD_E_MFM=.8783e2c8-82e7-401a-9b9c-cc1004df2a63@github.com> Message-ID: On Tue, 30 Nov 2021 22:56:56 GMT, Erik Joelsson wrote: > I agree with Kevin, I don't think we have any need for configuring different file types having different size requirements. If no one agrees with me or gives another idea these days, I will follow this idea. > It looks like you have taken the existing "binary" check and changed it to be a size check. Because when I dove into the class `PullRequestCheckIssueVisitor`, I fould that the `BinaryIssue` is never used and the check result has no effect in the PR. So I think `BinaryIssue` is not necessary and rename it to `BinaryFileTooLargeIssue`. // class PullRequestCheckIssueVisitor @Override public void visit(BinaryIssue issue) { log.fine("ignored: binary file"); // <---- miss to add the failed message to the `failedChecks`. } But now I find the `JCheckCLIVisitor` use the `BinaryIssue` which means the `BinaryIssue` is effective. So now I think the `PullRequestCheckIssueVisitor` just has a small bug that it miss to add the failed message to the `failedChecks`. And actually, the result of the `binary` check in the PR has never activated in the past. // class JCheckCLIVisitor public void visit(BinaryIssue i) { if (!ignore.contains(i.check().name())) { println(i, "adds binary file: " + i.path().toString()); hasDisplayedErrors = true; } } I will solve this small bug of the `PullRequestCheckIssueVisitor` in this patch and will keep the `BinaryIssue` instead of removing `BinaryIssue`. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 1 13:29:34 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 13:29:34 GMT Subject: RFR: 1254: Add a checkbox for CSR requirement [v2] In-Reply-To: References: Message-ID: <0odISXWdlKakdB0xdob-JykL9Fe7LA_eOXB9t0jb-Sg=.77887035-4d72-4eef-bc0f-29108c450956@github.com> On Wed, 1 Dec 2021 11:11:43 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a checkbox for CSR requirement in the `Progress` and adds the corresponding test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - If the csr request is not required, it is no need to add the csr progress. And add more test cases > - Merge branch 'master' into SKARA-1254-NEW > - 1254: Add a checkbox for CSR requirement The code was updated. Thanks for the review. And I find an intermittent issue. Filed [SKARA-1264](https://bugs.openjdk.java.net/browse/SKARA-1264). ------------- PR: https://git.openjdk.java.net/skara/pull/1246 From ihse at openjdk.java.net Wed Dec 1 13:40:55 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 1 Dec 2021 13:40:55 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v3] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 08:00:15 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. >> >> All the existing tests passed. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Improve the encapsulation and use the methods of the 'Optional' instead of direct null check bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 85: > 83: var csrOptional = jbsIssue.get().links().stream() > 84: .filter(link -> link.relationship().isPresent() && "csr for".equals(link.relationship().get())) > 85: .findAny().flatMap(Link::issue); I realize you'd be breaking abstractions by using csrLink() from CSRCommand, but maybe you can create a duplicated csrLink method here? I think it would help with readability, at least. And if we ever refactor this more, it would be a clear candidate to move to a class that is accessible from both here and CSRCommand. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From ihse at openjdk.java.net Wed Dec 1 13:46:59 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 1 Dec 2021 13:46:59 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v3] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 08:00:15 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. >> >> All the existing tests passed. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Improve the encapsulation and use the methods of the 'Optional' instead of direct null check bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 139: > 137: return Optional.empty(); > 138: } > 139: var csr = jbsIssue.get().links().stream() ... and here as well. It's really unfortunate that we have no good framework for where to place such common functionality. :-( ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From ihse at openjdk.java.net Wed Dec 1 13:54:48 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 1 Dec 2021 13:54:48 GMT Subject: RFR: 1254: Add a checkbox for CSR requirement [v2] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 11:11:43 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a checkbox for CSR requirement in the `Progress` and adds the corresponding test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - If the csr request is not required, it is no need to add the csr progress. And add more test cases > - Merge branch 'master' into SKARA-1254-NEW > - 1254: Add a checkbox for CSR requirement This looks good to me, now. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1246 From ihse at openjdk.java.net Wed Dec 1 14:06:33 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 1 Dec 2021 14:06:33 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: Message-ID: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> On Tue, 30 Nov 2021 11:42:56 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong I agree with the other reviewers that we only need a single binary limit. But be aware that actually deploying a change in the main JDK repo which enables this in jcheck is a separate discussion. I don't think we've ever had a hard limit on binary file sizes, only just that you should "try to avoid too large files". I foresee a highly opinionated debate on what size limit to use, if we should even activate it at all. Having a very conservative upper value is more likely to be accepted (let's say the currently largest file times two), and if that seems to work fine, we might try lowering the value. In a separate, but related note, I'd really like to let jcheck have some kind of "warnings", information that is not strictly blockers, but signals that you should make sure you really intend to do what you're doing. If we had that, then we could have a (generous) upper bound for binary sizes where jcheck makes it an error, and a much lower bound for which jcheck warns you that you perhaps should reconsider. jcheck/src/main/java/org/openjdk/skara/jcheck/BinaryCheck.java line 69: > 67: try { > 68: fileSize = path != null ? Files.size(path) : 0; > 69: needCheck = true; Does that mean that jcheck will block renaming an existing binary file if it is larger than the currently accepted maximum? I don't think that is the right behavior. Only adding a new file should trigger this. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Wed Dec 1 14:16:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 14:16:27 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> References: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> Message-ID: On Wed, 1 Dec 2021 14:01:54 GMT, Magnus Ihse Bursie wrote: > In a separate, but related note, I'd really like to let jcheck have some kind of "warnings", information that is not strictly blockers, but signals that you should make sure you really intend to do what you're doing. If we had that, then we could have a (generous) upper bound for binary sizes where jcheck makes it an error, and a much lower bound for which jcheck warns you that you perhaps should reconsider. Having two levels, warn and error, is a good idea. I'm not sure how well the current jcheck model fits with that, but if it does, I'm all for that. Then we would need two parameters for configuration. One to trigger warning and one to trigger error. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From magnus.ihse.bursie at oracle.com Wed Dec 1 14:19:26 2021 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 1 Dec 2021 15:19:26 +0100 Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> Message-ID: Unfortunately the current jcheck model does not support that at all. :-( So that'd mean that a general "warning" functionality needs to be developed first. Which, as I said, I'm all in favor for, but it needs to be done... /Magnus On 2021-12-01 15:16, Erik Joelsson wrote: > On Wed, 1 Dec 2021 14:01:54 GMT, Magnus Ihse Bursie wrote: > >> In a separate, but related note, I'd really like to let jcheck have some kind of "warnings", information that is not strictly blockers, but signals that you should make sure you really intend to do what you're doing. If we had that, then we could have a (generous) upper bound for binary sizes where jcheck makes it an error, and a much lower bound for which jcheck warns you that you perhaps should reconsider. > Having two levels, warn and error, is a good idea. I'm not sure how well the current jcheck model fits with that, but if it does, I'm all for that. Then we would need two parameters for configuration. One to trigger warning and one to trigger error. > > ------------- > > PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Wed Dec 1 14:20:38 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 14:20:38 GMT Subject: RFR: 1254: Add a checkbox for CSR requirement [v2] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 11:11:43 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a checkbox for CSR requirement in the `Progress` and adds the corresponding test cases. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - If the csr request is not required, it is no need to add the csr progress. And add more test cases > - Merge branch 'master' into SKARA-1254-NEW > - 1254: Add a checkbox for CSR requirement Looks good! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1246 From erikj at openjdk.java.net Wed Dec 1 14:22:38 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 14:22:38 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: <0yXi1sLLIzWeSEP1FA5jPF_pfHB4JjNoOS-VD_E_MFM=.8783e2c8-82e7-401a-9b9c-cc1004df2a63@github.com> Message-ID: On Wed, 1 Dec 2021 11:35:13 GMT, Guoxiong Li wrote: > > It looks like you have taken the existing "binary" check and changed it to be a size check. > > Because when I dove into the class `PullRequestCheckIssueVisitor`, I fould that the `BinaryIssue` is never used and the check result has no effect in the PR. So I think `BinaryIssue` is not necessary and rename it to `BinaryFileTooLargeIssue`. > > ``` > // class PullRequestCheckIssueVisitor > @Override > public void visit(BinaryIssue issue) { > log.fine("ignored: binary file"); > // <---- miss to add the failed message to the `failedChecks`. > } > ``` > > But now I find the `JCheckCLIVisitor` use the `BinaryIssue` which means the `BinaryIssue` is effective. So now I think the `PullRequestCheckIssueVisitor` just has a small bug that it miss to add the failed message to the `failedChecks`. And actually, the result of the `binary` check in the PR has never activated in the past. > > ``` > // class JCheckCLIVisitor > public void visit(BinaryIssue i) { > if (!ignore.contains(i.check().name())) { > println(i, "adds binary file: " + i.path().toString()); > hasDisplayedErrors = true; > } > } > ``` > > I will solve this small bug of the `PullRequestCheckIssueVisitor` in this patch and will keep the `BinaryIssue` instead of removing `BinaryIssue`. I found the original PR where this was added https://github.com/openjdk/skara/pull/159. It looks like they never got around to implementing handling in the PR visitor. I think it's good if you fix that. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 1 16:17:41 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 16:17:41 GMT Subject: RFR: 1254: Add a checkbox for CSR requirement [v2] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 14:18:05 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - If the csr request is not required, it is no need to add the csr progress. And add more test cases >> - Merge branch 'master' into SKARA-1254-NEW >> - 1254: Add a checkbox for CSR requirement > > Looks good! @erikj79 @magicus Thanks for the reviews. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1246 From gli at openjdk.java.net Wed Dec 1 16:39:11 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 16:39:11 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v4] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. > > All the existing tests passed. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Encapsulate the csrLink method. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1248/files - new: https://git.openjdk.java.net/skara/pull/1248/files/5d7e353f..03eb925e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=02-03 Stats: 16 lines in 2 files changed: 10 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1248.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1248/head:pull/1248 PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 16:39:14 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 16:39:14 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v3] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 13:38:25 GMT, Magnus Ihse Bursie wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve the encapsulation and use the methods of the 'Optional' instead of direct null check > > bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 85: > >> 83: var csrOptional = jbsIssue.get().links().stream() >> 84: .filter(link -> link.relationship().isPresent() && "csr for".equals(link.relationship().get())) >> 85: .findAny().flatMap(Link::issue); > > I realize you'd be breaking abstractions by using csrLink() from CSRCommand, but maybe you can create a duplicated csrLink method here? I think it would help with readability, at least. And if we ever refactor this more, it would be a clear candidate to move to a class that is accessible from both here and CSRCommand. Encapsulating such a method can be reused in the future. Fixed > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 139: > >> 137: return Optional.empty(); >> 138: } >> 139: var csr = jbsIssue.get().links().stream() > > ... and here as well. It's really unfortunate that we have no good framework for where to place such common functionality. :-( Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 17:36:02 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 17:36:02 GMT Subject: Integrated: 1254: Add a checkbox for CSR requirement In-Reply-To: References: Message-ID: On Sat, 27 Nov 2021 13:54:51 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a checkbox for CSR requirement in the `Progress` and adds the corresponding test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 08548eb7 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/08548eb733e3f37b558fee5ba6b3bd5380a9044c Stats: 83 lines in 2 files changed: 73 ins; 1 del; 9 mod 1254: Add a checkbox for CSR requirement Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1246 From erikj at openjdk.java.net Wed Dec 1 17:54:29 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 17:54:29 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v4] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 16:39:11 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. >> >> All the existing tests passed. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Encapsulate the csrLink method. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 118: > 116: if (csrOptional.isEmpty()) { > 117: // The csr link exists but the csr issue doesn't exist. > 118: // We should remind the user to remove the link firstly. I missed this in the previous patch. I don't think we can ask the user to remove a broken link in JBS. I'm pretty sure that would require admin actions. Here we should just treat it as if the link didn't exist and remove the label. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 132: > 130: || !resolution.get("name").asString().equals("Withdrawn")) { > 131: // The issue has a non-withdrawn csr issue, the bot should direct the user to withdraw the csr firstly. > 132: reply.println("the issue for this pull request, [" + jbsIssue.get().id() + "](" + jbsIssue.get().webUrl() + "), has " + I missed this in the previous patch. The language of this reply needs some work. Here is my suggestion. "The CSR requirement cannot be removed as there already is a CSR associated with the main issue of this pull request. Please withdraw the CSR [link] and then use the command '/csr unneeded' again." ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 18:05:15 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 18:05:15 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:42:56 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong > I found the original PR where this was added #159. It looks like they never got around to implementing handling in the PR visitor. I think it's good if you fix that. I find that the field `JCheck#commitChecks` doesn't have the item `BinaryCheck`. So it seems that the `BinaryCheck` never run in both PR and git-jcheck command. I wiil fix it, too. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 1 18:10:51 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 18:10:51 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> References: <9jLlr3KeKxL0ZYiBfgwsmnGEsZTEpzKzH3uCJssKR2I=.b6262923-ad51-48c1-8f97-5a8e1ba8c1a3@github.com> Message-ID: On Wed, 1 Dec 2021 14:04:05 GMT, Magnus Ihse Bursie wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > jcheck/src/main/java/org/openjdk/skara/jcheck/BinaryCheck.java line 69: > >> 67: try { >> 68: fileSize = path != null ? Files.size(path) : 0; >> 69: needCheck = true; > > Does that mean that jcheck will block renaming an existing binary file if it is larger than the currently accepted maximum? I don't think that is the right behavior. Only adding a new file should trigger this. I intended to check it. But if you think it don't need to check, I could remove it. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 1 18:41:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 18:41:28 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:42:56 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong About the errors and warnings, I re-read the related code. Currently, the warning config is not the actual warnings in the PR. The PR bot doesn't distinguish them in the method `hiddenMessages` and `messages` of the class PullRequestCheckIssueVisitor. Both the errors and the warnings will be shown at the `### Errors` part of the PR first comment body and all of them will block the integration. Is it the intent of the PR bot? > we could have a (generous) upper bound for binary sizes where jcheck makes it an error, and a much lower bound for which jcheck warns you that you perhaps should reconsider. The goal is good. But we need to handle it carefully. Because the check config has the errors and warnings config, which I mentioned above. If we add the check level, `error` and `warning`, in a concrete check, the understanding, usage and implementation seem more difficult to the user and the skara developer. Note what I mention above firstly: the current code about current errors and warnings config is not clear and is not equal to the git-jcheck before. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 1 19:01:48 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 19:01:48 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v5] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. > > All the existing tests passed. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix the situation when the csr issue not existing. Revise the reply message. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1248/files - new: https://git.openjdk.java.net/skara/pull/1248/files/03eb925e..83fa15f2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=04 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1248&range=03-04 Stats: 21 lines in 2 files changed: 0 ins; 8 del; 13 mod Patch: https://git.openjdk.java.net/skara/pull/1248.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1248/head:pull/1248 PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 19:01:50 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 19:01:50 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v4] In-Reply-To: References: Message-ID: <_eyKGZgR-06rCtq4mwycYwr8LChrLjmYeV8W4Eo_b_0=.40fd4092-1509-4870-ae6c-f1ae1874e862@github.com> On Wed, 1 Dec 2021 17:42:07 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Encapsulate the csrLink method. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 118: > >> 116: if (csrOptional.isEmpty()) { >> 117: // The csr link exists but the csr issue doesn't exist. >> 118: // We should remind the user to remove the link firstly. > > I missed this in the previous patch. > > I don't think we can ask the user to remove a broken link in JBS. I'm pretty sure that would require admin actions. Here we should just treat it as if the link didn't exist and remove the label. Fixed. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CSRCommand.java line 132: > >> 130: || !resolution.get("name").asString().equals("Withdrawn")) { >> 131: // The issue has a non-withdrawn csr issue, the bot should direct the user to withdraw the csr firstly. >> 132: reply.println("the issue for this pull request, [" + jbsIssue.get().id() + "](" + jbsIssue.get().webUrl() + "), has " + > > I missed this in the previous patch. The language of this reply needs some work. Here is my suggestion. > > "The CSR requirement cannot be removed as there already is a CSR associated with the main issue of this pull request. Please withdraw the CSR [link] and then use the command '/csr unneeded' again." Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From kcr at openjdk.java.net Wed Dec 1 19:11:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 1 Dec 2021 19:11:08 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 11:42:56 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong I think having a single value for errors is sufficient. I can see how allowing for a lower "warning" limit might be useful, but I don't recommend holding up this PR to implement it. It could be added in the future. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Wed Dec 1 19:37:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 19:37:34 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 19:08:41 GMT, Kevin Rushforth wrote: > I think having a single value for errors is sufficient. I can see how allowing for a lower "warning" limit might be useful, but I don't recommend holding up this PR to implement it. It could be added in the future. I agree with Kevin, since the current implementation isn't readily letting us do this, then skip it for now. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Wed Dec 1 20:14:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 1 Dec 2021 20:14:36 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v5] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 19:01:48 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. >> >> All the existing tests passed. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix the situation when the csr issue not existing. Revise the reply message. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Wed Dec 1 20:28:55 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 1 Dec 2021 20:28:55 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup In-Reply-To: References: <_y_PdkHzVDOHVCjo8lQDzWSBVvF9C6n-youb5N2_5Mk=.fd8262e0-f58a-473a-9da8-84aa2e7886e8@github.com> Message-ID: On Tue, 30 Nov 2021 23:03:54 GMT, Erik Joelsson wrote: >>> I'm not sure there will ever be a need to filter links with multiple different relationships. Do you know of any such case that you are planning to convert? >> >> It can be used in the method `Backports#findMainIssue`: >> >> >> // method Backports#findMainIssue >> var links = issue.linksWithRelationships(List.of("backported by", "backport of")); >> >> >> But If we use the stream api, it is not needed now. > >> > I'm not sure there will ever be a need to filter links with multiple different relationships. Do you know of any such case that you are planning to convert? >> >> It can be used in the method `Backports#findMainIssue`: >> >> ``` >> // method Backports#findMainIssue >> var links = issue.linksWithRelationships(List.of("backported by", "backport of")); >> ``` >> >> But If we use the stream api, it is not needed now. > > Ah, right good point. I forgot about the two variants for every link type in JBS. @erikj79 thanks for the review. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Thu Dec 2 06:24:24 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 06:24:24 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li 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 six additional commits since the last revision: - Polish - Use simple config. Restore BinaryIssue. Only check the newly added or copied files. - Merge branch 'master' into SKARA-1236 - Cann't assert the file size directly. - Fix NPE. - 1236: Add jcheck option to check for large binary files ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/80086a48..8c962e33 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=00-01 Stats: 258 lines in 12 files changed: 150 ins; 41 del; 67 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 06:28:08 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 06:28:08 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix copyright. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/8c962e33..3c81b06d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 06:42:26 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 06:42:26 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v4] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Enable the binary check. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/3c81b06d..ae206e35 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 06:42:27 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 06:42:27 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 06:28:08 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix copyright. I updated the code just now. The change is listed below. 1. Use the simple config `max-size`. If the `max-size` is not set or is set to zero, the binary file is not allowed, or the BinaryIssue is raised. If the `max-size` is set and is not zero, the binary file can't be larger than `max-size`, or the BinaryFileTooLargeIssue is raised. 2. Restore the BinaryIssue, which was removed mistakenly. 3. Only check the newly added or copied files. The modified or renamed binary files won't be checked. 4. Fix the bug that the binary check is not enabled. Thanks for taking the time to review. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 08:22:30 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 08:22:30 GMT Subject: RFR: 1265: New CSR link warns that issue isn't open Message-ID: Hi all, This little patch removes the unnecessary warning `Issue is not open.` which is end of the CSR link. And the test case is added. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1265: New CSR link warns that issue isn't open Changes: https://git.openjdk.java.net/skara/pull/1249/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1249&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1265 Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1249.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1249/head:pull/1249 PR: https://git.openjdk.java.net/skara/pull/1249 From lgxbslgx at gmail.com Thu Dec 2 10:54:36 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 2 Dec 2021 18:54:36 +0800 Subject: [Investigation] The design for SKARA-1096 about JEP check Message-ID: Hi all, I am going to start working on SKARA-1096 [1] about the JEP check which is like the CSR check. Firstly, I would like to discuss the concrete design with you and receive your suggestions. I propose the following draft design: *1. Add issue link types `jep of` and `jep for` in the JBS.* This is similar to the `csr of` and `csr for`. Currently, the JEP issue and its implementation issue has at least 3 relationship: (1) The implementation issue is a `relates to` link of the JEP issue. Such as JDK-8264130 [2] (2) The implementation issue is a `Sub-tasks` link of the JEP issue. Such as JDK-8276797 [3] (3) The implementation issue is a `is blocked by` link of the JEP issue. Such as JDK-8269306 [4] They should be unified when we use the skara bot to run the automatic job. Only the ongoing JEPs, which excludes the finished JEPs, need to add the `jep of` link because the bot don't check the finished JEPs. Only when a developer is working on a JEP should he/she add the link by himself/herself. So it is not hard to add this link. After this SKARA-1096 completed, we can send an email to ` jdk-dev at openjdk.java.net` to notify all the JEP developers to add such link. *2. Add `JEP` label in the corresponding Github repository.* The `JEP` label means that the JEP is being reviewed and has not targeted. If a repository or project has the `JEP` feature, we need to add the `JEP` label to its Github code repository. Currently, I only know that the JDK mainline need to add the `JEP` label. I need your help to list the projects which need the `JEP` label. *3. Add a bot in the skara to automatically check the JEP.* When the developer submit a PR in the Github, the bot will check the `jep for` link of the main issue of the PR. If the bot finds a `jep for` link which has not targeted, it would complete the following things: (1) Add the `JEP` label to the PR. (2) Add a checkbox item, such as `Change requires a JEP to be targeted`, to the `Progress` part of the PR body. Similar to SKARA-1254 [5]. Because of this, we don't need to add the JEP integration blocker. (3) Add the JEP issue link to the `Issue` part of the PR body. Similar to SKARA-286 [6] If the bot finds that the `jep for` link has been targeted, it would complete the following things: (1) Remove the `JEP` label of the PR. (2) Check the checkbox item which is in the `Progress` part of the PR body. Note: the JEP issue which is in the `Issue` part of the PR body won't be removed. If the bot doesn't find the `jep for` link, it won't do any thing. (no `JEP` label, no checkbox item, no JEP issue link) *4. Not add the command such as `/jep`.* Currently, we have the `/csr` command. Its value is less when the SKARA-1071 [7] is integrated. We have discussed about removing the `/csr` command when solving SKARA-1071 [8]. But finally, we decided to leave it, because the following reason: (1) The PR author might not realize that a CSR is needed. So the command `/csr needed` can be used by the Reviewer to indicate that a PR needs to have a CSR. (2) The `/csr unneeded` command can prevent that a PR author with the role of Committer withdraw a CSR that a Reviewer had requested and integrate the PR without satisfying that requirement. Back to the command `/jep`, I think the similar situation has not existed. (1) The JEP is firstly created to start the discussion. Then the JEP implementation issue and PR is created. So we always know that JEP implementation issue needs the JEP issue to be targeted(Approved). So the command `/jep needed`, like `/csr needed`, is not really needed. (2) The JEP developers are some senior developers who can realize the JEP is needed. (3) Only the project lead can target(approve) the JEP, so we don't need to prevent that the developers integrate the PR without targeting the JEP. So the command `jep unneeded`, like `csr unneeded`, is not needed. The current design is shown above. Any idea and suggestion are appreciated. Best Regards, -- Guoxiong [1] https://bugs.openjdk.java.net/browse/SKARA-1096 [2] https://bugs.openjdk.java.net/browse/JDK-8264130 [3] https://bugs.openjdk.java.net/browse/JDK-8276797 [4] https://bugs.openjdk.java.net/browse/JDK-8269306 [5] https://bugs.openjdk.java.net/browse/SKARA-1254 [6] https://bugs.openjdk.java.net/browse/SKARA-286 [7] https://bugs.openjdk.java.net/browse/SKARA-1071 [8] https://github.com/openjdk/skara/pull/1245 From david.holmes at oracle.com Thu Dec 2 12:45:37 2021 From: david.holmes at oracle.com (David Holmes) Date: Thu, 2 Dec 2021 22:45:37 +1000 Subject: [Investigation] The design for SKARA-1096 about JEP check In-Reply-To: References: Message-ID: <58c6b54f-91a1-3175-d052-65704975818d@oracle.com> Hi, On 2/12/2021 8:54 pm, Guoxiong Li wrote: > Hi all, > > I am going to start working on SKARA-1096 [1] about the JEP check which is > like the CSR check. > Firstly, I would like to discuss the concrete design with you and > receive your suggestions. > > I propose the following draft design: > > *1. Add issue link types `jep of` and `jep for` in the JBS.* > > This is similar to the `csr of` and `csr for`. I don't think that is a decision to be made just in skara-dev. I'm not certain where would be the best place to discuss it ... we don't have a general infrastructure mailing list to discuss JBS. I'll have to make enquiries. Cheers, David > Currently, the JEP issue and its implementation issue has at least 3 > relationship: > (1) The implementation issue is a `relates to` link of the JEP issue. Such > as JDK-8264130 [2] > (2) The implementation issue is a `Sub-tasks` link of the JEP issue. Such > as JDK-8276797 [3] > (3) The implementation issue is a `is blocked by` link of the JEP issue. > Such as JDK-8269306 [4] > They should be unified when we use the skara bot to run the automatic job. > Only the ongoing JEPs, which excludes the finished JEPs, need to add the > `jep of` link because the bot don't check the finished JEPs. > Only when a developer is working on a JEP should he/she add the link by > himself/herself. So it is not hard to add this link. > After this SKARA-1096 completed, we can send an email to ` > jdk-dev at openjdk.java.net` to notify all the JEP developers to add such link. > > *2. Add `JEP` label in the corresponding Github repository.* > > The `JEP` label means that the JEP is being reviewed and has not targeted. > If a repository or project has the `JEP` feature, we need to add the `JEP` > label to its Github code repository. > Currently, I only know that the JDK mainline need to add the `JEP` label. > I need your help to list the projects which need the `JEP` label. > > *3. Add a bot in the skara to automatically check the JEP.* > > When the developer submit a PR in the Github, the bot will check the `jep > for` link of the main issue of the PR. > > If the bot finds a `jep for` link which has not targeted, it would complete > the following things: > (1) Add the `JEP` label to the PR. > (2) Add a checkbox item, such as `Change requires a JEP to be targeted`, to > the `Progress` part of the PR body. Similar to SKARA-1254 [5]. Because of > this, we don't need to add the JEP integration blocker. > (3) Add the JEP issue link to the `Issue` part of the PR body. Similar to > SKARA-286 [6] > > If the bot finds that the `jep for` link has been targeted, it would > complete the following things: > (1) Remove the `JEP` label of the PR. > (2) Check the checkbox item which is in the `Progress` part of the PR body. > Note: the JEP issue which is in the `Issue` part of the PR body won't be > removed. > > If the bot doesn't find the `jep for` link, it won't do any thing. (no > `JEP` label, no checkbox item, no JEP issue link) > > *4. Not add the command such as `/jep`.* > > Currently, we have the `/csr` command. Its value is less when the > SKARA-1071 [7] is integrated. > We have discussed about removing the `/csr` command when solving SKARA-1071 > [8]. > But finally, we decided to leave it, because the following reason: > (1) The PR author might not realize that a CSR is needed. So the command > `/csr needed` can be used by the Reviewer to indicate that a PR needs to > have a CSR. > (2) The `/csr unneeded` command can prevent that a PR author with the role > of Committer withdraw a CSR that a Reviewer had requested and integrate the > PR without satisfying that requirement. > > Back to the command `/jep`, I think the similar situation has not existed. > (1) The JEP is firstly created to start the discussion. Then the JEP > implementation issue and PR is created. So we always know that JEP > implementation issue needs the JEP issue to be targeted(Approved). So the > command `/jep needed`, like `/csr needed`, is not really needed. > (2) The JEP developers are some senior developers who can realize the JEP > is needed. > (3) Only the project lead can target(approve) the JEP, so we don't need to > prevent that the developers integrate the PR without targeting the JEP. So > the command `jep unneeded`, like `csr unneeded`, is not needed. > > The current design is shown above. > Any idea and suggestion are appreciated. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1096 > [2] https://bugs.openjdk.java.net/browse/JDK-8264130 > [3] https://bugs.openjdk.java.net/browse/JDK-8276797 > [4] https://bugs.openjdk.java.net/browse/JDK-8269306 > [5] https://bugs.openjdk.java.net/browse/SKARA-1254 > [6] https://bugs.openjdk.java.net/browse/SKARA-286 > [7] https://bugs.openjdk.java.net/browse/SKARA-1071 > [8] https://github.com/openjdk/skara/pull/1245 > From kcr at openjdk.java.net Thu Dec 2 13:27:00 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 2 Dec 2021 13:27:00 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 06:39:51 GMT, Guoxiong Li wrote: > Only check the newly added or copied files. The modified or renamed binary files won't be checked. A modified file is just as much of a problem, and much more likely to occur, as adding a new file. I strongly recommend checking all files, including modified or renamed files. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Thu Dec 2 14:13:14 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Dec 2021 14:13:14 GMT Subject: RFR: 1265: New CSR link warns that issue isn't open In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 08:18:53 GMT, Guoxiong Li wrote: > Hi all, > > This little patch removes the unnecessary warning `Issue is not open.` which is end of the CSR link. And the test case is added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1249 From erikj at openjdk.java.net Thu Dec 2 14:31:57 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Dec 2021 14:31:57 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: Message-ID: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> On Thu, 2 Dec 2021 13:24:32 GMT, Kevin Rushforth wrote: > > Only check the newly added or copied files. The modified or renamed binary files won't be checked. > > A modified file is just as much of a problem, and much more likely to occur, as adding a new file. I strongly recommend checking all files, including modified or renamed files. To expand on this a bit. My main motivation for this feature is to keep the repo clean of big binaries, as that's a bad thing in general. We also want to protect ourselves from hitting similar checks in other places, typically by downstream consumers of the JDK repo. We know of one such case today (but I wouldn't be surprised if there are more cases), and unfortunately, that check isn't smart enough to tell different types of changes apart, and we aren't able to affect the implementation of that check. So for that reason, I would also ask you to revert what Magnus asked, and let this apply to any binary file, regardless of how it was changed. We may revisit this later and relax this requirement if possible in the future. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 14:33:27 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 14:33:27 GMT Subject: RFR: 1265: New CSR link warns that issue isn't open In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 14:10:38 GMT, Erik Joelsson wrote: >> Hi all, >> >> This little patch removes the unnecessary warning `Issue is not open.` which is end of the CSR link. And the test case is added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1249 From erikj at openjdk.java.net Thu Dec 2 14:35:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 2 Dec 2021 14:35:03 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v4] In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 06:42:26 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Enable the binary check. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCheckIssueVisitor.java line 273: > 271: public void visit(BinaryFileTooLargeIssue issue) { > 272: addFailureMessage(issue.check(), "The size of the binary file `" + issue.path() + "` is " + issue.fileSize() > 273: + " Bytes, which is larger than the limited file size: " Suggestion: + " Bytes, which is larger than the binary file size limit: " cli/src/main/java/org/openjdk/skara/cli/JCheckCLIVisitor.java line 303: > 301: if (!ignore.contains(i.check().name())) { > 302: println(i, "The size of the binary file `" + i.path() + "` is " + i.fileSize() > 303: + " Bytes, which is larger than the limited file size: " Suggestion: + " Bytes, which is larger than the binary file size limit: " ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Thu Dec 2 14:38:47 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 14:38:47 GMT Subject: Integrated: 1265: New CSR link warns that issue isn't open In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 08:18:53 GMT, Guoxiong Li wrote: > Hi all, > > This little patch removes the unnecessary warning `Issue is not open.` which is end of the CSR link. And the test case is added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 3d48ff8c Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3d48ff8c0c1571ee1af0548bc654a8183f5e8d4e Stats: 17 lines in 2 files changed: 16 ins; 0 del; 1 mod 1265: New CSR link warns that issue isn't open Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1249 From gli at openjdk.java.net Thu Dec 2 15:11:46 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 15:11:46 GMT Subject: RFR: 1256: Use stream api to simplify the csr issue lookup [v5] In-Reply-To: References: Message-ID: On Wed, 1 Dec 2021 19:01:48 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. >> >> All the existing tests passed. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix the situation when the csr issue not existing. Revise the reply message. Could I get your help to sponsor this patch? Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From erik.joelsson at oracle.com Thu Dec 2 15:21:18 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 2 Dec 2021 07:21:18 -0800 Subject: [Investigation] The design for SKARA-1096 about JEP check In-Reply-To: References: Message-ID: Hello Guoxiong, On 2021-12-02 02:54, Guoxiong Li wrote: > Hi all, > > I am going to start working on SKARA-1096 [1] about the JEP check which is > like the CSR check. > Firstly, I would like to discuss the concrete design with you and > receive your suggestions. > > I propose the following draft design: > > *1. Add issue link types `jep of` and `jep for` in the JBS.* I don't know if this suggestion is feasible, at least not in the short term. While the CSR to Bug relationship is very well defined and clear cut, JEPs come in many different shapes and sizes. Also as David says, this kind of JBS change needs a wider discussion and audience. If you still want to try to pursue such a change to JBS, then perhaps bring it up on jdk-dev. If you do, I wouldn't frame it as "this is needed for a Skara feature". A change like this to the JEP process needs to stand on its own merits, and the ability for Skara and other tools to more easily find relationships between implementation and JEP issues in JBS would be one of the benefits. Just don't expect changes to happen quickly, if at all. I have found the lack of a standard way to associate my implementation issues with the JEP annoying and confusing though, so perhaps this is possible. Back to SKARA-1096. The suggested Skara feature here was intended to work within the currently available environment. Given that, I don't think auto discovery of JEPs is feasible. The command as suggested by Jon is '/jep NNNNN'. This would associate the JEP issue with the PR, similar to how you add additional issues to a PR today with '/issue NNNNN' [1]. The difference would be that a JEP would not be resolved when the PR is integrated, it would just serve as another integration blocker until the JEP transitions to targeted state. It may also add the jep label similar to how the csr label is used today. I'm not completely sure we need a label though. We will need to track the relationship to the JEP issue anyway somewhere in the PR body or comment, similar to how issues are tracked. We also want to augment the body to link to the JEP in a way that makes it clear to users. This association isn't just about blocking integration but also to make the JEP more visible. Regarding the new label, there is no extra action needed. The bots can add any labels they want without any pre-configuration needed in Github. The '/jep' command could accept both JBS issue numbers as well as JEP numbers to make it more flexible and easier to use. If in the future, if your suggestion for JBS improvements goes through, we can add auto discovery of JEPs. /Erik [1] https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/issue > This is similar to the `csr of` and `csr for`. > Currently, the JEP issue and its implementation issue has at least 3 > relationship: > (1) The implementation issue is a `relates to` link of the JEP issue. Such > as JDK-8264130 [2] > (2) The implementation issue is a `Sub-tasks` link of the JEP issue. Such > as JDK-8276797 [3] > (3) The implementation issue is a `is blocked by` link of the JEP issue. > Such as JDK-8269306 [4] > They should be unified when we use the skara bot to run the automatic job. > Only the ongoing JEPs, which excludes the finished JEPs, need to add the > `jep of` link because the bot don't check the finished JEPs. > Only when a developer is working on a JEP should he/she add the link by > himself/herself. So it is not hard to add this link. > After this SKARA-1096 completed, we can send an email to ` > jdk-dev at openjdk.java.net` to notify all the JEP developers to add such link. > > *2. Add `JEP` label in the corresponding Github repository.* > > The `JEP` label means that the JEP is being reviewed and has not targeted. > If a repository or project has the `JEP` feature, we need to add the `JEP` > label to its Github code repository. > Currently, I only know that the JDK mainline need to add the `JEP` label. > I need your help to list the projects which need the `JEP` label. > > *3. Add a bot in the skara to automatically check the JEP.* > > When the developer submit a PR in the Github, the bot will check the `jep > for` link of the main issue of the PR. > > If the bot finds a `jep for` link which has not targeted, it would complete > the following things: > (1) Add the `JEP` label to the PR. > (2) Add a checkbox item, such as `Change requires a JEP to be targeted`, to > the `Progress` part of the PR body. Similar to SKARA-1254 [5]. Because of > this, we don't need to add the JEP integration blocker. > (3) Add the JEP issue link to the `Issue` part of the PR body. Similar to > SKARA-286 [6] > > If the bot finds that the `jep for` link has been targeted, it would > complete the following things: > (1) Remove the `JEP` label of the PR. > (2) Check the checkbox item which is in the `Progress` part of the PR body. > Note: the JEP issue which is in the `Issue` part of the PR body won't be > removed. > > If the bot doesn't find the `jep for` link, it won't do any thing. (no > `JEP` label, no checkbox item, no JEP issue link) > > *4. Not add the command such as `/jep`.* > > Currently, we have the `/csr` command. Its value is less when the > SKARA-1071 [7] is integrated. > We have discussed about removing the `/csr` command when solving SKARA-1071 > [8]. > But finally, we decided to leave it, because the following reason: > (1) The PR author might not realize that a CSR is needed. So the command > `/csr needed` can be used by the Reviewer to indicate that a PR needs to > have a CSR. > (2) The `/csr unneeded` command can prevent that a PR author with the role > of Committer withdraw a CSR that a Reviewer had requested and integrate the > PR without satisfying that requirement. > > Back to the command `/jep`, I think the similar situation has not existed. > (1) The JEP is firstly created to start the discussion. Then the JEP > implementation issue and PR is created. So we always know that JEP > implementation issue needs the JEP issue to be targeted(Approved). So the > command `/jep needed`, like `/csr needed`, is not really needed. > (2) The JEP developers are some senior developers who can realize the JEP > is needed. > (3) Only the project lead can target(approve) the JEP, so we don't need to > prevent that the developers integrate the PR without targeting the JEP. So > the command `jep unneeded`, like `csr unneeded`, is not needed. > > The current design is shown above. > Any idea and suggestion are appreciated. > > Best Regards, > -- Guoxiong > > [1] https://bugs.openjdk.java.net/browse/SKARA-1096 > [2] https://bugs.openjdk.java.net/browse/JDK-8264130 > [3] https://bugs.openjdk.java.net/browse/JDK-8276797 > [4] https://bugs.openjdk.java.net/browse/JDK-8269306 > [5] https://bugs.openjdk.java.net/browse/SKARA-1254 > [6] https://bugs.openjdk.java.net/browse/SKARA-286 > [7] https://bugs.openjdk.java.net/browse/SKARA-1071 > [8] https://github.com/openjdk/skara/pull/1245 From gli at openjdk.java.net Thu Dec 2 15:26:15 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 2 Dec 2021 15:26:15 GMT Subject: Integrated: 1256: Use stream api to simplify the csr issue lookup In-Reply-To: References: Message-ID: On Tue, 30 Nov 2021 13:26:12 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the common methods `Issue#linksWithRelationships`, `Issue#csrLink` and `Issue#csrIssue` and refactors the code to reduce the loop nested statements by using these common methods. > > All the existing tests passed. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: f44cb045 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f44cb045d19bf005ea93dd9e6c402ff2769d403c Stats: 192 lines in 4 files changed: 65 ins; 70 del; 57 mod 1256: Use stream api to simplify the csr issue lookup Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1248 From gli at openjdk.java.net Fri Dec 3 12:58:59 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 12:58:59 GMT Subject: RFR: 1258: Add review link/details to comments section Message-ID: Hi all, This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1258: Add review link/details to comments section Changes: https://git.openjdk.java.net/skara/pull/1250/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1258 Stats: 138 lines in 9 files changed: 113 ins; 6 del; 19 mod Patch: https://git.openjdk.java.net/skara/pull/1250.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1250/head:pull/1250 PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 13:16:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 13:16:28 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v5] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Fix the output message. - Check the renamed/modified binary file. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/ae206e35..b112f033 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=04 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=03-04 Stats: 20 lines in 4 files changed: 1 ins; 3 del; 16 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Fri Dec 3 13:16:30 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 13:16:30 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v4] In-Reply-To: References: Message-ID: On Thu, 2 Dec 2021 14:14:06 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Enable the binary check. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCheckIssueVisitor.java line 273: > >> 271: public void visit(BinaryFileTooLargeIssue issue) { >> 272: addFailureMessage(issue.check(), "The size of the binary file `" + issue.path() + "` is " + issue.fileSize() >> 273: + " Bytes, which is larger than the limited file size: " > > Suggestion: > > + " Bytes, which is larger than the binary file size limit: " Fixed. > cli/src/main/java/org/openjdk/skara/cli/JCheckCLIVisitor.java line 303: > >> 301: if (!ignore.contains(i.check().name())) { >> 302: println(i, "The size of the binary file `" + i.path() + "` is " + i.fileSize() >> 303: + " Bytes, which is larger than the limited file size: " > > Suggestion: > > + " Bytes, which is larger than the binary file size limit: " Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Fri Dec 3 13:20:10 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 13:20:10 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> Message-ID: On Thu, 2 Dec 2021 14:29:26 GMT, Erik Joelsson wrote: > let this apply to any binary file, Fixed. I have a small problem. Can the following code get the file size actually? The `path` seems a local relative path. try { fileSize = Files.size(path); } catch (IOException e) { log.warning("The file '" + path + "' doesn't exist."); } ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Fri Dec 3 14:21:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 14:21:11 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 12:55:03 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong If you look in JiraIssue::addWebLink, it already uses a comment instead of a link in certain cases (specifically when the link is considered confidential). This is the behavior we now wish to emulate all the time, but in addition to the weblink. IMO, we just need to change this method a bit, so that it always calls ::addWebLinkAsComment and then skips the weblink part if needsSecurity is true. I don't think we should remove comments when removing links. Issue comments are meant to represent a log of things happening to an Issue. The links section is meant to represent the current valid/relevant links. Removing the link when it's not relevant is good, but removing comments is like editing history and should only be done rare cases. In this situation, I would leave it to the user to clean up if they think it's needed. Also, if you add new API calls to various REST providers, those need thorough testing which can be hard to perform. We unfortunately do not have any automated way of testing the interaction between Skara and Github/Gitlab/Jira. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 14:47:10 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 14:47:10 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> Message-ID: On Fri, 3 Dec 2021 13:17:28 GMT, Guoxiong Li wrote: > > let this apply to any binary file, > > Fixed. > > I have a small problem. Can the following code get the file size actually? The `path` seems a local relative path. > > ``` > try { > fileSize = Files.size(path); > } catch (IOException e) { > log.warning("The file '" + path + "' doesn't exist."); > } > ``` The path you get from a patch should be local to the repository. Assuming the file is in the workspace, it should be resolvable against the repository root, but I don't think a jcheck check can make such an assumption. AFAIK it's expected to just interact with the commit data. It's never updating the workspace to each inspected commit to perform the checks. I think you need to figure out the size by inspecting the binary patch. I'm not sure exactly how, but it looks like all the binary data is encoded in the patch hunks. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erik.joelsson at oracle.com Fri Dec 3 14:51:32 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 3 Dec 2021 06:51:32 -0800 Subject: [External] : Re: Switch jdk7u development to Git/Skara In-Reply-To: References: <24feab95-a6fb-6959-c7bc-7c6de51d28a1@oracle.com> Message-ID: <1e5b909a-0d81-1c85-cfd5-535e8d8a1dd4@oracle.com> Hello Andrew, Thanks for your reply. Yes, we can certainly perform the consolidation next week. I'm proposing we start on Monday. I've filed this issue to track the work: https://bugs.openjdk.java.net/browse/SKARA-1268 /Erik On 2021-12-03 05:50, Andrew Brygin wrote: > Hello Erik, > > ?I apologize for the really delayed response. > > ?It seems to be natural to follow the jdk8u migration > ?schedule, as it is the main source of changes for jdk7u. > ?So, a coordinated migration to consolidated Mercurial > ?repositories seems to be most convenient approach. > > ?As jdk7u has (to put it mildly) a bit less active development, > ?we seems to have more freedom regarding the migration schedule. > > ?So, a two-step? migration to the consolidated Mercurial repo > ?in December, and move to the Git repo in February seems to be > ?acceptable schedule. > > ?As I can see, the consolidated prototype [1] already contains > ?all changes for the jdk7u forest, and corresponds to the jdk8u > ?consolidated repo in the common part of the history. > > ?From your perspective, is it feasible to migrate to the consolidated > ?Mercurial repository during the next week of December (12/06 - 12/12)? > > Thanks, > Andrew > > [1] http://hg.openjdk.java.net/jdk7u/consol-proto > > On 13.10.2021 00:51, erik.joelsson at oracle.com wrote: >> Hello jdk7u maintainers, >> >> I would like to raise the subject of potentially moving jdk7u >> development over to Github/Skara at some point in the future. >> Currently the only 2 projects still on hg.openjdk.java.net are jdk7u >> and jdk8u, and we are currently in the process of figuring out the >> migration path for jdk8u [1]. If the current plan holds, then in >> April 2022, jdk7u will be the only project left. I don't know how >> long jdk7u will stay active, but even if it's for a limited time, the >> move would be greatly appreciated from an infrastructure support >> point of view. >> >> The move for 7u is similar to 8u and a bit trickier than the previous >> move of 11u. We first need to consolidate the Mercurial repositories >> into one, like we did for 10. I have already produced a prototype >> conversion, both of a consolidated HG repo [2] and then also to >> Github [3]. In the jdk8u plan, we are aiming for a separate forest >> consolidation step in November, followed by a two step move to Git in >> February and April respectively. We can do the same thing for 7u, or >> we can do it all in one step. Note that the consolidation is the step >> that has the most potential for down time. I would recommend planning >> for a full week just in case something goes wrong, though expected >> time is more likely around 1-2 days. >> >> I would like to hear from the maintainers of jdk7u what your >> preferred strategy would be and what timelines would potentially work >> for you. >> >> /Erik >> >> [1] >> https://mail.openjdk.java.net/pipermail/jdk8u-dev/2021-October/014316.html >> [2] http://hg.openjdk.java.net/jdk7u/consol-proto/ >> [3] >> https://urldefense.com/v3/__https://github.com/openjdk/jdk7u__;!!ACWV5N9M2RV99hQ!b9Cv3fH8xq09ZFbQ0dV3VbNjuXsgjrLQ7rH0H9YTn2nT-ypODgssk9vCgLrmprzi_l4$ > From gli at openjdk.java.net Fri Dec 3 15:19:15 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 15:19:15 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> On Fri, 3 Dec 2021 14:18:34 GMT, Erik Joelsson wrote: > If you look in JiraIssue::addWebLink, it already uses a comment instead of a link in certain cases (specifically when the link is considered confidential). This is the behavior we now wish to emulate all the time, but in addition to the weblink. IMO, we just need to change this method a bit, so that it always calls ::addWebLinkAsComment and then skips the weblink part if needsSecurity is true. I agree to adjust the method `addWebLinkAsComment` to complete this enhancement. > I don't think we should remove comments when removing links. Issue comments are meant to represent a log of things happening to an Issue. The links section is meant to represent the current valid/relevant links. Removing the link when it's not relevant is good, but removing comments is like editing history and should only be done rare cases. In this situation, I would leave it to the user to clean up if they think it's needed. Curently, the method `removeWebLink` will remove the corresponding comment. Please see the code below. The line `request.delete("/comment/" + comment.id()).execute()` will remove the related web link comment. Because such comment is related to the weblink, I think this step is reasonable. But removing the arbitrary comment is not good. I agree that we shouldn't provide the api about removing comment. private void removeWebLink(Link link) { request.delete("/remotelink") .param("globalId", "skaralink=" + link.uri().orElseThrow().toString()) .onError(e -> e.statusCode() == 404 ? Optional.of(JSON.object().put("already_deleted", true)) : Optional.empty()) .execute(); for (var comment : comments()) { var commentLink = parseWebLinkComment(comment); if (commentLink.isEmpty()) { continue; } if (!commentLink.get().uri().equals(link.uri())) { continue; } request.delete("/comment/" + comment.id()).execute(); // <---- here, remove the comment. } } > Also, if you add new API calls to various REST providers, those need thorough testing which can be hard to perform. We unfortunately do not have any automated way of testing the interaction between Skara and Github/Gitlab/Jira. I noticed it. Hope the automated tests can be built in the future. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From ihse at openjdk.java.net Fri Dec 3 17:11:13 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 3 Dec 2021 17:11:13 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 12:55:03 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I don't like the thought of removing things from JBS. What is it you want to remove, and why? The Review link? As I argued in the bug report, I think it is useful to have and should not be removed. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 17:15:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 17:15:22 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: <2dhRdJa6WR5BwIypQ0YoHkVue-1qkVF5gsBZ0sZ7wkY=.01594465-0c19-47aa-a83f-621a2005cbd5@github.com> On Fri, 3 Dec 2021 15:16:36 GMT, Guoxiong Li wrote: > > I don't think we should remove comments when removing links. Issue comments are meant to represent a log of things happening to an Issue. The links section is meant to represent the current valid/relevant links. Removing the link when it's not relevant is good, but removing comments is like editing history and should only be done rare cases. In this situation, I would leave it to the user to clean up if they think it's needed. > > Curently, the method `removeWebLink` will remove the corresponding comment. Please see the code below. The line `request.delete("/comment/" + comment.id()).execute()` will remove the related web link comment. > > Because such comment is related to the weblink, I think this step is reasonable. But removing the arbitrary comment is not good. I agree that we shouldn't provide the api about removing comment. You are right, I missed this, and thinking more about this, I think it's the correct behavior. That also means we don't need to change anything with regards to removing links in this enhancement. > > > Also, if you add new API calls to various REST providers, those need thorough testing which can be hard to perform. We unfortunately do not have any automated way of testing the interaction between Skara and Github/Gitlab/Jira. > > I noticed it. Hope the automated tests can be built in the future. I wouldn't know where to start. I have created a couple of manual tests that interact directly with Github and Gitlab for functionality that I added. To run them you need to feed in a properties file with URLs and authentication data. See ManualForgeTests for an example. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From ihse at openjdk.java.net Fri Dec 3 17:16:07 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Fri, 3 Dec 2021 17:16:07 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v5] In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 13:16:28 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Fix the output message. > - Check the renamed/modified binary file. I just want to confirm that Erik is correct. You need to check even updated and renamed files. I also want to confirm that I don't think getting a warning level should hold up this PR. As I said, we don't currently support warnings, and the entire concept needs to be developed, for all stages, up to and including how to present them to the user in the GitHub UI, before we can start to actually emit any warnings. I still think this would be a good thing to have, though. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Fri Dec 3 17:20:17 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 17:20:17 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 17:08:44 GMT, Magnus Ihse Bursie wrote: > I don't like the thought of removing things from JBS. What is it you want to remove, and why? The Review link? As I argued in the bug report, I think it is useful to have and should not be removed. The operations here are "add an issue" to a PR (which adds a review link to the issue), and remove an issue from a PR (which removes the review link from the issue). Both of these are already supported today and as Guoxiong pointed out to me, both link and comment are already automatically removed from the issue when the user does `/issue remove`. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 17:20:17 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 17:20:17 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 15:16:36 GMT, Guoxiong Li wrote: > If you look in JiraIssue::addWebLink, it already uses a comment instead of a link in certain cases (specifically when the link is considered confidential). This is the behavior we now wish to emulate all the time, but in addition to the weblink. IMO, we just need to change this method a bit, so that it always calls ::addWebLinkAsComment and then skips the weblink part if needsSecurity is true. @erikj79 I re-read the code. If we make `addWebLinkAsComment` always be invoked, it may cause some unexpected behavior. For example, when a patch integrates, a link will be added to the issue (The code is at `IssueNotifier#onIntegratedPullRequest`). At the same time, a comment will be added to the issue (The code is at `IssueNotifier#onNewCommits`). If we enable the `addWebLinkAsComment`, two similar comments would be added to the same issue. We can remove the related code in `IssueNotifier#onNewCommits` to let the bot only add one comment. But actually, the comment message of the `IssueNotifier#onNewCommits` is more readable and precise. If we always remove the related code like `IssueNotifier#onNewCommits`, I can't find all the places to modify now and the change is more large and more difficult. So I advice that we can add a warning comment in the api `removeComment` so that the developers use this api carefully. > Also, if you add new API calls to various REST providers, those need thorough testing which can be hard to perform. We unfortunately do not have any automated way of testing the interaction between Skara and Github/Gitlab/Jira. If you agree to add the api `removeComment`, this patch needs to be reviewed carefully according to the documentation of the `Github/Gitlab/Jira`. ---- When I type this comment, I receive the your new comment just now. If something is duplicated, just ignore it. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 17:46:52 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 17:46:52 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 17:17:23 GMT, Erik Joelsson wrote: > I don't like the thought of removing things from JBS. What is it you want to remove, and why? The Review link? As I argued in the bug report, I think it is useful to have and should not be removed. I understand your meaning in the comment of [SKARA-1258](https://bugs.openjdk.java.net/browse/SKARA-1258). This patch is following your idea. The original logic is: 1. When the user types `/issue add XXXX` at a comment of the PR, the bot will add a review link to the issue `XXXX`. 2. When the user types `/issue remove XXXX` at a comment of the PR, the bot will remove the review link which is added in the step 1. This removing step is necessary because the issue `XXXX` is not related to the PR if the user typed `/issue remove XXXX`. The logic of this patch is: 1. Like the step 1 above. Add the review link and **a comment which makes the JBS can notify the watchers**. 2. Like the step 2 above. Remove the added link and **remove the added comment**. The review link is added and removed as before. And this patch only cares about the comment. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 18:12:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 18:12:18 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 17:17:35 GMT, Guoxiong Li wrote: > > If you look in JiraIssue::addWebLink, it already uses a comment instead of a link in certain cases (specifically when the link is considered confidential). This is the behavior we now wish to emulate all the time, but in addition to the weblink. IMO, we just need to change this method a bit, so that it always calls ::addWebLinkAsComment and then skips the weblink part if needsSecurity is true. > > @erikj79 I re-read the code. If we make `addWebLinkAsComment` always be invoked, it may cause some unexpected behavior. > > For example, when a patch integrates, a link will be added to the issue (The code is at `IssueNotifier#onIntegratedPullRequest`). At the same time, a comment will be added to the issue (The code is at `IssueNotifier#onNewCommits`). If we enable the `addWebLinkAsComment`, two similar comments would be added to the same issue. > > We can remove the related code in `IssueNotifier#onNewCommits` to let the bot only add one comment. But actually, the comment message of the `IssueNotifier#onNewCommits` is more readable and precise. If we always remove the related code like `IssueNotifier#onNewCommits`, I can't find all the places to modify now and the change is more large and more difficult. > I've now read through the code in question and you are partly right. First of all, internally at Oracle we are already using the code path where comments are used instead of issue links. The "needsSecurity" conditional basically means "is this Oracle confidential". You of course can't see this in action, but this makes me comfortable that it currently actually works. We did have an issue with duplicate comments being posted in the past. This was fixed in #784. I don't really like that solution, but it does the trick. Looking at actual (confidential) bugs, the onNewCommits call seems to run first, so we do get the nicer comment link. Given this, we could get away with just changing addWebLink as I suggested. However, this would have the effect that also commit links would be added as both comments and links, which the enhancement request did not ask for. That's probably not desired. > So I advice that we can add a warning comment in the api `removeComment` so that the developers use this api carefully. If we need to add Issue::removeComment, then only implement it where it's going to be used, which is in JiraIssue. For GithubPullRequest and GitlabMergeRequest, better leave it not implemented than implemented but not tested. (Here the failed abstraction of Issue and lack of a sub interface for bug system issues strikes again.) If you go down this route, I won't be able to integrate this until I have time to test it properly. Given how little time I have to spend on Skara these days, that may be a while. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From kcr at openjdk.java.net Fri Dec 3 18:21:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 18:21:30 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:09:48 GMT, Erik Joelsson wrote: > Given this, we could get away with just changing addWebLink as I suggested. However, this would have the effect that also commit links would be added as both comments and links, which the enhancement request did not ask for. That's probably not desired. Actually, I _do_ think having both the link and the comment is desired. See the comment from Magnus in the JBS issue (and my comment agreeing with him). ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 18:33:38 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 18:33:38 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:17:53 GMT, Kevin Rushforth wrote: > > Given this, we could get away with just changing addWebLink as I suggested. However, this would have the effect that also commit links would be added as both comments and links, which the enhancement request did not ask for. That's probably not desired. > > Actually, I _do_ think having both the link and the comment is desired. See the comment from Magnus in the JBS issue (and my comment agreeing with him). Sorry if I wasn't clear. We do want both link and comment for review links, but not for commit links. My suggested solution would apply to both kinds of links. The enhancement request was only for review links. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 18:40:48 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 18:40:48 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:31:05 GMT, Erik Joelsson wrote: > We do want both link and comment for review links, but not for commit links. The comment for commit links is added by `IssueNotifier#onNewCommits`. It is a existing feature. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From kcr at openjdk.java.net Fri Dec 3 18:40:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 3 Dec 2021 18:40:49 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:31:05 GMT, Erik Joelsson wrote: > Sorry if I wasn't clear. We do want both link and comment for review links, but not for commit links. My suggested solution would apply to both kinds of links. The enhancement request was only for review links. Ah, I misunderstood. You're right then. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 18:47:59 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 18:47:59 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:31:05 GMT, Erik Joelsson wrote: > Given this, we could get away with just changing addWebLink as I suggested. However, this would have the effect that also commit links would be added as both comments and links, which the enhancement request did not ask for. That's probably not desired. Do you mean that if we change the method `addWebLink` as you suggested, there will be two similar comments for commit links, which is unexpected? ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Fri Dec 3 18:59:16 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 3 Dec 2021 18:59:16 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: <4PEQrBwvjoemRp3fbkyZ8Lf_KdS0a7tU8D01bEFxUQU=.4736241c-32c5-4ee6-a858-51754e1627f7@github.com> On Fri, 3 Dec 2021 12:55:03 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I have one thing to confirm. In a confidential issue, when the patch is integrated (commit links), which comment does you see? Changeset: Author: Committer: Date: URL: or Remote link: URL: Summary: Relationship: >From the code, I guess you can see the second style. Is my guess right? ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 19:04:14 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 19:04:14 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: <5KaoTFL90U4QfucqYxTWNoIW45CAjGHbCbhgYK0-qN0=.d225fbc9-261a-4744-97f0-da9a93bfc106@github.com> Message-ID: On Fri, 3 Dec 2021 18:43:38 GMT, Guoxiong Li wrote: > > Given this, we could get away with just changing addWebLink as I suggested. However, this would have the effect that also commit links would be added as both comments and links, which the enhancement request did not ask for. That's probably not desired. > > Do you mean that if we change the method `addWebLink` as you suggested, there will be two similar comments for commit links, which is unexpected? No, I seem to have mixed things up in this paragraph, please disregard it. There will never be duplicate link comments because #784 fixed that. I think my proposed fix in `addWebLink` should do the trick. To clarify, addWebLink would do the following. 1. If needsSecurity is false, add an IssueLink (same as today) 2. If a comment with this link doesn't already exist, add a comment with the link (new behavior when needsSecurity is false, otherwise same as today) > I have one thing to confirm. In a confidential issue, when the patch is integrated (commit links), which comment does you see? You see the first one, as onNewCommit seems to be executing first. I have searched back JBS and the newest bugs with where the second style comment can be found were fixed for JDK 16, so before #784 (in these issues both comments are present). ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 3 22:07:09 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 3 Dec 2021 22:07:09 GMT Subject: RFR: 1269: Handle Jira host with path element in URL Message-ID: <-QFNy1YmK54EqqJA5hB0M2XssDfly3F81g6rFTURh30=.b4d57f6a-e50a-425b-b16a-c8f01a1b284f@github.com> The IssueTracker/JiraHost classes in Skara make the assumption that the base URL for Jira is just a hostname with no path elements. In order to use Skara with a Jira instance with a URL that has a path element, this needs to be fixed. Instead of always basing REST call URLs on the configured base path and appending to it, there are many cases where the URIBuilder::setPath is used, which overwrites any existing path element. This is especially troublesome when combined with using IssueProject::webUrl as the base for these URLs. I would like to fix this by adding a supported way of getting the base URI from an IssueTracker (IssueTracker::uri), replace all uses of ::webUrl for constructing other URLs with this new call, and replacing all ::setPath with ::appendPath (in IssueTracker/Jira related code). This change will require all configurations to be careful not to add a trailing slash to the URL for the Jira instance. I intend to run this for a while in the staging environment to make sure it works. ------------- Commit messages: - SKARA-1269 Changes: https://git.openjdk.java.net/skara/pull/1251/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1251&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1269 Stats: 25 lines in 9 files changed: 14 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/skara/pull/1251.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1251/head:pull/1251 PR: https://git.openjdk.java.net/skara/pull/1251 From gli at openjdk.java.net Sat Dec 4 07:37:33 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 4 Dec 2021 07:37:33 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 12:55:03 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong > > From the code, I guess you can see the second style. Is my guess right? > > You see the first one, as onNewCommit seems to be executing first. I have searched back JBS and the newest bugs with where the second style comment can be found were fixed for JDK 16, so before #784 (in these issues both comments are present). The `see the first one` confused me. Please see the following code analysis. The method `parseWebLinkComment` can only identify the comment lines `Remote link:` and `URL:`. private static final Pattern titlePattern = Pattern.compile("^Remote link: (.*)"); private static final Pattern urlPattern = Pattern.compile("^URL: (.*)"); private static final Pattern summaryPattern = Pattern.compile("^Summary: (.*)"); private static final Pattern relationshipPattern = Pattern.compile("^Relationship: (.*)"); private Optional parseWebLinkComment(Comment comment) { var lines = comment.body().lines().collect(Collectors.toList()); if ((lines.size() < 2 ) || (lines.size() > 4)) { return Optional.empty(); } var titleMatcher = titlePattern.matcher(lines.get(0)); // <---- Remote link: XXXX var urlMatcher = urlPattern.matcher(lines.get(1)); // <---- URL: XXXX if (!titleMatcher.matches() || !urlMatcher.matches()) { // <---- Both `Remote link:` and `URL:` should exist return Optional.empty(); // <---- if not, it will return Optional.empty() } // ignore other code... } ``` So when the #784 added the following code, the variable `alreadyPosted` just can identify the comment which has `Remote link:` and `URL:`. But it can't identify the comment created by the method `onNewCommit`, which has `Changeset: Author: Committer: Date: URL: `. private void addWebLinkAsComment(Link link) { var alreadyPosted = comments().stream() .map(this::parseWebLinkComment) .filter(Optional::isPresent) .map(Optional::get) .anyMatch(l -> l.uri().equals(link.uri()) && l.title().equals(link.title())); if (alreadyPosted) { return; } // ignore other code... } As @rwestberg mentioned in the #784: > Please review this change that avoids potentially posting the same Jira link comment multiple times. The #784 only can avoid potentially posting **the same** Jira link comment multiple times. And the method `onNewCommit` has the following code which can identify the comment created by `addWebLinkAsComment`. It only checks the url and not checks the other pattern, which is not like `parseWebLinkComment`. ``` // only check the url var alreadyPostedComment = existingComments.stream() .filter(comment -> comment.author().equals(issueProject.issueTracker().currentUser())) .anyMatch(comment -> comment.body().contains(hashUrl) || comment.body().contains(shortHashUrl)); if (!alreadyPostedComment) { issue.addComment(commitNotification); } --- >From the code, we can simulate the run result. **If the issues are public (I can see):** 1. if the `onNewCommit` runs earier than `onIntegratedPullRequest`. (1) The `onNewCommit` will create the comment as `Changeset: Author: Committer: Date: URL:`. (2) Then the `onIntegratedPullRequest` will create the issue link for the commit. It is reasonable and expected. 2. if the `onIntegratedPullRequest` runs earier than `onNewCommit`. (1) The `onIntegratedPullRequest` will create the issue link for the commit. (2) Then the `onNewCommit` will create the comment as `Changeset: Author: Committer: Date: URL:`. The result is the same as the point 1. And it is the situation I always see in the OpenJDK JBS. **If the issues are confidential (not public) (I can't see):** 1. if the `onNewCommit` runs earier than `onIntegratedPullRequest`. (1) The `onNewCommit` will create the comment as `Changeset: Author: Committer: Date: URL:`. (2) Then the `onIntegratedPullRequest` runs. Because `parseWebLinkComment` can't identify the comment `Changeset: Author: Committer: Date: URL:`, so `onIntegratedPullRequest` creates another comment `Remote link:` and `URL:` for the commit. In this situation, there are two comments added. It is unexpected. 2. if the `onIntegratedPullRequest` runs earier than `onNewCommit`. (1) The `onIntegratedPullRequest` runs. Because there is no comment now, so `onIntegratedPullRequest` creates comment `Remote link: URL:` for the commit. (2) Then the `onNewCommit` runs. It only identifies the url, which can identify the comment `Remote link: URL:`. So it won't create the comment again. In this situation, only one comment like `Remote link: URL:` is added to the issue. It is unexpected, too. Because @erikj79 said `see the first one`. ---- I think the problem is not in method `parseWebLinkComment` and `addWebLink`. I re-read the code, it seems the problem is caused by the config `commitLink`. In the public issues, the `commitLink` is `true`, so the issue link can be created by using the method `onIntegratedPullRequest`. So the analysis above about this situation is right. // method onIntegratedPullRequest if (commitLink) { // <---- Here var linkBuilder = Link.create(repository.webUrl(hash), "Commit") .summary(repository.name() + "/" + hash.abbreviate()); if (commitIcon != null) { linkBuilder.iconTitle("Commit"); linkBuilder.iconUrl(commitIcon); } issue.addLink(linkBuilder.build()); // <---- if the commitLink is false, this line never runs. } In the confidential issues, the `commitLink` is false, so the issue comment `Remote link: URL:` never be created because the `issue.addLink` never runs. And the method `onNewCommit` will always create the comment `Changeset: Author: Committer: Date: URL:`, which you can see in current confidential (oracle internal) issues. Could I get your help to read the configuration about the `commitLink` to verify my suspection? ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Sat Dec 4 15:30:24 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 4 Dec 2021 15:30:24 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> Message-ID: <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> On Fri, 3 Dec 2021 14:44:35 GMT, Erik Joelsson wrote: > I think you need to figure out the size by inspecting the binary patch. I'm not sure exactly how, but it looks like all the binary data is encoded in the patch hunks. I dive into the diff information to find the size. Only the added and deleted files have the entire size. The modified files have the delta size (modified size) which we can't use. And the renamed and copied files have no size, they only have the source path and target patch. May need help from the experts who are famaliar with Git/HG. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Sun Dec 5 18:41:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 5 Dec 2021 18:41:28 GMT Subject: RFR: 635: Add census link for credited reviewers Message-ID: Hi all, This patch uses the full name and the census link of the credited reviewer so that the `### Reviewers` part can be clearer. For example, the [PR-6562](https://github.com/openjdk/jdk/pull/6562) has a credited reviewer which is shown as `jbhateja - Committer Added manually`. After this patch, it will show: `Jatin Bhateja - Committer Added manually`. The full name `Jatin Bhateja` will replace the username `jbhateja`. If these is a census link, it will show: `[Jatin Bhateja](https://openjdk.java.net/census#jbhateja) - Committer Added manually`. And the test cases are added. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 635: Add census link for credited reviewers Changes: https://git.openjdk.java.net/skara/pull/1252/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1252&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-635 Stats: 80 lines in 2 files changed: 58 ins; 0 del; 22 mod Patch: https://git.openjdk.java.net/skara/pull/1252.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1252/head:pull/1252 PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 09:01:09 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 09:01:09 GMT Subject: RFR: 1140: Add test case for stale backport branches Message-ID: Hi all, This patch adds the test cases about fetching the target branch when using the backport command each time. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1140: Add test case for stale backport branches Changes: https://git.openjdk.java.net/skara/pull/1253/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1253&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1140 Stats: 21 lines in 1 file changed: 20 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1253.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1253/head:pull/1253 PR: https://git.openjdk.java.net/skara/pull/1253 From gli at openjdk.java.net Mon Dec 6 13:22:47 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 13:22:47 GMT Subject: Withdrawn: 1140: Add test case for stale backport branches In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 08:57:13 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the test cases about fetching the target branch when using the backport command each time. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/skara/pull/1253 From erikj at openjdk.java.net Mon Dec 6 15:30:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 15:30:22 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: <82Lhou2ZUJOuLH9cEdo-RCMLciiSKJ8RknOLKvMkfEE=.0788ce4b-d6e2-4425-99c2-5c9fd29b47fa@github.com> On Sat, 4 Dec 2021 07:34:56 GMT, Guoxiong Li wrote: > Could I get your help to read the configuration about the `commitLink` to verify my suspection? You are correct, we have `"commitLink": "false"` in the configuration for the confidential notifier. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Mon Dec 6 15:36:03 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 15:36:03 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> Message-ID: On Sat, 4 Dec 2021 15:27:48 GMT, Guoxiong Li wrote: > > I think you need to figure out the size by inspecting the binary patch. I'm not sure exactly how, but it looks like all the binary data is encoded in the patch hunks. > > I dive into the diff information to find the size. Only the added and deleted files have the entire size. The modified files have the delta size (modified size) which we can't use. And the renamed and copied files have no size, they only have the source path and target patch. > > May need help from the experts who are famaliar with Git/HG. I think size delta in the case of modified is fine. In my experience, it's very rare for binary patches to actually be partial in real situations. When replacing an image or archive, the whole file usually changes enough. If the binary patch is empty, due to file moved/rename, then we can't really do anything about that unfortunately. Have you looked at actual patch output from Git to see what it looks like for renamed binary files? Git doesn't track file renames explicitly, so I'm not sure what would actually happen here. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Mon Dec 6 15:56:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 15:56:22 GMT Subject: RFR: 635: Add census link for credited reviewers In-Reply-To: References: Message-ID: On Sun, 5 Dec 2021 18:38:05 GMT, Guoxiong Li wrote: > Hi all, > > This patch uses the full name and the census link of the credited reviewer so that the `### Reviewers` part can be clearer. > > For example, the [PR-6562](https://github.com/openjdk/jdk/pull/6562) has a credited reviewer which is shown as `jbhateja - Committer Added manually`. > > After this patch, it will show: `Jatin Bhateja - Committer Added manually`. The full name `Jatin Bhateja` will replace the username `jbhateja`. > > If these is a census link, it will show: `[Jatin Bhateja](https://openjdk.java.net/census#jbhateja) - Committer Added manually`. > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Looks good otherwise. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 403: > 401: ret.append("@"); > 402: ret.append(user.username()); > 403: ret.append(" (Unknown "); I think I prefer the original message "no known user name / role". ------------- PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 16:15:37 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:15:37 GMT Subject: RFR: 1258: Add review link/details to comments section In-Reply-To: <82Lhou2ZUJOuLH9cEdo-RCMLciiSKJ8RknOLKvMkfEE=.0788ce4b-d6e2-4425-99c2-5c9fd29b47fa@github.com> References: <82Lhou2ZUJOuLH9cEdo-RCMLciiSKJ8RknOLKvMkfEE=.0788ce4b-d6e2-4425-99c2-5c9fd29b47fa@github.com> Message-ID: On Mon, 6 Dec 2021 15:27:47 GMT, Erik Joelsson wrote: > You are correct, we have "commitLink": "false" in the configuration for the confidential notifier. @erikj79 Given this, if we change the method `addWebLink` as you suggested. We may get two comments in public issues because the method `addWebLinkAsComment` can't identify the comment added by the method `onNewCommit`. We need to remove the relate code about adding comment in `onNewCommit`. The related code, which adds both link and comment like `onNewCommit`, need to be removed, too.(I am not sure whether these code exist at other classes) So I suggest that we can set the config `reviewLink` to `false`, too. And then add the comment or remove the comment when needed or unneeded. It follows the convention : if we need to add both the link and comment, we need to disable the link at the confidential issues.(such as "commitLink": "false"). > If we need to add Issue::removeComment, then only implement it where it's going to be used, which is in JiraIssue. For GithubPullRequest and GitlabMergeRequest, better leave it not implemented than implemented but not tested. Agree. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Mon Dec 6 16:23:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:23:28 GMT Subject: RFR: 635: Add census link for credited reviewers [v2] In-Reply-To: References: Message-ID: <4WwLkJ_l-5-cZFGLC6ZmlA86nb9gEJONMRXZzBpkIIU=.5ae8dba6-57d9-454c-8819-3f9cd7e09601@github.com> > Hi all, > > This patch uses the full name and the census link of the credited reviewer so that the `### Reviewers` part can be clearer. > > For example, the [PR-6562](https://github.com/openjdk/jdk/pull/6562) has a credited reviewer which is shown as `jbhateja - Committer Added manually`. > > After this patch, it will show: `Jatin Bhateja - Committer Added manually`. The full name `Jatin Bhateja` will replace the username `jbhateja`. > > If these is a census link, it will show: `[Jatin Bhateja](https://openjdk.java.net/census#jbhateja) - Committer Added manually`. > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix the output message. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1252/files - new: https://git.openjdk.java.net/skara/pull/1252/files/2774c8a2..d69c7037 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1252&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1252&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1252.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1252/head:pull/1252 PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 16:23:29 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:23:29 GMT Subject: RFR: 635: Add census link for credited reviewers [v2] In-Reply-To: References: Message-ID: <3kcUi0JkvGGMXSbJu2WdjtC3eHnFu-WPxpTvdcSI3mE=.2903cfd5-2192-45c6-9f5e-3779113b904b@github.com> On Mon, 6 Dec 2021 15:52:35 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix the output message. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 403: > >> 401: ret.append("@"); >> 402: ret.append(user.username()); >> 403: ret.append(" (Unknown "); > > I think I prefer the original message "no known user name / role". Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 16:36:19 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:36:19 GMT Subject: RFR: 1258: Add review link/details to comments section [v2] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Move the code about adding comment out of the reviewLink block. - Not implement the unused method. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1250/files - new: https://git.openjdk.java.net/skara/pull/1250/files/0dca8e8d..bcfee9d5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=00-01 Stats: 18 lines in 4 files changed: 3 ins; 7 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1250.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1250/head:pull/1250 PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Mon Dec 6 16:44:28 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:44:28 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> Message-ID: On Mon, 6 Dec 2021 15:33:31 GMT, Erik Joelsson wrote: > I think size delta in the case of modified is fine. In my experience, it's very rare for binary patches to actually be partial in real situations. When replacing an image or archive, the whole file usually changes enough. If the binary patch is empty, due to file moved/rename, then we can't really do anything about that unfortunately. Have you looked at actual patch output from Git to see what it looks like for renamed binary files? Git doesn't track file renames explicitly, so I'm not sure what would actually happen here. Moved file is identifed as `renamed`. The `renamed` diff information is shown below. :100644 100644 c9eef64 c9eef64 R100 t/1.png t/2.png diff --git a/t/1.png b/t/2.png similarity index 100% rename from t/1.png rename to t/2.png It only has the source file and target file and have no information about size. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Mon Dec 6 16:47:41 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 16:47:41 GMT Subject: RFR: 635: Add census link for credited reviewers [v2] In-Reply-To: <4WwLkJ_l-5-cZFGLC6ZmlA86nb9gEJONMRXZzBpkIIU=.5ae8dba6-57d9-454c-8819-3f9cd7e09601@github.com> References: <4WwLkJ_l-5-cZFGLC6ZmlA86nb9gEJONMRXZzBpkIIU=.5ae8dba6-57d9-454c-8819-3f9cd7e09601@github.com> Message-ID: <0DyTzFDHLz98tvqzG966NZapud1Njal4ysOiShtu-ls=.99f271fa-1039-4aad-9bef-95589646d26c@github.com> On Mon, 6 Dec 2021 16:23:28 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch uses the full name and the census link of the credited reviewer so that the `### Reviewers` part can be clearer. >> >> For example, the [PR-6562](https://github.com/openjdk/jdk/pull/6562) has a credited reviewer which is shown as `jbhateja - Committer Added manually`. >> >> After this patch, it will show: `Jatin Bhateja - Committer Added manually`. The full name `Jatin Bhateja` will replace the username `jbhateja`. >> >> If these is a census link, it will show: `[Jatin Bhateja](https://openjdk.java.net/census#jbhateja) - Committer Added manually`. >> >> And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix the output message. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 16:51:10 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:51:10 GMT Subject: RFR: 635: Add census link for credited reviewers [v2] In-Reply-To: <0DyTzFDHLz98tvqzG966NZapud1Njal4ysOiShtu-ls=.99f271fa-1039-4aad-9bef-95589646d26c@github.com> References: <4WwLkJ_l-5-cZFGLC6ZmlA86nb9gEJONMRXZzBpkIIU=.5ae8dba6-57d9-454c-8819-3f9cd7e09601@github.com> <0DyTzFDHLz98tvqzG966NZapud1Njal4ysOiShtu-ls=.99f271fa-1039-4aad-9bef-95589646d26c@github.com> Message-ID: On Mon, 6 Dec 2021 16:45:03 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix the output message. > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1252 From erikj at openjdk.java.net Mon Dec 6 16:54:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 16:54:19 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> Message-ID: On Mon, 6 Dec 2021 16:41:59 GMT, Guoxiong Li wrote: > > I think size delta in the case of modified is fine. In my experience, it's very rare for binary patches to actually be partial in real situations. When replacing an image or archive, the whole file usually changes enough. If the binary patch is empty, due to file moved/rename, then we can't really do anything about that unfortunately. Have you looked at actual patch output from Git to see what it looks like for renamed binary files? Git doesn't track file renames explicitly, so I'm not sure what would actually happen here. > > Moved file is identifed as `renamed`. The `renamed` diff information is shown below. > > ``` > :100644 100644 c9eef64 c9eef64 R100 t/1.png t/2.png > > diff --git a/t/1.png b/t/2.png > similarity index 100% > rename from t/1.png > rename to t/2.png > ``` > > It only has the source file and target file and have no information about size. Then we can't check the size of files in such changes. We are limited to what Git will tell us here. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Mon Dec 6 16:56:25 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 16:56:25 GMT Subject: Integrated: 635: Add census link for credited reviewers In-Reply-To: References: Message-ID: On Sun, 5 Dec 2021 18:38:05 GMT, Guoxiong Li wrote: > Hi all, > > This patch uses the full name and the census link of the credited reviewer so that the `### Reviewers` part can be clearer. > > For example, the [PR-6562](https://github.com/openjdk/jdk/pull/6562) has a credited reviewer which is shown as `jbhateja - Committer Added manually`. > > After this patch, it will show: `Jatin Bhateja - Committer Added manually`. The full name `Jatin Bhateja` will replace the username `jbhateja`. > > If these is a census link, it will show: `[Jatin Bhateja](https://openjdk.java.net/census#jbhateja) - Committer Added manually`. > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: afe9eab7 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/afe9eab7875defe2cc612b9f4b1a5ea521133824 Stats: 80 lines in 2 files changed: 58 ins; 0 del; 22 mod 635: Add census link for credited reviewers Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1252 From gli at openjdk.java.net Mon Dec 6 17:07:38 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 17:07:38 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v3] In-Reply-To: References: <7R9JA_AvRnoPFmlTzQR9FsLTRjdBmaAfQc3QZnQyP8s=.708a387d-94c6-496d-bf42-3a627cd216ff@github.com> <5HP3HtarYfzodgtCrEnhKaNzETWrs0MhsBzxoxM4n_g=.3a3f017e-396e-43f8-a8b6-345642b69d91@github.com> Message-ID: <1U0gWAti3VKxe7rSZZm_0ahy_-iNZwzoJaWtWYPqM1w=.76f3d788-3346-4657-891d-ae3d7e3105e1@github.com> On Mon, 6 Dec 2021 15:33:31 GMT, Erik Joelsson wrote: > And the renamed and copied files have no size, they only have the source path and target patch. Please note the copied file has no size, too: :100644 100644 c9eef64 c9eef64 C100 1.png t/1.png diff --git a/1.png b/t/1.png similarity index 100% copy from 1.png copy to t/1.png ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From kcr at openjdk.java.net Mon Dec 6 17:21:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 6 Dec 2021 17:21:55 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v5] In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 13:16:28 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Fix the output message. > - Check the renamed/modified binary file. How is this diff generated? The commit itself does have the complete information. Here is a test I just did in the jfx repo: $ git diff --no-renames --binary HEAD diff --git a/tests/manual/web/dnd/blue_renamed.png b/tests/manual/web/dnd/blue_renamed.png new file mode 100644 index 0000000000000000000000000000000000000000..d8f1d7de2baf7851a8c63506709ea0b83806c172 GIT binary patch literal 207 zcmeAS at N?(olHy`uVBq!ia0vp^4j|0I1SD0tpLGJMX`U{QAsLNtZyEA7I54mrd~CX> zH9xbkMOI6SW#R%xl?RMmDgilmHvluqo1)RTg`Mv?V OkipZ{&t;ucLK6Uiphv*~ literal 0 HcmV?d00001 diff --git a/tests/manual/web/dnd/red_copied.png b/tests/manual/web/dnd/red_copied.png new file mode 100644 index 0000000000000000000000000000000000000000..66d776a846d3671512c5afba2623fb3a0dac847e GIT binary patch literal 284 zcmeAS at N?(olHy`uVBq!ia0vp^4j|0I1SD0tpLGJM$DS^ZAsLNtFDh~!N?>Sv_&55Z z(KclXF&Vv%@QqP1qHJdUiWyh3Iht}g+EfoF{kYt;ZmsUw2b?7jQ$N_M|A at 2OynoyI z$7SCvdS30mEPu_v%c6JMO!1iobE)Xf`Y(i}5VVexdoF^S?Tyk7Q<7{dCU0qvW^u=({Q52RG;)e&*}{ itMTjP(XoB98W>z)d%Zc+kzm%-E3&t;ucLK6Tl6m?4g literal 0 HcmV?d00001 ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Mon Dec 6 17:52:01 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 6 Dec 2021 17:52:01 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v5] In-Reply-To: References: Message-ID: <5z5laiJGc4swwF__57QNWRwozz6hE_LQ8K_F4uC7q7c=.46294945-cd91-4351-95ec-3bc56895978d@github.com> On Mon, 6 Dec 2021 17:19:26 GMT, Kevin Rushforth wrote: > How is this diff generated? The commit itself does have the complete information. Here is a test I just did in the jfx repo: Good caght. It seems that the option `--no-renames` should be added to the corresponding code. @kevinrushforth Do you know which method about the git/hg should we revise? If you don't know, I will do more search tomorrow. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Mon Dec 6 18:17:30 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 6 Dec 2021 18:17:30 GMT Subject: RFR: 1270: Allow different 'issues' urls for different repositories in mlbridge configuration Message-ID: The 'issues' URL in the mlbridge configuration is currently global for all repositories. We need to be able to configure different Jira instances for different repositories. ------------- Commit messages: - Repo specific issue tracker for mlbridge Changes: https://git.openjdk.java.net/skara/pull/1254/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1254&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1270 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1254.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1254/head:pull/1254 PR: https://git.openjdk.java.net/skara/pull/1254 From gli at openjdk.java.net Tue Dec 7 08:31:27 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 08:31:27 GMT Subject: RFR: 596: Allow short-hand syntax for /label command Message-ID: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Hi all, This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. Some example: Add a label: `/label +labelName` Remove a label: `/label -labelName` Mixed: `/label +labelName, -labelName2` Mixed: `/label labelName, +labelName2, -labelName3` And the test cases are added. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 596: Allow short-hand syntax for /label command Changes: https://git.openjdk.java.net/skara/pull/1255/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1255&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-596 Stats: 223 lines in 2 files changed: 187 ins; 5 del; 31 mod Patch: https://git.openjdk.java.net/skara/pull/1255.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1255/head:pull/1255 PR: https://git.openjdk.java.net/skara/pull/1255 From erikj at openjdk.java.net Tue Dec 7 14:03:36 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Dec 2021 14:03:36 GMT Subject: RFR: 596: Allow short-hand syntax for /label command In-Reply-To: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: On Tue, 7 Dec 2021 08:27:36 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. > > Some example: > > Add a label: `/label +labelName` > Remove a label: `/label -labelName` > Mixed: `/label +labelName, -labelName2` > Mixed: `/label labelName, +labelName2, -labelName3` > > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Looks good otherwise. bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 123: > 121: > 122: private void printInvalidLabels(List invalidLabels, PullRequestBot bot, PrintWriter reply) { > 123: reply.println(""); // Intentionally blank line. Why a blank line? I can't see anything printed before this method is called. ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From gli at openjdk.java.net Tue Dec 7 14:26:38 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 14:26:38 GMT Subject: RFR: 596: Allow short-hand syntax for /label command In-Reply-To: References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: On Tue, 7 Dec 2021 14:00:38 GMT, Erik Joelsson wrote: >> Hi all, >> >> This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. >> >> Some example: >> >> Add a label: `/label +labelName` >> Remove a label: `/label -labelName` >> Mixed: `/label +labelName, -labelName2` >> Mixed: `/label labelName, +labelName2, -labelName3` >> >> >> And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 123: > >> 121: >> 122: private void printInvalidLabels(List invalidLabels, PullRequestBot bot, PrintWriter reply) { >> 123: reply.println(""); // Intentionally blank line. > > Why a blank line? I can't see anything printed before this method is called. The `@username` will be printed at first. If the invalid labels is more than 2. The output will be: @username The label `labelName` is not a valid label. The label `labelName` is not a valid label. I would like to adjust it to : @username The label `labelName` is not a valid label. The label `labelName` is not a valid label. ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From erikj at openjdk.java.net Tue Dec 7 14:36:17 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Dec 2021 14:36:17 GMT Subject: RFR: 1258: Add review link/details to comments section [v2] In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 16:36:19 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Move the code about adding comment out of the reviewLink block. > - Not implement the unused method. I have given this a lot of thought, and I think I'm ok with your current solution. It's a bit unfortunate to have differently formatted comments for confidential vs non confidential, but it's good enough for now. bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 61: > 59: private final Logger log = Logger.getLogger("org.openjdk.skara.bots.notify"); > 60: > 61: private static final String pullRequestTip = "A pull request is submitted for review."; Suggestion: private static final String pullRequestTip = "A pull request was submitted for review."; ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Tue Dec 7 14:38:23 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Dec 2021 14:38:23 GMT Subject: RFR: 596: Allow short-hand syntax for /label command In-Reply-To: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: On Tue, 7 Dec 2021 08:27:36 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. > > Some example: > > Add a label: `/label +labelName` > Remove a label: `/label -labelName` > Mixed: `/label +labelName, -labelName2` > Mixed: `/label labelName, +labelName2, -labelName3` > > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From erikj at openjdk.java.net Tue Dec 7 14:38:23 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 7 Dec 2021 14:38:23 GMT Subject: RFR: 596: Allow short-hand syntax for /label command In-Reply-To: References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: On Tue, 7 Dec 2021 14:24:03 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 123: >> >>> 121: >>> 122: private void printInvalidLabels(List invalidLabels, PullRequestBot bot, PrintWriter reply) { >>> 123: reply.println(""); // Intentionally blank line. >> >> Why a blank line? I can't see anything printed before this method is called. > > The `@username` will be printed at first. If the invalid labels is more than 2. The output will be: > > > @username The label `labelName` is not a valid label. > The label `labelName` is not a valid label. > > > I would like to adjust it to : > > > @username > The label `labelName` is not a valid label. > The label `labelName` is not a valid label. Ah, makes sense. ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From gli at openjdk.java.net Tue Dec 7 15:00:27 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 15:00:27 GMT Subject: RFR: 596: Allow short-hand syntax for /label command In-Reply-To: References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: <0OpoPg2BIJmZKom-kj6772CgGDOGPIRcJLX7DubMvXY=.269e54c8-e313-4624-8a5c-112b7692da01@github.com> On Tue, 7 Dec 2021 14:35:38 GMT, Erik Joelsson wrote: >> Hi all, >> >> This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. >> >> Some example: >> >> Add a label: `/label +labelName` >> Remove a label: `/label -labelName` >> Mixed: `/label +labelName, -labelName2` >> Mixed: `/label labelName, +labelName2, -labelName3` >> >> >> And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From erikj at openjdk.java.net Fri Dec 10 19:37:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 10 Dec 2021 19:37:52 GMT Subject: RFR: 1281: Jcheck fails to run due to IllegalStateException Message-ID: This patch changes the reaction on a hg-tags jcheck failure in a PR from throwing IllegalStateException to just ignore with a log message. This is restoring the behavior to before [423](https://github.com/openjdk/skara/pull/423) for this particular check. See bug description for a more in depth explanation why this is needed. ------------- Commit messages: - SKARA-1281 Changes: https://git.openjdk.java.net/skara/pull/1258/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1258&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1281 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1258.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1258/head:pull/1258 PR: https://git.openjdk.java.net/skara/pull/1258 From erikj at openjdk.java.net Fri Dec 10 20:35:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 10 Dec 2021 20:35:05 GMT Subject: RFR: 1280: Possible race condition when integrating PR could cause a spurious "Withdrawn" email Message-ID: <4xXnPDaVPu_N-2kucaRbiU0cjgj8JVj_PlX8eNRK350=.e63b4299-3d90-445b-af74-ad1c6b5667fe@github.com> Change the order of adding "integrated" label and closing a pull request to avoid a race with the mlbridge bot, which could otherwise mistakenly send out a "withdrawn" message for a PR that is in the process of being integrated. ------------- Commit messages: - SKARA-1280 Changes: https://git.openjdk.java.net/skara/pull/1259/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1259&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1280 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1259.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1259/head:pull/1259 PR: https://git.openjdk.java.net/skara/pull/1259 From kcr at openjdk.java.net Tue Dec 7 22:34:47 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 22:34:47 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v5] In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 13:16:28 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds the large binary file check to the jcheck. >> >> The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. >> >> >> [checks] >> error = binary >> >> [checks "binary"] >> .*.bin=200B >> .*.o=1k >> >> >> The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. >> >> The corresponding test cases are added. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: > > - Fix the output message. > - Check the renamed/modified binary file. No, I don't know. And one thing I should mention is that there are almost certainly other cases where you do want `git diff` to do rename detection (`webrev` comes to mind), so I recommend only inhibiting rename detection when checking binary files. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Tue Dec 7 15:10:00 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 15:10:00 GMT Subject: RFR: 1258: Add review link/details to comments section [v3] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix typo. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1250/files - new: https://git.openjdk.java.net/skara/pull/1250/files/bcfee9d5..458dbd27 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1250.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1250/head:pull/1250 PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Wed Dec 8 05:01:48 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 05:01:48 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v6] In-Reply-To: References: Message-ID: <4TIG9IzfydAC1hy4JNl1PjPY5FRnLDPAJ4XJh2RSnEY=.a6ba21fc-1743-4606-a98d-2cbd4a349874@github.com> > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: - Excluded copied and renamed files. - Excluded renamed and copied files. Use Git commit information. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/b112f033..588660cf Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=05 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=04-05 Stats: 16 lines in 2 files changed: 8 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From kcr at openjdk.java.net Tue Dec 7 22:28:57 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 22:28:57 GMT Subject: RFR: 1270: Allow different 'issues' urls for different repositories in mlbridge configuration In-Reply-To: References: Message-ID: <-159N5Gypz2Y4ntM5z9OkKpk6FLQ-9oqPlIqZLSzNf0=.e5622be3-60ed-412e-b30b-692110045de2@github.com> On Mon, 6 Dec 2021 18:13:47 GMT, Erik Joelsson wrote: > The 'issues' URL in the mlbridge configuration is currently global for all repositories. We need to be able to configure different Jira instances for different repositories. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1254 From gli at openjdk.java.net Tue Dec 7 15:10:01 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 15:10:01 GMT Subject: RFR: 1258: Add review link/details to comments section [v2] In-Reply-To: References: Message-ID: On Tue, 7 Dec 2021 14:32:37 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Move the code about adding comment out of the reviewLink block. >> - Not implement the unused method. > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 61: > >> 59: private final Logger log = Logger.getLogger("org.openjdk.skara.bots.notify"); >> 60: >> 61: private static final String pullRequestTip = "A pull request is submitted for review."; > > Suggestion: > > private static final String pullRequestTip = "A pull request was submitted for review."; Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Wed Dec 8 14:41:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 8 Dec 2021 14:41:04 GMT Subject: Integrated: 1269: Handle Jira host with path element in URL In-Reply-To: <-QFNy1YmK54EqqJA5hB0M2XssDfly3F81g6rFTURh30=.b4d57f6a-e50a-425b-b16a-c8f01a1b284f@github.com> References: <-QFNy1YmK54EqqJA5hB0M2XssDfly3F81g6rFTURh30=.b4d57f6a-e50a-425b-b16a-c8f01a1b284f@github.com> Message-ID: On Fri, 3 Dec 2021 22:03:02 GMT, Erik Joelsson wrote: > The IssueTracker/JiraHost classes in Skara make the assumption that the base URL for Jira is just a hostname with no path elements. In order to use Skara with a Jira instance with a URL that has a path element, this needs to be fixed. > > Instead of always basing REST call URLs on the configured base path and appending to it, there are many cases where the URIBuilder::setPath is used, which overwrites any existing path element. This is especially troublesome when combined with using IssueProject::webUrl as the base for these URLs. > > I would like to fix this by adding a supported way of getting the base URI from an IssueTracker (IssueTracker::uri), replace all uses of ::webUrl for constructing other URLs with this new call, and replacing all ::setPath with ::appendPath (in IssueTracker/Jira related code). > > This change will require all configurations to be careful not to add a trailing slash to the URL for the Jira instance. > > I intend to run this for a while in the staging environment to make sure it works. This pull request has now been integrated. Changeset: 57c88f57 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/57c88f57681bacb96ba1ded9670562e5faec7943 Stats: 25 lines in 9 files changed: 14 ins; 0 del; 11 mod 1269: Handle Jira host with path element in URL Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1251 From kcr at openjdk.java.net Tue Dec 7 22:31:42 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 7 Dec 2021 22:31:42 GMT Subject: RFR: 1269: Handle Jira host with path element in URL In-Reply-To: <-QFNy1YmK54EqqJA5hB0M2XssDfly3F81g6rFTURh30=.b4d57f6a-e50a-425b-b16a-c8f01a1b284f@github.com> References: <-QFNy1YmK54EqqJA5hB0M2XssDfly3F81g6rFTURh30=.b4d57f6a-e50a-425b-b16a-c8f01a1b284f@github.com> Message-ID: On Fri, 3 Dec 2021 22:03:02 GMT, Erik Joelsson wrote: > The IssueTracker/JiraHost classes in Skara make the assumption that the base URL for Jira is just a hostname with no path elements. In order to use Skara with a Jira instance with a URL that has a path element, this needs to be fixed. > > Instead of always basing REST call URLs on the configured base path and appending to it, there are many cases where the URIBuilder::setPath is used, which overwrites any existing path element. This is especially troublesome when combined with using IssueProject::webUrl as the base for these URLs. > > I would like to fix this by adding a supported way of getting the base URI from an IssueTracker (IssueTracker::uri), replace all uses of ::webUrl for constructing other URLs with this new call, and replacing all ::setPath with ::appendPath (in IssueTracker/Jira related code). > > This change will require all configurations to be careful not to add a trailing slash to the URL for the Jira instance. > > I intend to run this for a while in the staging environment to make sure it works. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1251 From gli at openjdk.java.net Tue Dec 7 16:02:23 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 7 Dec 2021 16:02:23 GMT Subject: Integrated: 596: Allow short-hand syntax for /label command In-Reply-To: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> References: <9JT0Xtq-KTKy33XEzRtiHdsLz0qe5KV2SVRR0YgjDMI=.545f1a1c-c0b9-4021-a5a3-f72498e8b237@github.com> Message-ID: <_F9Gakjlgp3zzislkSBZkAe1hWp0XKrs2g2B1JOL-CI=.d823d8d1-c861-4208-a94a-dfdda5872a18@github.com> On Tue, 7 Dec 2021 08:27:36 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds the short-hand syntax for `/label` command. The short-hand syntax makes the users easily add and remove the labels in one comment. > > Some example: > > Add a label: `/label +labelName` > Remove a label: `/label -labelName` > Mixed: `/label +labelName, -labelName2` > Mixed: `/label labelName, +labelName2, -labelName3` > > > And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 474b7e8f Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/474b7e8f431021b9bad1072d4f2459f887bd05fd Stats: 223 lines in 2 files changed: 187 ins; 5 del; 31 mod 596: Allow short-hand syntax for /label command Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1255 From erikj at openjdk.java.net Wed Dec 8 14:39:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 8 Dec 2021 14:39:39 GMT Subject: Integrated: 1270: Allow different 'issues' urls for different repositories in mlbridge configuration In-Reply-To: References: Message-ID: On Mon, 6 Dec 2021 18:13:47 GMT, Erik Joelsson wrote: > The 'issues' URL in the mlbridge configuration is currently global for all repositories. We need to be able to configure different Jira instances for different repositories. This pull request has now been integrated. Changeset: bfc39d95 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/bfc39d9570eec0900ec2bf99e6035a8e33989e6f Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 1270: Allow different 'issues' urls for different repositories in mlbridge configuration Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1254 From gli at openjdk.java.net Wed Dec 8 10:32:26 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 10:32:26 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review Message-ID: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> Hi all, This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 713: Rename git/pr-approve to git-pr-review Changes: https://git.openjdk.java.net/skara/pull/1256/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1256&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-713 Stats: 216 lines in 4 files changed: 124 ins; 86 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1256.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1256/head:pull/1256 PR: https://git.openjdk.java.net/skara/pull/1256 From erikj at openjdk.java.net Wed Dec 8 15:17:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 8 Dec 2021 15:17:08 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> Message-ID: <33PrhCXIrH0CoCns091hwXDkC8QRXCJO5IDvxqxSjY8=.bd9d8454-715c-4454-98c7-d81cfd97e6f5@github.com> On Wed, 8 Dec 2021 10:28:31 GMT, Guoxiong Li wrote: > Hi all, > > This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. > > I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I recommend using the repository https://github.com/openjdk/playground to test your changes. You can create PRs and play around there freely. ------------- PR: https://git.openjdk.java.net/skara/pull/1256 From gli at openjdk.java.net Wed Dec 8 15:48:13 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 15:48:13 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <33PrhCXIrH0CoCns091hwXDkC8QRXCJO5IDvxqxSjY8=.bd9d8454-715c-4454-98c7-d81cfd97e6f5@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> <33PrhCXIrH0CoCns091hwXDkC8QRXCJO5IDvxqxSjY8=.bd9d8454-715c-4454-98c7-d81cfd97e6f5@github.com> Message-ID: On Wed, 8 Dec 2021 15:14:05 GMT, Erik Joelsson wrote: > I recommend using the repository https://github.com/openjdk/playground to test your changes. You can create PRs and play around there freely. Thanks for the advising. ------------- PR: https://git.openjdk.java.net/skara/pull/1256 From erikj at openjdk.java.net Thu Dec 9 14:42:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 9 Dec 2021 14:42:25 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> Message-ID: On Wed, 8 Dec 2021 10:28:31 GMT, Guoxiong Li wrote: > Hi all, > > This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. > > I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong If you think you have tested this enough, then the change looks good to me. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1256 From gli at openjdk.java.net Thu Dec 9 14:48:19 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 9 Dec 2021 14:48:19 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <33PrhCXIrH0CoCns091hwXDkC8QRXCJO5IDvxqxSjY8=.bd9d8454-715c-4454-98c7-d81cfd97e6f5@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> <33PrhCXIrH0CoCns091hwXDkC8QRXCJO5IDvxqxSjY8=.bd9d8454-715c-4454-98c7-d81cfd97e6f5@github.com> Message-ID: On Wed, 8 Dec 2021 15:14:05 GMT, Erik Joelsson wrote: >> Hi all, >> >> This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. >> >> I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > I recommend using the repository https://github.com/openjdk/playground to test your changes. You can create PRs and play around there freely. @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1256 From gli at openjdk.java.net Wed Dec 8 14:21:40 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 14:21:40 GMT Subject: RFR: 1275: The unknown sub-command will ouput the unexpected message Message-ID: Hi all, When using the unknown command, the client will output the unexpected message. For example: $ git-pr lis 123 error: unexpected input: 123 usage: git-pr [options] [] -h, --help Show help --verbose Turn on verbose output --debug Turn on debugging output --version Print the version of this tool When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. This patch will output more information to the user: $ git-pr lis 123 Can't find the sub-command 'lis', the default sub-command 'help' will be executed. The arguments [lis, 123] will be passed to the default sub-command. error: unexpected input: 123 usage: git-pr [options] [] -h, --help Show help --verbose Turn on verbose output --debug Turn on debugging output --version Print the version of this tool The added information can let the user know why the following output is shown. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1275: The unknown sub-command will ouput the unexpected message Changes: https://git.openjdk.java.net/skara/pull/1257/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1275 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1257.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1257/head:pull/1257 PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Wed Dec 8 15:12:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 8 Dec 2021 15:12:34 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: <6-aFpETpxbfDUXiL5aQWUzwkO9W4qUyaT8bQ0yGFHYw=.6fe7ff00-215b-445c-b88b-41b420955540@github.com> On Wed, 8 Dec 2021 14:17:51 GMT, Guoxiong Li wrote: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong The new message does explain in great detail how the implementation interprets the given input, but I think it's unnecessarily verbose. I think something like this would be clear enough: $ git-pr lis 123 error: unknown sub-command: lis error: unexpected input: 123 usage: git-pr [options] [] -h, --help Show help --verbose Turn on verbose output --debug Turn on debugging output --version Print the version of this tool However, not all users of MultiCommandParser have the help command as default. The webrev command does not and printing all of this text when running `webrev` with no explicit sub-command would be a regression IMO. Printing this error would need to be made conditional on if a sub-command is required or not. For `pr` it is, while for `webrev` it's not. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Wed Dec 8 15:42:13 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 15:42:13 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: <-Vf-dl1S2hS6tS5OB-gn5pRXRuPfkzeLAd_H3FmbBRs=.6ae9dfe4-ae2b-4532-bcf3-eab402c76fb9@github.com> On Wed, 8 Dec 2021 14:17:51 GMT, Guoxiong Li wrote: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong If we only output `error: unknown sub-command: lis`, the following output is confused: error: unexpected input: 123 usage: git-pr [options] [] // <-- here should be `git-pr help [options] [] `. See SKARA-1274 -h, --help Show help --verbose Turn on verbose output --debug Turn on debugging output --version Print the version of this tool The user would confuse why the client outputs the usage of the `git-pr help`. Because the user expects the following message. error: unknown sub-command: lis Available sub-commands are: - apply - approve - cc So I think it is necessary to let user know what is happening. As for `git webrev`, it will output the following message in my patch. Because the `git-webrev generate` will execute. Can't find the sub-command 'lis', the default sub-command 'generate' will be executed. The arguments [lis, 123] will be passed to the default sub-command. Now I suggest the following information: $ git-pr lis 123 error: unknown sub-command: lis the default sub-command 'help' will be executed with the arguments [lis, 123]. error: unexpected input: 123 usage: git-pr [options] [] -h, --help Show help --verbose Turn on verbose output --debug Turn on debugging output --version Print the version of this tool $ git-webrev lis 123 error: unknown sub-command: lis the default sub-command 'generate' will be executed with the arguments [lis, 123]. error: unexpected input: 123 usage: git webrev [options] [] // ignore ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Wed Dec 8 16:08:20 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 8 Dec 2021 16:08:20 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: On Wed, 8 Dec 2021 14:17:51 GMT, Guoxiong Li wrote: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Because the code is still running and is not stopped. It is good to change the `error` to `warning`. The message could be: $ git-pr lis 123 warning: unknown sub-command: lis the default sub-command 'help' will be executed with the arguments [lis, 123]. error: unexpected input: 123 usage: git-pr [options] [] // ignore ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Thu Dec 9 14:40:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 9 Dec 2021 14:40:50 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: On Wed, 8 Dec 2021 14:17:51 GMT, Guoxiong Li wrote: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I like the last suggestion much better, but I still don't think it should be printed for `git webrev`. Running webrev without a sub-command is normal procedure and should not result in a warning. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Thu Dec 9 15:03:39 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 9 Dec 2021 15:03:39 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v2] In-Reply-To: References: Message-ID: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Adjust the message. Excluded the 'git-webrev'. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1257/files - new: https://git.openjdk.java.net/skara/pull/1257/files/6efb2e9b..6e40540d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=00-01 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1257.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1257/head:pull/1257 PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Thu Dec 9 15:03:41 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 9 Dec 2021 15:03:41 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 14:37:56 GMT, Erik Joelsson wrote: >> Hi all, >> >> When using the unknown command, the client will output the unexpected message. For example: >> >> >> $ git-pr lis 123 >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. >> >> This patch will output more information to the user: >> >> >> $ git-pr lis 123 >> >> Can't find the sub-command 'lis', the default sub-command 'help' will be executed. >> The arguments [lis, 123] will be passed to the default sub-command. >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> The added information can let the user know why the following output is shown. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > I like the last suggestion much better, but I still don't think it should be printed for `git webrev`. Running webrev without a sub-command is normal procedure and should not result in a warning. @erikj79 I updated the code just now. The new code uses the `warning` and excludes the `git webrev` command as you suggested. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From kcr at openjdk.java.net Fri Dec 10 23:07:17 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 23:07:17 GMT Subject: RFR: 1280: Possible race condition when integrating PR could cause a spurious "Withdrawn" email In-Reply-To: <4xXnPDaVPu_N-2kucaRbiU0cjgj8JVj_PlX8eNRK350=.e63b4299-3d90-445b-af74-ad1c6b5667fe@github.com> References: <4xXnPDaVPu_N-2kucaRbiU0cjgj8JVj_PlX8eNRK350=.e63b4299-3d90-445b-af74-ad1c6b5667fe@github.com> Message-ID: On Fri, 10 Dec 2021 20:31:27 GMT, Erik Joelsson wrote: > Change the order of adding "integrated" label and closing a pull request to avoid a race with the mlbridge bot, which could otherwise mistakenly send out a "withdrawn" message for a PR that is in the process of being integrated. Looks fine. And I can think of no downside to doing this. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1259 From kcr at openjdk.java.net Fri Dec 10 23:08:25 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 10 Dec 2021 23:08:25 GMT Subject: RFR: 1281: Jcheck fails to run due to IllegalStateException In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 19:34:00 GMT, Erik Joelsson wrote: > This patch changes the reaction on a hg-tags jcheck failure in a PR from throwing IllegalStateException to just ignore with a log message. This is restoring the behavior to before [423](https://github.com/openjdk/skara/pull/423) for this particular check. See bug description for a more in depth explanation why this is needed. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1258 From cstein at openjdk.java.net Tue Dec 14 08:27:30 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 08:27:30 GMT Subject: RFR: build: update to JUnit 5.8.2 Message-ID: This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? ------------- Commit messages: - build: update to JUnit 5.8.2 Changes: https://git.openjdk.java.net/skara/pull/1260/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1260&range=00 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1260.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1260/head:pull/1260 PR: https://git.openjdk.java.net/skara/pull/1260 From erikj at openjdk.java.net Tue Dec 14 14:10:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 14:10:44 GMT Subject: RFR: build: update to JUnit 5.8.2 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 08:24:03 GMT, Christian Stein wrote: > This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. > > PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? I'm not sure why an explicit junit version is listed in the README as the gradle build specifies the dependency anyway, but as long as that number is there, I think it should be updated in unison with the gradle dependency. It seems someone missed that last time this version was bumped. Could you add this to your change? ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From cstein at openjdk.java.net Tue Dec 14 14:15:18 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 14:15:18 GMT Subject: RFR: build: update to JUnit 5.8.2 [v2] In-Reply-To: References: Message-ID: > This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. > > PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? Christian Stein has updated the pull request incrementally with one additional commit since the last revision: Update README.md ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1260/files - new: https://git.openjdk.java.net/skara/pull/1260/files/9bc6ad07..2c9aade7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1260&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1260&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1260.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1260/head:pull/1260 PR: https://git.openjdk.java.net/skara/pull/1260 From cstein at openjdk.java.net Tue Dec 14 14:15:19 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 14:15:19 GMT Subject: RFR: build: update to JUnit 5.8.2 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 08:24:03 GMT, Christian Stein wrote: > This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. > > PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? Done. What's up with pre-submit tests on mac os? ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From erikj at openjdk.java.net Tue Dec 14 14:41:47 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 14:41:47 GMT Subject: RFR: build: update to JUnit 5.8.2 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 14:12:13 GMT, Christian Stein wrote: > What's up with pre-submit tests on mac os? Not sure. We seem to have intermittent failures in the test base. I haven't had time to investigate all of them. I ran your patch on my own mac and it passed, so I don't think it's related to the junit version. ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From erikj at openjdk.java.net Tue Dec 14 14:41:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 14:41:48 GMT Subject: RFR: build: update to JUnit 5.8.2 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 14:37:02 GMT, Erik Joelsson wrote: > > What's up with pre-submit tests on mac os? > > Not sure. We seem to have intermittent failures in the test base. I haven't had time to investigate all of them. I ran your patch on my own mac and it passed, so I don't think it's related to the junit version. But now it looks like it failed twice in a row. Maybe this warrants more investigation. Hm, my PR failed yesterday too. ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From cstein at openjdk.java.net Tue Dec 14 15:56:33 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 15:56:33 GMT Subject: RFR: build: update to JUnit 5.8.2 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 14:15:18 GMT, Christian Stein wrote: >> This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. >> >> PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update README.md Seems to be related to Mercurial `5.9.3` vs `6.0` ... which is installed via `brew install mercurial` since about two weeks. ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From erikj at openjdk.java.net Tue Dec 14 16:13:46 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:13:46 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 Message-ID: Adjust ext.py to handle Mercurial versions 6.0+. ------------- Commit messages: - SKARA-1283 Changes: https://git.openjdk.java.net/skara/pull/1261/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1261&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1283 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1261.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1261/head:pull/1261 PR: https://git.openjdk.java.net/skara/pull/1261 From cstein at openjdk.java.net Tue Dec 14 16:17:39 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 16:17:39 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 In-Reply-To: References: Message-ID: <8e26rkwmO0Yy76rso1wHTrRQmHmeo7NJzmso69yaE5w=.73b8a96e-0feb-41f7-917d-139b909507c0@github.com> On Tue, 14 Dec 2021 16:09:52 GMT, Erik Joelsson wrote: > Adjust ext.py to handle Mercurial versions 6.0+. LGTM (until mercurial hits `10.0`?) ------------- Marked as reviewed by cstein (no project role). PR: https://git.openjdk.java.net/skara/pull/1261 From erikj at openjdk.java.net Tue Dec 14 16:29:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:29:27 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: > Adjust ext.py to handle Mercurial versions 6.0+. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Compare as int ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1261/files - new: https://git.openjdk.java.net/skara/pull/1261/files/721768f0..4c6a65aa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1261&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1261&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1261.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1261/head:pull/1261 PR: https://git.openjdk.java.net/skara/pull/1261 From cstein at openjdk.java.net Tue Dec 14 16:29:27 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 16:29:27 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 16:26:51 GMT, Erik Joelsson wrote: >> Adjust ext.py to handle Mercurial versions 6.0+. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Compare as int ?? ------------- Marked as reviewed by cstein (no project role). PR: https://git.openjdk.java.net/skara/pull/1261 From erikj at openjdk.java.net Tue Dec 14 16:29:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:29:28 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: <8e26rkwmO0Yy76rso1wHTrRQmHmeo7NJzmso69yaE5w=.73b8a96e-0feb-41f7-917d-139b909507c0@github.com> References: <8e26rkwmO0Yy76rso1wHTrRQmHmeo7NJzmso69yaE5w=.73b8a96e-0feb-41f7-917d-139b909507c0@github.com> Message-ID: On Tue, 14 Dec 2021 16:15:00 GMT, Christian Stein wrote: > LGTM (until mercurial hits `10.0`?) You are right, I should convert to int instead. Python really isn't my first language. ------------- PR: https://git.openjdk.java.net/skara/pull/1261 From erikj at openjdk.java.net Tue Dec 14 16:36:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:36:26 GMT Subject: RFR: build: update to JUnit 5.8.2 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 14:15:18 GMT, Christian Stein wrote: >> This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. >> >> PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Update README.md Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From erikj at openjdk.java.net Tue Dec 14 16:37:12 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:37:12 GMT Subject: Integrated: 1280: Possible race condition when integrating PR could cause a spurious "Withdrawn" email In-Reply-To: <4xXnPDaVPu_N-2kucaRbiU0cjgj8JVj_PlX8eNRK350=.e63b4299-3d90-445b-af74-ad1c6b5667fe@github.com> References: <4xXnPDaVPu_N-2kucaRbiU0cjgj8JVj_PlX8eNRK350=.e63b4299-3d90-445b-af74-ad1c6b5667fe@github.com> Message-ID: <62oTLD0_0lyVPFZ5DJf80kwBtgQM9Pmh-Q3igVfjqfw=.cfb75289-71c1-44d9-8af9-f1246e5edf64@github.com> On Fri, 10 Dec 2021 20:31:27 GMT, Erik Joelsson wrote: > Change the order of adding "integrated" label and closing a pull request to avoid a race with the mlbridge bot, which could otherwise mistakenly send out a "withdrawn" message for a PR that is in the process of being integrated. This pull request has now been integrated. Changeset: 2ed56ac1 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/2ed56ac14c73f118b3acb423402ff160b93eecb8 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 1280: Possible race condition when integrating PR could cause a spurious "Withdrawn" email Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1259 From erikj at openjdk.java.net Tue Dec 14 16:38:45 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 16:38:45 GMT Subject: Integrated: 1281: Jcheck fails to run due to IllegalStateException In-Reply-To: References: Message-ID: On Fri, 10 Dec 2021 19:34:00 GMT, Erik Joelsson wrote: > This patch changes the reaction on a hg-tags jcheck failure in a PR from throwing IllegalStateException to just ignore with a log message. This is restoring the behavior to before [423](https://github.com/openjdk/skara/pull/423) for this particular check. See bug description for a more in depth explanation why this is needed. This pull request has now been integrated. Changeset: 3caed6e5 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3caed6e5aa18b359b4a2cae61a2fb931dadd2837 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1281: Jcheck fails to run due to IllegalStateException Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1258 From kcr at openjdk.java.net Tue Dec 14 17:03:31 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 14 Dec 2021 17:03:31 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 16:29:27 GMT, Erik Joelsson wrote: >> Adjust ext.py to handle Mercurial versions 6.0+. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Compare as int Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1261 From gli at openjdk.java.net Tue Dec 14 17:03:31 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 14 Dec 2021 17:03:31 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 16:29:27 GMT, Erik Joelsson wrote: >> Adjust ext.py to handle Mercurial versions 6.0+. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Compare as int Does this patch also solve [SKARA-1264](https://bugs.openjdk.java.net/browse/SKARA-1264)? ------------- PR: https://git.openjdk.java.net/skara/pull/1261 From cstein at openjdk.java.net Tue Dec 14 17:19:26 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Tue, 14 Dec 2021 17:19:26 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 16:59:02 GMT, Guoxiong Li wrote: > Does this patch also solve SKARA-1264? I guess so, yes. The stack trace in that issue reads familiar with what we saw today ... and in other failing pre-submit runs on Mac OS triggered since Mercurial 6.0 is shipped. ------------- PR: https://git.openjdk.java.net/skara/pull/1261 From erikj at openjdk.java.net Tue Dec 14 18:04:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 18:04:34 GMT Subject: RFR: 1283: Test failures with Mercurial 6.0 [v2] In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 17:16:51 GMT, Christian Stein wrote: > > Does this patch also solve SKARA-1264? > > I guess so, yes. The stack trace in that issue reads familiar with what we saw today ... and in other failing pre-submit runs on Mac OS triggered since Mercurial 6.0 is shipped. I'm pretty sure it's the same issue. Same failing test and stacktrace. Closed that bug as duplicate. ------------- PR: https://git.openjdk.java.net/skara/pull/1261 From erikj at openjdk.java.net Tue Dec 14 18:04:34 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 14 Dec 2021 18:04:34 GMT Subject: Integrated: 1283: Test failures with Mercurial 6.0 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 16:09:52 GMT, Erik Joelsson wrote: > Adjust ext.py to handle Mercurial versions 6.0+. This pull request has now been integrated. Changeset: 68394f56 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/68394f56961411ad1454b441341441e3aea3f233 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1283: Test failures with Mercurial 6.0 Reviewed-by: cstein, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1261 From gli at openjdk.java.net Wed Dec 15 12:39:58 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:39:58 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation Message-ID: Hi all, The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: > Description > Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). This patch fixes the bug and revises the code to match the documentation. The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); + if (remainingAdditional > updatedLimits.get(r)) { + // Set the number for the lower roles to remove. + remainingRemovals = remainingAdditional - updatedLimits.get(r); + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. + // Because the '.jcheck/conf' file means the minimal reviewer requirement. + updatedLimits.replace(r, remainingAdditional); + } The other code changes are listed below: - add negative number check. - remove the updated limits check. Because it is not needed after adding the negative number check. - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. - add more test cases. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1288: Adjust the implementation of the 'reviewers' command to match the documentation Changes: https://git.openjdk.java.net/skara/pull/1262/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1262&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1288 Stats: 196 lines in 3 files changed: 169 ins; 7 del; 20 mod Patch: https://git.openjdk.java.net/skara/pull/1262.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1262/head:pull/1262 PR: https://git.openjdk.java.net/skara/pull/1262 From kcr at openjdk.java.net Wed Dec 15 12:46:46 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 15 Dec 2021 12:46:46 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 12:36:24 GMT, Guoxiong Li wrote: > Hi all, > > The `reviewers` command [documentation](https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers) states: > >> Description >> Require that at least N users with given role (defaults to Author) review the pull request before it can be integrated. The requirements are in addition to the ones specified by the .jcheck/conf file. > > But the implementation doesn't match the documentation now, especially the bug reported at [JDK-PULL-6752](https://github.com/openjdk/jdk/pull/6752) ([SKARA-1288](https://bugs.openjdk.java.net/browse/SKARA-1288) also recorded this bug). > > This patch fixes the bug and revises the code to match the documentation. > > The logic has small change(Please see the following code). In the past, the reviewer number of the role will be the sum of the `updatedLimits.get(r)` and `remainingAdditional`. But I don't know it meets our expectation. Because the higher roles can reduce the `remainingAdditional`, I think the remaining number should be only set to `updatedLimits` but not added to `updatedLimits`. This matches the documentation `Require that at least N users with given role (defaults to Author) review the pull request`, especially the key work `at least`. > > > - updatedLimits.replace(r, updatedLimits.get(r) + remainingAdditional); > + if (remainingAdditional > updatedLimits.get(r)) { > + // Set the number for the lower roles to remove. > + remainingRemovals = remainingAdditional - updatedLimits.get(r); > + // The new number of the reviewers should larger or equal than the requirement of the '.jcheck/conf' file. > + // Because the '.jcheck/conf' file means the minimal reviewer requirement. > + updatedLimits.replace(r, remainingAdditional); > + } > > > The other code changes are listed below: > - add negative number check. > - remove the updated limits check. Because it is not needed after adding the negative number check. > - adjust the reply message, always output the concrete reviewers. Because the merged logic of jcheck config and user `reviewers` command is a little hard, we should let the user know the result directly instead of guessing the result. > - `decrease lower roles` in the method `ReviewersTracker#updatedRoleLimits` doesn't work as expected. I fix it. > - add more test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. What problem are you trying to solve? ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From gli at openjdk.java.net Wed Dec 15 12:46:51 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:46:51 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: References: Message-ID: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into SKARA-1275 - Adjust the message. Excluded the 'git-webrev'. - 1275: The unknown sub-command will ouput the unexpected message ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1257/files - new: https://git.openjdk.java.net/skara/pull/1257/files/6e40540d..e72b96dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=01-02 Stats: 35 lines in 13 files changed: 20 ins; 1 del; 14 mod Patch: https://git.openjdk.java.net/skara/pull/1257.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1257/head:pull/1257 PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Wed Dec 15 12:47:14 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:47:14 GMT Subject: RFR: 1258: Add review link/details to comments section [v4] In-Reply-To: References: Message-ID: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li 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 five additional commits since the last revision: - Merge branch 'master' into SKARA-1258 - Fix typo. - Move the code about adding comment out of the reviewLink block. - Not implement the unused method. - 1258: Add review link/details to comments section ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1250/files - new: https://git.openjdk.java.net/skara/pull/1250/files/458dbd27..538891e3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1250&range=02-03 Stats: 338 lines in 17 files changed: 265 ins; 6 del; 67 mod Patch: https://git.openjdk.java.net/skara/pull/1250.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1250/head:pull/1250 PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Wed Dec 15 12:47:50 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:47:50 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v7] In-Reply-To: References: Message-ID: > Hi all, > > This patch adds the large binary file check to the jcheck. > > The corresponding configuration is like the following code. Each key/value in the `[checks "binary"]` is a mapper. The `key` means the file pattern and the `value` means the limited file size. For example, `.*\.bin=200B` means the file which ends with `.bin` should not exceed 200 Bytes. > > > [checks] > error = binary > > [checks "binary"] > .*.bin=200B > .*.o=1k > > > The limited file size can use one of these several units: b(Byte), kb(KiloByte), mb(MegaByte), gb(GigaByte). The units is case insensitive, which means the `Kb`, `kB` and `KB` are equals to `kb(KiloByte)`. If the unit is not provided, it defauts to `b(Byte)`. And these is no a unit called `bit`. > > The corresponding test cases are added. > > Best Regards, > -- Guoxiong Guoxiong Li 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 13 additional commits since the last revision: - Merge branch 'master' into SKARA-1236 - Excluded copied and renamed files. - Excluded renamed and copied files. Use Git commit information. - Fix the output message. - Check the renamed/modified binary file. - Enable the binary check. - Fix copyright. - Polish - Use simple config. Restore BinaryIssue. Only check the newly added or copied files. - Merge branch 'master' into SKARA-1236 - ... and 3 more: https://git.openjdk.java.net/skara/compare/26f49c36...3b4eb2c3 ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1247/files - new: https://git.openjdk.java.net/skara/pull/1247/files/588660cf..3b4eb2c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=06 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1247&range=05-06 Stats: 547 lines in 21 files changed: 346 ins; 76 del; 125 mod Patch: https://git.openjdk.java.net/skara/pull/1247.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1247/head:pull/1247 PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Dec 15 12:54:49 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:54:49 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> Message-ID: On Wed, 15 Dec 2021 12:46:51 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using the unknown command, the client will output the unexpected message. For example: >> >> >> $ git-pr lis 123 >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. >> >> This patch will output more information to the user: >> >> >> $ git-pr lis 123 >> >> Can't find the sub-command 'lis', the default sub-command 'help' will be executed. >> The arguments [lis, 123] will be passed to the default sub-command. >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> The added information can let the user know why the following output is shown. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into SKARA-1275 > - Adjust the message. Excluded the 'git-webrev'. > - 1275: The unknown sub-command will ouput the unexpected message I merged the master branch to re-run the pre-submit tests in macOS, which failed in the past. And ping for review. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Wed Dec 15 12:55:03 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:55:03 GMT Subject: RFR: 1258: Add review link/details to comments section [v4] In-Reply-To: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> References: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> Message-ID: On Wed, 15 Dec 2021 12:47:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li 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 five additional commits since the last revision: > > - Merge branch 'master' into SKARA-1258 > - Fix typo. > - Move the code about adding comment out of the reviewLink block. > - Not implement the unused method. > - 1258: Add review link/details to comments section I merged the master branch to re-run the pre-submit tests in macOS, which failed in the past. And ping for review. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Wed Dec 15 12:55:31 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 12:55:31 GMT Subject: RFR: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> Message-ID: On Wed, 8 Dec 2021 10:28:31 GMT, Guoxiong Li wrote: > Hi all, > > This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. > > I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Could I get your help to sponsor this patch? Thanks a lot. ------------- PR: https://git.openjdk.java.net/skara/pull/1256 From gli at openjdk.java.net Wed Dec 15 13:36:36 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 13:36:36 GMT Subject: Integrated: 713: Rename git/pr-approve to git-pr-review In-Reply-To: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> References: <68BksSrkDc4AUH4Ulfd4yXtQnPH_yD4I2m6K4ITzqOA=.a5dbdb85-eaa7-4fec-b991-03207e210943@github.com> Message-ID: On Wed, 8 Dec 2021 10:28:31 GMT, Guoxiong Li wrote: > Hi all, > > This patch changes the command `git pr approve` to `git pr review` and adds the option `type` to identify the review type `approve`, `request-changes` or `comment`. > > I tested this patch in [PR1](https://github.com/openjdk/skara/pull/1) mistakenly. Apology for the wrong operation. And I can't find the right place to test the `git pr` command now. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 1b06b946 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/1b06b9462f7517c86d19a9bfd5dda90a9681dfcf Stats: 216 lines in 4 files changed: 124 ins; 86 del; 6 mod 713: Rename git/pr-approve to git-pr-review Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1256 From gli at openjdk.java.net Wed Dec 15 14:01:20 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 15 Dec 2021 14:01:20 GMT Subject: RFR: 1274: The help message of the 'git-pr' sub-commamd misses the sub-command name Message-ID: Hi all, This little patch fixes the help message when using the `git-pr` sub-command. For example: Before this patch: $ git-pr list -h usage: git-pr [options] [] // <---- Here miss the `list` // Ignore the following output. After this patch: $ git-pr list -h usage: git-pr list [options] [] // Ignore the following output. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - Fix command 'git-pr review' - Merge branch 'master' into SKARA-1274 - 1274: The help information of the 'git-pr' sub-commamd misses the sub-command name Changes: https://git.openjdk.java.net/skara/pull/1263/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1263&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1274 Stats: 25 lines in 14 files changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.java.net/skara/pull/1263.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1263/head:pull/1263 PR: https://git.openjdk.java.net/skara/pull/1263 From erikj at openjdk.java.net Wed Dec 15 22:11:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 15 Dec 2021 22:11:54 GMT Subject: RFR: 1288: Adjust the implementation of the 'reviewers' command to match the documentation In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 12:44:11 GMT, Kevin Rushforth wrote: > Unless there is a corner case that I haven't hit, the implementation is working as expected now. I will need to look at your proposed change more closely, but I don't see the need to change the existing logic. > > What problem are you trying to solve? In the linked PR, they tried to run `/reviewers 2 reviewer`, which gave a very weird error. At least that part is completely wrong in the current implementation. There isn't really any test coverage for using the command with a role argument. As for the rest, I'm still investigating. The command as implemented does not do what the documentation at https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/reviewers says it's supposed to do, that I definitely agree on. I think one point of confusion is if multiple command invocations should be added together, or just override the previous one, and should the override apply globally or just to the specified role? Before we go any further with an implementation, I think we need to agree on what the desired behavior actually is. The bug comments seems like a good forum for suggesting and commenting on bot behavior. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From erikj at openjdk.java.net Wed Dec 15 22:43:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 15 Dec 2021 22:43:05 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> Message-ID: <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> On Wed, 15 Dec 2021 12:46:51 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using the unknown command, the client will output the unexpected message. For example: >> >> >> $ git-pr lis 123 >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. >> >> This patch will output more information to the user: >> >> >> $ git-pr lis 123 >> >> Can't find the sub-command 'lis', the default sub-command 'help' will be executed. >> The arguments [lis, 123] will be passed to the default sub-command. >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> The added information can let the user know why the following output is shown. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into SKARA-1275 > - Adjust the message. Excluded the 'git-webrev'. > - 1275: The unknown sub-command will ouput the unexpected message args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java line 65: > 63: return () -> p.main(forwardedArgs); > 64: } > 65: if (!"git-webrev".equals(programName) && !"git webrev".equals(programName)) { I was expecting a more elegant solution to this. I would add a property/method on the Command interface that MutliCommandParser can use to check this. Something like Command::defaultCommandExpected. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Wed Dec 15 22:57:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 15 Dec 2021 22:57:08 GMT Subject: RFR: 1258: Add review link/details to comments section [v4] In-Reply-To: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> References: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> Message-ID: On Wed, 15 Dec 2021 12:47:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li 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 five additional commits since the last revision: > > - Merge branch 'master' into SKARA-1258 > - Fix typo. > - Move the code about adding comment out of the reviewLink block. > - Not implement the unused method. > - 1258: Add review link/details to comments section Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Wed Dec 15 23:00:08 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 15 Dec 2021 23:00:08 GMT Subject: RFR: 1274: The help message of the 'git-pr' sub-commamd misses the sub-command name In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 13:57:45 GMT, Guoxiong Li wrote: > Hi all, > > This little patch fixes the help message when using the `git-pr` sub-command. For example: > > Before this patch: > > > $ git-pr list -h > > usage: git-pr [options] [] // <---- Here miss the `list` > // Ignore the following output. > > > After this patch: > > > $ git-pr list -h > usage: git-pr list [options] [] > // Ignore the following output. > > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1263 From gli at openjdk.java.net Thu Dec 16 08:10:21 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 16 Dec 2021 08:10:21 GMT Subject: RFR: 1274: The help message of the 'git-pr' sub-commamd misses the sub-command name In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 22:57:25 GMT, Erik Joelsson wrote: >> Hi all, >> >> This little patch fixes the help message when using the `git-pr` sub-command. For example: >> >> Before this patch: >> >> >> $ git-pr list -h >> >> usage: git-pr [options] [] // <---- Here miss the `list` >> // Ignore the following output. >> >> >> After this patch: >> >> >> $ git-pr list -h >> usage: git-pr list [options] [] >> // Ignore the following output. >> >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for your review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1263 From gli at openjdk.java.net Thu Dec 16 08:11:53 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 16 Dec 2021 08:11:53 GMT Subject: RFR: 1258: Add review link/details to comments section [v2] In-Reply-To: References: Message-ID: <4R9sGMBIQrwJZF-lAz-IC1VyK9PRsykUzRHeh0yx6hk=.2bb947c4-8458-4dbb-9f80-c96e04f7285f@github.com> On Tue, 7 Dec 2021 14:33:52 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - Move the code about adding comment out of the reviewLink block. >> - Not implement the unused method. > > I have given this a lot of thought, and I think I'm ok with your current solution. It's a bit unfortunate to have differently formatted comments for confidential vs non confidential, but it's good enough for now. @erikj79 Thanks for your review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From gli at openjdk.java.net Thu Dec 16 09:11:47 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 16 Dec 2021 09:11:47 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> Message-ID: On Wed, 15 Dec 2021 22:40:24 GMT, Erik Joelsson wrote: > I was expecting a more elegant solution to this. I would add a property/method on the Command interface that MutliCommandParser can use to check this. Something like Command::defaultCommandExpected. Good idea. Should we add it in this patch? Or we should file another issue to implement it? ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Thu Dec 16 13:58:54 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 16 Dec 2021 13:58:54 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> Message-ID: On Thu, 16 Dec 2021 09:09:15 GMT, Guoxiong Li wrote: >> args/src/main/java/org/openjdk/skara/args/MultiCommandParser.java line 65: >> >>> 63: return () -> p.main(forwardedArgs); >>> 64: } >>> 65: if (!"git-webrev".equals(programName) && !"git webrev".equals(programName)) { >> >> I was expecting a more elegant solution to this. I would add a property/method on the Command interface that MutliCommandParser can use to check this. Something like Command::defaultCommandExpected. > >> I was expecting a more elegant solution to this. I would add a property/method on the Command interface that MutliCommandParser can use to check this. Something like Command::defaultCommandExpected. > > Good idea. Should we add it in this patch? Or we should file another issue to implement it? This was meant as a suggestion for this patch. I don't think the current solution is ok to go in. I'm not sure about the name of the new method, it's hard to come up with a good name for this property of a Command. It's trying to express if the default sub-command is expected to be run with arguments or not, or if it takes arguments at all, but putting all that in a method name becomes quite a mouthful. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Thu Dec 16 22:41:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 16 Dec 2021 22:41:04 GMT Subject: RFR: 1291: NPE in org.openjdk.skara.issuetracker.Label.compareTo Message-ID: Recently, we have started seeing NPEs being thrown in org.openjdk.skara.issuetracker.Label::compareTo when called from GitLabMergeRequest::links. This seems to be caused by adding of labels while the GitLabMergeRequest object is active. The labelNameToLabel map is initiated in the constructor based on the repository labels. This may get outdated while the GitLabMergeRequest instance is still alive. This patch makes the initialization of the map lazy by wrapping all calls to the map in a private method. The map is re-initialized any time an element isn't found in it. I also added a filter on null labels before the sorting to avoid the NPE in case it still slips through. ------------- Commit messages: - SKARA-1291 Changes: https://git.openjdk.java.net/skara/pull/1264/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1264&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1291 Stats: 24 lines in 1 file changed: 17 ins; 4 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1264.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1264/head:pull/1264 PR: https://git.openjdk.java.net/skara/pull/1264 From gli at openjdk.java.net Thu Dec 16 22:45:59 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 16 Dec 2021 22:45:59 GMT Subject: Integrated: 1258: Add review link/details to comments section In-Reply-To: References: Message-ID: On Fri, 3 Dec 2021 12:55:03 GMT, Guoxiong Li wrote: > Hi all, > > This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: a8f19d7f Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/a8f19d7fbf746609ddfe83f71aa02b50df4510ce Stats: 134 lines in 9 files changed: 109 ins; 6 del; 19 mod 1258: Add review link/details to comments section Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From cstein at openjdk.java.net Thu Dec 16 22:46:11 2021 From: cstein at openjdk.java.net (Christian Stein) Date: Thu, 16 Dec 2021 22:46:11 GMT Subject: Integrated: build: update to JUnit 5.8.2 In-Reply-To: References: Message-ID: On Tue, 14 Dec 2021 08:24:03 GMT, Christian Stein wrote: > This patch that updates JUnit Jupiter to 5.8.2 and JUnit Platform to 1.8.2. > > PS: The text at https://github.com/openjdk/skara#testing reading "_JUnit 5.6.2 or later is required to run the unit tests._" seems to be out of date. Shouldn't it read like: "A recent version of JUnit 5 is..."? This pull request has now been integrated. Changeset: abe48a5d Author: Christian Stein Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/abe48a5d9a8e7b150ed98eb4f190f0f2918c4aba Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod build: update to JUnit 5.8.2 Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1260 From gli at openjdk.java.net Thu Dec 16 22:47:17 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Thu, 16 Dec 2021 22:47:17 GMT Subject: Integrated: 1274: The help message of the 'git-pr' sub-commamd misses the sub-command name In-Reply-To: References: Message-ID: On Wed, 15 Dec 2021 13:57:45 GMT, Guoxiong Li wrote: > Hi all, > > This little patch fixes the help message when using the `git-pr` sub-command. For example: > > Before this patch: > > > $ git-pr list -h > > usage: git-pr [options] [] // <---- Here miss the `list` > // Ignore the following output. > > > After this patch: > > > $ git-pr list -h > usage: git-pr list [options] [] > // Ignore the following output. > > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 2e9fd5f8 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/2e9fd5f8f46ba742e4d5c8cf4cc45c1741182271 Stats: 25 lines in 14 files changed: 0 ins; 0 del; 25 mod 1274: The help message of the 'git-pr' sub-commamd misses the sub-command name Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1263 From kcr at openjdk.java.net Thu Dec 16 22:51:19 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 16 Dec 2021 22:51:19 GMT Subject: RFR: 1291: NPE in org.openjdk.skara.issuetracker.Label.compareTo In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 22:37:01 GMT, Erik Joelsson wrote: > Recently, we have started seeing NPEs being thrown in org.openjdk.skara.issuetracker.Label::compareTo when called from GitLabMergeRequest::links. This seems to be caused by adding of labels while the GitLabMergeRequest object is active. The labelNameToLabel map is initiated in the constructor based on the repository labels. This may get outdated while the GitLabMergeRequest instance is still alive. > > This patch makes the initialization of the map lazy by wrapping all calls to the map in a private method. The map is re-initialized any time an element isn't found in it. I also added a filter on null labels before the sorting to avoid the NPE in case it still slips through. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1264 From gli at openjdk.java.net Fri Dec 17 07:26:09 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Fri, 17 Dec 2021 07:26:09 GMT Subject: RFR: 1258: Add review link/details to comments section [v4] In-Reply-To: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> References: <0Ugzw88NYb-LWj--hky6d1bC56g3OR1V8C9KvTwq660=.f497daae-8ffb-44b6-b742-3639d9a3eb3f@github.com> Message-ID: On Wed, 15 Dec 2021 12:47:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> This patch adds a comment to the jira issue when the corresponding PR is submitted. Because currently, the class `Issue` has no an api to remove a comment. So I need to create and implement it, too. And the test cases are added. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li 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 five additional commits since the last revision: > > - Merge branch 'master' into SKARA-1258 > - Fix typo. > - Move the code about adding comment out of the reviewLink block. > - Not implement the unused method. > - 1258: Add review link/details to comments section Please notice to set the config `reviewLink` to `false`. ------------- PR: https://git.openjdk.java.net/skara/pull/1250 From erikj at openjdk.java.net Fri Dec 17 22:11:12 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 17 Dec 2021 22:11:12 GMT Subject: RFR: 1292: Empty commit message causes IndexOutOfBoundsException Message-ID: This patch fixes an IndexOutOfBoundsException which occurs when a new repository is configured and it contains commits with an empty message. The message() here represents the commit message as a List with one item for each line. If the message is empty, the list is empty. From what I can tell, returning an empty string in that case should work fine. ------------- Commit messages: - SKARA-1292 Changes: https://git.openjdk.java.net/skara/pull/1265/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1265&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1292 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1265.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1265/head:pull/1265 PR: https://git.openjdk.java.net/skara/pull/1265 From kcr at openjdk.java.net Fri Dec 17 23:25:22 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 17 Dec 2021 23:25:22 GMT Subject: RFR: 1292: Empty commit message causes IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 22:07:03 GMT, Erik Joelsson wrote: > This patch fixes an IndexOutOfBoundsException which occurs when a new repository is configured and it contains commits with an empty message. The message() here represents the commit message as a List with one item for each line. If the message is empty, the list is empty. From what I can tell, returning an empty string in that case should work fine. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1265 From gli at openjdk.java.net Sat Dec 18 14:59:21 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sat, 18 Dec 2021 14:59:21 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> Message-ID: <9i2NOEl7vZKH9ghSqoTTgTdmoqdH6VVO1t6-i_YpGxE=.787e41cd-b365-4217-bb47-a2e4137835b7@github.com> On Thu, 16 Dec 2021 13:55:55 GMT, Erik Joelsson wrote: >>> I was expecting a more elegant solution to this. I would add a property/method on the Command interface that MutliCommandParser can use to check this. Something like Command::defaultCommandExpected. >> >> Good idea. Should we add it in this patch? Or we should file another issue to implement it? > > This was meant as a suggestion for this patch. I don't think the current solution is ok to go in. > > I'm not sure about the name of the new method, it's hard to come up with a good name for this property of a Command. It's trying to express if the default sub-command is expected to be run with arguments or not, or if it takes arguments at all, but putting all that in a method name becomes quite a mouthful. What about `defaultCommandWarningEnabled`? Actually, the default sub-command is always invoked if no sub-command is provided. But the warning message are outputted optionally. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Mon Dec 20 13:33:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Dec 2021 13:33:39 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: <9i2NOEl7vZKH9ghSqoTTgTdmoqdH6VVO1t6-i_YpGxE=.787e41cd-b365-4217-bb47-a2e4137835b7@github.com> References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> <9i2NOEl7vZKH9ghSqoTTgTdmoqdH6VVO1t6-i_YpGxE=.787e41cd-b365-4217-bb47-a2e4137835b7@github.com> Message-ID: On Sat, 18 Dec 2021 14:56:43 GMT, Guoxiong Li wrote: >> This was meant as a suggestion for this patch. I don't think the current solution is ok to go in. >> >> I'm not sure about the name of the new method, it's hard to come up with a good name for this property of a Command. It's trying to express if the default sub-command is expected to be run with arguments or not, or if it takes arguments at all, but putting all that in a method name becomes quite a mouthful. > > What about `defaultCommandWarningEnabled`? Actually, the default sub-command is always invoked if no sub-command is provided. But the warning message are outputted optionally. Works for me. Thanks. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Mon Dec 20 14:02:59 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 20 Dec 2021 14:02:59 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v4] In-Reply-To: References: Message-ID: <8WOQ0GmqWt4Qdese9yM1DqQIYdj0Ne9gWjvtWjzbwUc=.bfe565a4-a712-44ba-bcc6-4e46a4e75c87@github.com> > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Guoxiong Li 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 five additional commits since the last revision: - Add parameter 'defaultCommandWarningEnabled' - Merge branch 'master' of github.com:openjdk/skara into SKARA-1275 - Merge branch 'master' into SKARA-1275 - Adjust the message. Excluded the 'git-webrev'. - 1275: The unknown sub-command will ouput the unexpected message ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1257/files - new: https://git.openjdk.java.net/skara/pull/1257/files/e72b96dd..a2ed3be8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1257&range=02-03 Stats: 388 lines in 30 files changed: 235 ins; 92 del; 61 mod Patch: https://git.openjdk.java.net/skara/pull/1257.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1257/head:pull/1257 PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Mon Dec 20 14:02:59 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 20 Dec 2021 14:02:59 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v3] In-Reply-To: References: <__v3FNyq0cEinBv5-BB0UwUppkUe8csu83wPVngZfFw=.29e448e8-9db4-4d8c-aed7-6c82d05025b6@github.com> <1t1S4eQ_O8Pm1h-4EP-C2HhmzM_HCWHuHx4YQnIQiic=.0ad4b10d-fead-4d70-b921-6a09dcb44245@github.com> <9i2NOEl7vZKH9ghSqoTTgTdmoqdH6VVO1t6-i_YpGxE=.787e41cd-b365-4217-bb47-a2e4137835b7@github.com> Message-ID: On Mon, 20 Dec 2021 13:30:54 GMT, Erik Joelsson wrote: >> What about `defaultCommandWarningEnabled`? Actually, the default sub-command is always invoked if no sub-command is provided. But the warning message are outputted optionally. > > Works for me. Thanks. I updated the code just now by using the property `defaultCommandWarningEnabled`. ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Mon Dec 20 14:07:11 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Dec 2021 14:07:11 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message [v4] In-Reply-To: <8WOQ0GmqWt4Qdese9yM1DqQIYdj0Ne9gWjvtWjzbwUc=.bfe565a4-a712-44ba-bcc6-4e46a4e75c87@github.com> References: <8WOQ0GmqWt4Qdese9yM1DqQIYdj0Ne9gWjvtWjzbwUc=.bfe565a4-a712-44ba-bcc6-4e46a4e75c87@github.com> Message-ID: <28oydNhx0i6RMr_nFYDivGIWR-Q0xWK0rxZPS8dfThU=.3f114a31-2167-4916-9630-5948e0c0226e@github.com> On Mon, 20 Dec 2021 14:02:59 GMT, Guoxiong Li wrote: >> Hi all, >> >> When using the unknown command, the client will output the unexpected message. For example: >> >> >> $ git-pr lis 123 >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. >> >> This patch will output more information to the user: >> >> >> $ git-pr lis 123 >> >> Can't find the sub-command 'lis', the default sub-command 'help' will be executed. >> The arguments [lis, 123] will be passed to the default sub-command. >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> The added information can let the user know why the following output is shown. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li 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 five additional commits since the last revision: > > - Add parameter 'defaultCommandWarningEnabled' > - Merge branch 'master' of github.com:openjdk/skara into SKARA-1275 > - Merge branch 'master' into SKARA-1275 > - Adjust the message. Excluded the 'git-webrev'. > - 1275: The unknown sub-command will ouput the unexpected message Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Mon Dec 20 14:12:05 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 20 Dec 2021 14:12:05 GMT Subject: RFR: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: On Thu, 9 Dec 2021 14:37:56 GMT, Erik Joelsson wrote: >> Hi all, >> >> When using the unknown command, the client will output the unexpected message. For example: >> >> >> $ git-pr lis 123 >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. >> >> This patch will output more information to the user: >> >> >> $ git-pr lis 123 >> >> Can't find the sub-command 'lis', the default sub-command 'help' will be executed. >> The arguments [lis, 123] will be passed to the default sub-command. >> >> error: unexpected input: 123 >> usage: git-pr [options] [] >> -h, --help Show help >> --verbose Turn on verbose output >> --debug Turn on debugging output >> --version Print the version of this tool >> >> >> The added information can let the user know why the following output is shown. >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > I like the last suggestion much better, but I still don't think it should be printed for `git webrev`. Running webrev without a sub-command is normal procedure and should not result in a warning. @erikj79 Thanks for your review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From gli at openjdk.java.net Mon Dec 20 14:17:05 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 20 Dec 2021 14:17:05 GMT Subject: Integrated: 1275: An unknown sub-command gives a confusing error message In-Reply-To: References: Message-ID: On Wed, 8 Dec 2021 14:17:51 GMT, Guoxiong Li wrote: > Hi all, > > When using the unknown command, the client will output the unexpected message. For example: > > > $ git-pr lis 123 > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > When the client can't identify the sub-command `git-pr lis`, it will execute the default command `git-pr help` and will pass `lis 123` as the argument to the `git-pr help` command. And the `git-pr help` can resolve only one argument, which is `lis` in this example, so it would output `error: unexpected input: 123`. > > This patch will output more information to the user: > > > $ git-pr lis 123 > > Can't find the sub-command 'lis', the default sub-command 'help' will be executed. > The arguments [lis, 123] will be passed to the default sub-command. > > error: unexpected input: 123 > usage: git-pr [options] [] > -h, --help Show help > --verbose Turn on verbose output > --debug Turn on debugging output > --version Print the version of this tool > > > The added information can let the user know why the following output is shown. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 649dd3cf Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/649dd3cf73e2feed6ba330966f3d6108e56585f5 Stats: 14 lines in 4 files changed: 7 ins; 0 del; 7 mod 1275: An unknown sub-command gives a confusing error message Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1257 From erikj at openjdk.java.net Mon Dec 20 17:57:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Dec 2021 17:57:28 GMT Subject: Integrated: 1292: Empty commit message causes IndexOutOfBoundsException In-Reply-To: References: Message-ID: On Fri, 17 Dec 2021 22:07:03 GMT, Erik Joelsson wrote: > This patch fixes an IndexOutOfBoundsException which occurs when a new repository is configured and it contains commits with an empty message. The message() here represents the commit message as a List with one item for each line. If the message is empty, the list is empty. From what I can tell, returning an empty string in that case should work fine. This pull request has now been integrated. Changeset: f95f606e Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f95f606e226ded17e39dcd21028eed789156f8d4 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1292: Empty commit message causes IndexOutOfBoundsException Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1265 From erikj at openjdk.java.net Mon Dec 20 22:47:59 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 20 Dec 2021 22:47:59 GMT Subject: Integrated: 1291: NPE in org.openjdk.skara.issuetracker.Label.compareTo In-Reply-To: References: Message-ID: On Thu, 16 Dec 2021 22:37:01 GMT, Erik Joelsson wrote: > Recently, we have started seeing NPEs being thrown in org.openjdk.skara.issuetracker.Label::compareTo when called from GitLabMergeRequest::links. This seems to be caused by adding of labels while the GitLabMergeRequest object is active. The labelNameToLabel map is initiated in the constructor based on the repository labels. This may get outdated while the GitLabMergeRequest instance is still alive. > > This patch makes the initialization of the map lazy by wrapping all calls to the map in a private method. The map is re-initialized any time an element isn't found in it. I also added a filter on null labels before the sorting to avoid the NPE in case it still slips through. This pull request has now been integrated. Changeset: 87d9845d Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/87d9845dc1c5ff957836c4ff42392602d523b587 Stats: 24 lines in 1 file changed: 17 ins; 4 del; 3 mod 1291: NPE in org.openjdk.skara.issuetracker.Label.compareTo Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1264 From gli at openjdk.java.net Wed Dec 22 12:02:41 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 22 Dec 2021 12:02:41 GMT Subject: RFR: 1293: The Skara bot should not add review links or comments to CSR issues Message-ID: Hi all, Currently, the review link and comment will be added to the CSR issue because the method `PullRequestWorkItem::parseIssues` get the all the issues from the PR body. This patch excludes the CSR issue and adds a corresponding test case. And the method `IssueNotifier::pullRequestToTextBrief` creates the following comment body in the jira, because the method `println` prints the line seperator according to the bot server OS. But it seems that the jira can't identify this line seperator. So I adjust this method bu using the class `StringBuilder` instead of `PrintWriter`. A pull request was submitted for review. URL: https://git.openjdk.java.net/jfx/pull/548 Date: 2021-06-28 12:13:44 +0000 Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - Fix copyright. - 1293: The Skara bot should not add review links or comments to CSR issues Changes: https://git.openjdk.java.net/skara/pull/1266/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1266&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1293 Stats: 70 lines in 3 files changed: 62 ins; 1 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1266.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1266/head:pull/1266 PR: https://git.openjdk.java.net/skara/pull/1266 From erikj at openjdk.java.net Wed Dec 22 13:55:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 22 Dec 2021 13:55:50 GMT Subject: RFR: 1293: The Skara bot should not add review links or comments to CSR issues In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 11:58:53 GMT, Guoxiong Li wrote: > Hi all, > > Currently, the review link and comment will be added to the CSR issue because the method `PullRequestWorkItem::parseIssues` get the all the issues from the PR body. This patch excludes the CSR issue and adds a corresponding test case. > > And the method `IssueNotifier::pullRequestToTextBrief` creates the following comment body in the jira, because the method `println` prints the line seperator according to the bot server OS. But it seems that the jira can't identify this line seperator. So I adjust this method bu using the class `StringBuilder` instead of `PrintWriter`. > > > A pull request was submitted for review. > > URL: https://git.openjdk.java.net/jfx/pull/548 Date: 2021-06-28 12:13:44 +0000 > > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1266 From gli at openjdk.java.net Wed Dec 22 14:04:32 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 22 Dec 2021 14:04:32 GMT Subject: RFR: 1293: The Skara bot should not add review links or comments to CSR issues In-Reply-To: References: Message-ID: On Wed, 22 Dec 2021 13:53:03 GMT, Erik Joelsson wrote: >> Hi all, >> >> Currently, the review link and comment will be added to the CSR issue because the method `PullRequestWorkItem::parseIssues` get the all the issues from the PR body. This patch excludes the CSR issue and adds a corresponding test case. >> >> And the method `IssueNotifier::pullRequestToTextBrief` creates the following comment body in the jira, because the method `println` prints the line seperator according to the bot server OS. But it seems that the jira can't identify this line seperator. So I adjust this method bu using the class `StringBuilder` instead of `PrintWriter`. >> >> >> A pull request was submitted for review. >> >> URL: https://git.openjdk.java.net/jfx/pull/548 Date: 2021-06-28 12:13:44 +0000 >> >> >> Thanks for taking the time to review. >> >> Best Regards, >> -- Guoxiong > > Marked as reviewed by erikj (Lead). @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1266 From gli at openjdk.java.net Wed Dec 22 14:08:53 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 22 Dec 2021 14:08:53 GMT Subject: Integrated: 1293: The Skara bot should not add review links or comments to CSR issues In-Reply-To: References: Message-ID: <44LaZCkzGOCv052Xy4gFfmUSeCca6doDvOgENCY5AgY=.71ca7d4a-b2b0-402e-9ac2-8daad406e90b@github.com> On Wed, 22 Dec 2021 11:58:53 GMT, Guoxiong Li wrote: > Hi all, > > Currently, the review link and comment will be added to the CSR issue because the method `PullRequestWorkItem::parseIssues` get the all the issues from the PR body. This patch excludes the CSR issue and adds a corresponding test case. > > And the method `IssueNotifier::pullRequestToTextBrief` creates the following comment body in the jira, because the method `println` prints the line seperator according to the bot server OS. But it seems that the jira can't identify this line seperator. So I adjust this method bu using the class `StringBuilder` instead of `PrintWriter`. > > > A pull request was submitted for review. > > URL: https://git.openjdk.java.net/jfx/pull/548 Date: 2021-06-28 12:13:44 +0000 > > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 56bdc6ee Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/56bdc6eefd2ce9be686efa7b231611a83503032e Stats: 70 lines in 3 files changed: 62 ins; 1 del; 7 mod 1293: The Skara bot should not add review links or comments to CSR issues Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1266 From erikj at openjdk.java.net Wed Dec 22 19:25:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 22 Dec 2021 19:25:27 GMT Subject: RFR: 1296: ArchiveWorkItem throws repeated exceptions after force push to PR Message-ID: The mlbridge bot sometimes fails handling of force-pushed changes to a PR. This patch tries to fix this. When the previous head hash of a PR has been replaced with a force push, that hash will not automatically be present in the local repository that the bot uses to generate diffs. Sometimes it will be present if the bot happens to execute in the same scratch area as where the PR was processed before. Before this patch, the code assumes that the previous hash is present in the local repo. I'm attacking this from two sides. I'm adding a method that tries to pull in the missing hash if needed. This may or may not succeed depending on if the server allows pulling of arbitrary hashes or not (my local git does not, but I believe github does). It can also fail if the hash has been GCd on the server. If the hash is, or has been made present in the local repo, we can proceed as before. If getting the hash was unsuccessful, I'm changing the email message to explain that incremental views of the changes are unavailable, and we only try to produce the full webrev. To test this properly, I tried to adapt an existing test. However, while working with that test, I discovered that it wasn't really doing what (at least I) expected it to do. As I explained in a bug comment, TestCredentials::getHostedRepository, will return HostedRepository objects with the same backing Git repository in all of them. This was causing weird and unexpected behavior as changes for the main PR repo as well as the webrev and mail archive repos all ended up jumbled in the same repository, making it impossible to actually control the setup for the test. To handle this I added the ability to create multiple named repositories for a TestHost, and use it in the two tests affected by this change. I also found two other tests that relied on there only being one repo per TestHost (and fixed them). I believe a followup is necessary to try to fix the remaining tests for at least mlbridge as I suspect more of them are likely to have issues. I added caching of the supplier results in ArchiveItem. The suppliers here are potentially calling out to remote URLs as well as running multiple git commands to generate the body and footer. I noticed that at least the body() method was called twice, so figured it would be good to only make these costly operations once. ------------- Commit messages: - SKARA-1296 Changes: https://git.openjdk.java.net/skara/pull/1267/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1267&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1296 Stats: 235 lines in 6 files changed: 188 ins; 5 del; 42 mod Patch: https://git.openjdk.java.net/skara/pull/1267.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1267/head:pull/1267 PR: https://git.openjdk.java.net/skara/pull/1267 From erikj at openjdk.java.net Thu Dec 23 22:27:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 23 Dec 2021 22:27:19 GMT Subject: RFR: 1295: CSRBot throws intermittent exception when looking up JiraIssue links Message-ID: This patch adds another retry condition for rest requests. When a rest call uses authentication but fails with 401 "unauthorized", we need to give it at least one more try. The authentication mechanism for JBS works with time limited tokens that sometimes need to be renewed. This can only be detected through failing with 401. On the retry, the dynamic authorization provider (authGen.getAuthHeaders()) will get to run again and will detect the stale token. I'm currently running with this patch live for the affected bot and so far it's looking good, but I will leave it running a while more to make sure. ------------- Commit messages: - Update RestRequest.java - Better retry - Add logging on retry - Retry on failed authorization. Tidy up logging. - Adding logging when JiraProject::issue fails - Add info to exception to better understand when things go wrong Changes: https://git.openjdk.java.net/skara/pull/1268/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1268&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1295 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1268.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1268/head:pull/1268 PR: https://git.openjdk.java.net/skara/pull/1268 From gli at openjdk.java.net Sun Dec 26 11:25:32 2021 From: gli at openjdk.java.net (Guoxiong Li) Date: Sun, 26 Dec 2021 11:25:32 GMT Subject: RFR: 1298: IssueNotifier removes and re-adds review links and comments Message-ID: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> Hi all, When the author of the PR modified the PR body, the Github will store the PR body by using its internal line separator instead of `\n`. The method `parseIssues` can't identify the line separator so that it can't find any issue. This patch enhances the pattern to let it identify the `\r` as well and the corresponding test case is added. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - 1298: IssueNotifier removes and re-adds review links and comments Changes: https://git.openjdk.java.net/skara/pull/1269/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1269&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1298 Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1269.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1269/head:pull/1269 PR: https://git.openjdk.java.net/skara/pull/1269