From gli at openjdk.java.net Tue Feb 8 08:29:05 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 08:29:05 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR Message-ID: Hi all, The contributor command uses the static domain `openjdk.org` which causes this issue. This patch uses the domain of the configuration instead of the static `openjdk.org`, changes the default domain to `openjdk.org` and adjusts the test cases. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - Change default domain. - SKARA-1340: Correct email domain not always used when adding a contributor to a PR Changes: https://git.openjdk.java.net/skara/pull/1281/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1281&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1340 Stats: 8 lines in 3 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1281.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1281/head:pull/1281 PR: https://git.openjdk.java.net/skara/pull/1281 From gli at openjdk.java.net Tue Feb 8 08:33:07 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 08:33:07 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: > Hi all, > > The contributor command uses the static domain `openjdk.org` which causes this issue. This patch uses the domain of the configuration instead of the static `openjdk.org` and adjusts the test cases. > > 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: Revert the default domain. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1281/files - new: https://git.openjdk.java.net/skara/pull/1281/files/c9535904..8dda44e6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1281&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1281&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1281.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1281/head:pull/1281 PR: https://git.openjdk.java.net/skara/pull/1281 From gli at openjdk.java.net Tue Feb 8 08:35:27 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 08:35:27 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR In-Reply-To: References: Message-ID: <3EyhJCL-wfk6bLhpMNYvT6oCrFygrm5rTNuiZW1MBA0=.8afb37fc-32b9-4a55-a610-d42e871d0994@github.com> On Tue, 8 Feb 2022 08:25:24 GMT, Guoxiong Li wrote: > Hi all, > > The contributor command uses the static domain `openjdk.org` which causes this issue. This patch uses the domain of the configuration instead of the static `openjdk.org` and adjusts the test cases. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I have changed the default domain to `openjdk.org` but reverted it. We need more discussion before changing it. ------------- PR: https://git.openjdk.java.net/skara/pull/1281 From gli at openjdk.java.net Tue Feb 8 12:06:53 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 12:06:53 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored Message-ID: Hi all, If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1333: Sponsor label only removed if PR is actually sponsored Changes: https://git.openjdk.java.net/skara/pull/1282/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1282&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1333 Stats: 100 lines in 3 files changed: 96 ins; 1 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1282.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1282/head:pull/1282 PR: https://git.openjdk.java.net/skara/pull/1282 From gli at openjdk.java.net Tue Feb 8 12:23:50 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 12:23:50 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: <4jmx1wOI5p2Z84CD-MozvOU68SZpH-gDb2O6afNoEtU=.5f80217d-2243-4ff0-aee1-a6fc7afea4d3@github.com> On Wed, 1 Dec 2021 14:19:41 GMT, Erik Joelsson wrote: > 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. I don't think this patch would be integrated in short time. So I advice that we can use another patch to enable the existing binary check firstly, which is a bug in the past. @erikj79 What's your opinion? ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Tue Feb 8 12:24:57 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Tue, 8 Feb 2022 12:24:57 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 Keep the patch alive. And waiting for comments in the issue or this PR. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From erikj at openjdk.java.net Tue Feb 8 14:22:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Feb 2022 14:22:52 GMT Subject: RFR: SKARA-1340: Correct email domain not always used when adding a contributor to a PR [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 08:33:07 GMT, Guoxiong Li wrote: >> Hi all, >> >> The contributor command uses the static domain `openjdk.org` which causes this issue. This patch uses the domain of the configuration instead of the static `openjdk.org` and adjusts the test cases. >> >> 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: > > Revert the default domain. I don't know what the correct solution for this is without thoroughly investigating the known cases where the current behavior was wrong. Unfortunately those are Oracle internal cases, so I can't share any details. ------------- PR: https://git.openjdk.java.net/skara/pull/1281 From erikj at openjdk.java.net Tue Feb 8 14:37:06 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Feb 2022 14:37:06 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 12:03:16 GMT, Guoxiong Li wrote: > Hi all, > > If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Looks good, just some language nits in comments. bots/pr/src/main/java/org/openjdk/skara/bots/pr/SponsorCommand.java line 139: > 137: } > 138: > 139: // This method only has one statement now, but it is kept intentionally to meet the change in the future. I don't think we need a comment for this. To me it still makes sense to keep this method. bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1471: > 1469: assertEquals(0, notPushed); > 1470: > 1471: // Mark the PR author as committer Suggestion: // Mark the PR author a committer bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1477: > 1475: var committerBot = PullRequestBot.newBuilder().repo(botUser).censusRepo(committerCensusBuilder.build()).build(); > 1476: > 1477: // Issue an integrate command with being a Committer Suggestion: // Issue an integrate command while being a Committer ------------- PR: https://git.openjdk.java.net/skara/pull/1282 From erikj at openjdk.java.net Tue Feb 8 14:44:28 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Feb 2022 14: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 16:51:45 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. > >> > 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. > I don't think this patch would be integrated in short time. So I advice that we can use another patch to enable the existing binary check firstly, which is a bug in the past. @erikj79 What's your opinion? I agree that it's better to change PullRequestCheckIssueVisitor to react to the existing binary check in a separate change. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Feb 9 02:13:14 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 02:13:14 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored [v2] In-Reply-To: References: Message-ID: > Hi all, > > If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. > > 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 comments. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1282/files - new: https://git.openjdk.java.net/skara/pull/1282/files/7b578dda..a9667998 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1282&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1282&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1282.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1282/head:pull/1282 PR: https://git.openjdk.java.net/skara/pull/1282 From gli at openjdk.java.net Wed Feb 9 02:13:15 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 02:13:15 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored [v2] In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 14:34:31 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments. > > Looks good, just some language nits in comments. @erikj79 Thanks for the suggestion. I fixed the comments. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/SponsorCommand.java line 139: > >> 137: } >> 138: >> 139: // This method only has one statement now, but it is kept intentionally to meet the change in the future. > > I don't think we need a comment for this. To me it still makes sense to keep this method. Fixed. > bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1471: > >> 1469: assertEquals(0, notPushed); >> 1470: >> 1471: // Mark the PR author as committer > > Suggestion: > > // Mark the PR author a committer Fixed. > bots/pr/src/test/java/org/openjdk/skara/bots/pr/IntegrateTests.java line 1477: > >> 1475: var committerBot = PullRequestBot.newBuilder().repo(botUser).censusRepo(committerCensusBuilder.build()).build(); >> 1476: >> 1477: // Issue an integrate command with being a Committer > > Suggestion: > > // Issue an integrate command while being a Committer Fixed. ------------- PR: https://git.openjdk.java.net/skara/pull/1282 From erikj at openjdk.java.net Wed Feb 9 13:50:04 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 13:50:04 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored [v2] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 02:13:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. >> >> 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 comments. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1282 From gli at openjdk.java.net Wed Feb 9 13:54:26 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 13:54:26 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored [v2] In-Reply-To: References: Message-ID: <-PdJRcHFobGzaNfLYdUTR4EpSfYpWjSENVlnjcyhXf4=.661b1a6f-00c2-4965-a839-06bc7b37ed43@github.com> On Wed, 9 Feb 2022 13:47:26 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comments. > > 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/1282 From gli at openjdk.java.net Wed Feb 9 14:03:00 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 14:03:00 GMT Subject: RFR: 1236: Add jcheck option to check for large binary files [v7] In-Reply-To: References: Message-ID: <4Fc8FugqHzF1BpjqGicOsQwwtTzgYgYeuZSQGnqygts=.341bcb8a-818d-4bae-bc78-1e6c73ac6039@github.com> On Wed, 15 Dec 2021 12:47:50 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 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/07c16c0f...3b4eb2c3 I filed [SKARA-1347](https://bugs.openjdk.java.net/browse/SKARA-1347) to follow up. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From gli at openjdk.java.net Wed Feb 9 14:19:40 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 14:19:40 GMT Subject: RFR: SKARA-1347: Enable binary check Message-ID: Hi all, The binary check was not effective in the past. This patch fixes it to enable binary check. Thanks for taking the time to reivew. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1347: Enable binary check Changes: https://git.openjdk.java.net/skara/pull/1283/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1283&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1347 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1283.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1283/head:pull/1283 PR: https://git.openjdk.java.net/skara/pull/1283 From erikj at openjdk.java.net Wed Feb 9 14:30:30 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 14:30:30 GMT Subject: RFR: SKARA-1333: Sponsor label only removed if PR is actually sponsored [v2] In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 02:13:14 GMT, Guoxiong Li wrote: >> Hi all, >> >> If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. >> >> 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 comments. Yes, but you need to issue the integrate command first. ------------- PR: https://git.openjdk.java.net/skara/pull/1282 From gli at openjdk.java.net Wed Feb 9 14:42:13 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 14:42:13 GMT Subject: Integrated: SKARA-1333: Sponsor label only removed if PR is actually sponsored In-Reply-To: References: Message-ID: On Tue, 8 Feb 2022 12:03:16 GMT, Guoxiong Li wrote: > Hi all, > > If an author types `/integrate` command, the `sponsor` label is added. When the author becomes the committer and types the command `/integrate` again, the `sponsor` label doesn't been removed. It is good to remove the label `sponsor`, too, just like the labels `rfr` and `ready`. This patch fixes it and adds a test case. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 4df4afb8 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/4df4afb8f85b5a4ebb7d2dec7482b56836c56046 Stats: 99 lines in 3 files changed: 95 ins; 1 del; 3 mod 1333: Sponsor label only removed if PR is actually sponsored Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1282 From erikj at openjdk.java.net Wed Feb 9 15:14:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 15:14:56 GMT Subject: RFR: SKARA-1347: Enable binary check In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 14:15:49 GMT, Guoxiong Li wrote: > Hi all, > > The binary check was not effective in the past. This patch fixes it to enable binary check. > Thanks for taking the time to reivew. > > Best Regards, > -- Guoxiong bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCheckIssueVisitor.java line 266: > 264: @Override > 265: public void visit(BinaryIssue issue) { > 266: addFailureMessage(issue.check(), "The binary file " + issue.path().toString() + " is not allowed in this repository."); Can you make the message match the ones for executable files and symbolic links above? ------------- PR: https://git.openjdk.java.net/skara/pull/1283 From gli at openjdk.java.net Wed Feb 9 15:22:32 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 15:22:32 GMT Subject: RFR: SKARA-1347: Enable binary check In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 15:11:47 GMT, Erik Joelsson wrote: >> Hi all, >> >> The binary check was not effective in the past. This patch fixes it to enable binary check. >> Thanks for taking the time to reivew. >> >> Best Regards, >> -- Guoxiong > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCheckIssueVisitor.java line 266: > >> 264: @Override >> 265: public void visit(BinaryIssue issue) { >> 266: addFailureMessage(issue.check(), "The binary file " + issue.path().toString() + " is not allowed in this repository."); > > Can you make the message match the ones for executable files and symbolic links above? What about `String.format("Binary files are not allowed (file: %s)", issue.path())`? ------------- PR: https://git.openjdk.java.net/skara/pull/1283 From erikj at openjdk.java.net Wed Feb 9 15:30:48 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 15:30:48 GMT Subject: RFR: SKARA-1347: Enable binary check In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 15:19:59 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCheckIssueVisitor.java line 266: >> >>> 264: @Override >>> 265: public void visit(BinaryIssue issue) { >>> 266: addFailureMessage(issue.check(), "The binary file " + issue.path().toString() + " is not allowed in this repository."); >> >> Can you make the message match the ones for executable files and symbolic links above? > > What about `String.format("Binary files are not allowed (file: %s)", issue.path())`? Looks good. ------------- PR: https://git.openjdk.java.net/skara/pull/1283 From gli at openjdk.java.net Wed Feb 9 15:33:40 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 15:33:40 GMT Subject: RFR: SKARA-1347: Enable binary check [v2] In-Reply-To: References: Message-ID: <-2KWjLM3kbUqEHvzw9TlIrjoqgqQE6Xe68kJ5GCi6s8=.443235e1-141d-4519-9955-4208c931c676@github.com> > Hi all, > > The binary check was not effective in the past. This patch fixes it to enable binary check. > Thanks for taking the time to reivew. > > Best Regards, > -- Guoxiong Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: Fix message. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1283/files - new: https://git.openjdk.java.net/skara/pull/1283/files/e8c9f477..15879bc5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1283&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1283&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1283.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1283/head:pull/1283 PR: https://git.openjdk.java.net/skara/pull/1283 From erikj at openjdk.java.net Wed Feb 9 15:43:27 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 15:43:27 GMT Subject: RFR: SKARA-1347: Enable binary check [v2] In-Reply-To: <-2KWjLM3kbUqEHvzw9TlIrjoqgqQE6Xe68kJ5GCi6s8=.443235e1-141d-4519-9955-4208c931c676@github.com> References: <-2KWjLM3kbUqEHvzw9TlIrjoqgqQE6Xe68kJ5GCi6s8=.443235e1-141d-4519-9955-4208c931c676@github.com> Message-ID: On Wed, 9 Feb 2022 15:33:40 GMT, Guoxiong Li wrote: >> Hi all, >> >> The binary check was not effective in the past. This patch fixes it to enable binary check. >> Thanks for taking the time to reivew. >> >> Best Regards, >> -- Guoxiong > > Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: > > Fix message. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1283 From gli at openjdk.java.net Wed Feb 9 15:43:27 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 15:43:27 GMT Subject: RFR: SKARA-1347: Enable binary check [v2] In-Reply-To: References: <-2KWjLM3kbUqEHvzw9TlIrjoqgqQE6Xe68kJ5GCi6s8=.443235e1-141d-4519-9955-4208c931c676@github.com> Message-ID: <9x-ci_BCgptxtLu04IfDjeTXfCji5Hnyt59Bu4l4qkk=.6f8f430c-f1c7-48e4-a0b4-cd259657cbf4@github.com> On Wed, 9 Feb 2022 15:38:01 GMT, Erik Joelsson wrote: >> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix 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/1283 From gli at openjdk.java.net Wed Feb 9 15:57:13 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Wed, 9 Feb 2022 15:57:13 GMT Subject: Integrated: SKARA-1347: Enable binary check In-Reply-To: References: Message-ID: On Wed, 9 Feb 2022 14:15:49 GMT, Guoxiong Li wrote: > Hi all, > > The binary check was not effective in the past. This patch fixes it to enable binary check. > Thanks for taking the time to reivew. > > Best Regards, > -- Guoxiong This pull request has now been integrated. Changeset: 54ac640e Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/54ac640e5e25912bca57fdec095779f898f29289 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 1347: Enable binary check Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1283 From erikj at openjdk.java.net Wed Feb 9 17:42:24 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Feb 2022 17:42:24 GMT Subject: RFR: 1345: sync-bot removing hgupdate-sync label from 8u5 backport Message-ID: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> This patch fixes an issue in the synclabel bot. For update releases of 8 and 7, we have special ranges of build numbers that are used for special releases. These need to be, and are, handled separately in the synclabel bot. These ranges only apply to update releases however, and not the main feature releases, where the actual build numbers used went well into these ranges. Added a test that mimics the example mislabeled set of bugs. ------------- Commit messages: - SKARA-1345 Changes: https://git.openjdk.java.net/skara/pull/1284/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1284&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1345 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1284.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1284/head:pull/1284 PR: https://git.openjdk.java.net/skara/pull/1284 From kcr at openjdk.java.net Thu Feb 10 01:51:16 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 10 Feb 2022 01:51:16 GMT Subject: RFR: 1345: sync-bot removing hgupdate-sync label from 8u5 backport In-Reply-To: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> References: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> Message-ID: On Wed, 9 Feb 2022 17:38:30 GMT, Erik Joelsson wrote: > This patch fixes an issue in the synclabel bot. For update releases of 8 and 7, we have special ranges of build numbers that are used for special releases. These need to be, and are, handled separately in the synclabel bot. These ranges only apply to update releases however, and not the main feature releases, where the actual build numbers used went well into these ranges. > > Added a test that mimics the example mislabeled set of bugs. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1284 From ihse at openjdk.java.net Thu Feb 10 16:15:54 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 10 Feb 2022 16:15:54 GMT Subject: RFR: 1345: sync-bot removing hgupdate-sync label from 8u5 backport In-Reply-To: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> References: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> Message-ID: On Wed, 9 Feb 2022 17:38:30 GMT, Erik Joelsson wrote: > This patch fixes an issue in the synclabel bot. For update releases of 8 and 7, we have special ranges of build numbers that are used for special releases. These need to be, and are, handled separately in the synclabel bot. These ranges only apply to update releases however, and not the main feature releases, where the actual build numbers used went well into these ranges. > > Added a test that mimics the example mislabeled set of bugs. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1284 From erikj at openjdk.java.net Thu Feb 10 19:31:36 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 10 Feb 2022 19:31:36 GMT Subject: Integrated: 1345: sync-bot removing hgupdate-sync label from 8u5 backport In-Reply-To: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> References: <-1s7_Zi8oYK0gDGCwd-yYXT0MeNiRW5RV7bVrcrDR9k=.7b06dbfa-eb95-43d3-a8a9-7d158e8147bb@github.com> Message-ID: On Wed, 9 Feb 2022 17:38:30 GMT, Erik Joelsson wrote: > This patch fixes an issue in the synclabel bot. For update releases of 8 and 7, we have special ranges of build numbers that are used for special releases. These need to be, and are, handled separately in the synclabel bot. These ranges only apply to update releases however, and not the main feature releases, where the actual build numbers used went well into these ranges. > > Added a test that mimics the example mislabeled set of bugs. This pull request has now been integrated. Changeset: e7a5c307 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/e7a5c30777a1f9d4d0f55c66a2f66e6aa8d8fe73 Stats: 15 lines in 2 files changed: 14 ins; 0 del; 1 mod 1345: sync-bot removing hgupdate-sync label from 8u5 backport Reviewed-by: kcr, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1284 From erikj at openjdk.java.net Mon Feb 14 22:47:55 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 14 Feb 2022 22:47:55 GMT Subject: RFR: 1344: Support notifications operating on a repository mirror Message-ID: We would like to move some NotifierBot configurations to operate off of a mirror of a repo instead of the original repo. In order to support this I would like to add these two new configuration options in the issue notifier: 1. "originalrepository": Setting this implies that the repo the notifier is operating on is a mirror, and this original repo should be used for any links generated in notifications. 2. "repoonly": Similar to the existing "pronly", this limits what kind of notifications the notifier acts on. This is needed to be able to separate the PR event based notifications from the repo event based notifications. PRs aren't mirrored so those can't be moved to operate from the mirror. When implementing repoonly, I also changed the NotifyBot to only return WorkItems for either pr or repo if there are actually listeners registered for them respectively. This caused some seemingly unrelated tests to fail, as they were relying on the side effect of running the RepositoryWorkItem with nothing to do. To combat this, I've introduced a mock NullRepositoryListener for these tests. ------------- Commit messages: - Merge branch 'master' into SKARA-1344-notify-on-mirror - Add new test and fix some existing ones - Implementation Changes: https://git.openjdk.java.net/skara/pull/1285/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1285&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1344 Stats: 156 lines in 7 files changed: 128 ins; 5 del; 23 mod Patch: https://git.openjdk.java.net/skara/pull/1285.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1285/head:pull/1285 PR: https://git.openjdk.java.net/skara/pull/1285 From ihse at openjdk.java.net Tue Feb 15 11:07:50 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 15 Feb 2022 11:07:50 GMT Subject: RFR: 1344: Support notifications operating on a repository mirror In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 22:43:45 GMT, Erik Joelsson wrote: > We would like to move some NotifierBot configurations to operate off of a mirror of a repo instead of the original repo. In order to support this I would like to add these two new configuration options in the issue notifier: > > 1. "originalrepository": Setting this implies that the repo the notifier is operating on is a mirror, and this original repo should be used for any links generated in notifications. > 2. "repoonly": Similar to the existing "pronly", this limits what kind of notifications the notifier acts on. This is needed to be able to separate the PR event based notifications from the repo event based notifications. PRs aren't mirrored so those can't be moved to operate from the mirror. > > When implementing repoonly, I also changed the NotifyBot to only return WorkItems for either pr or repo if there are actually listeners registered for them respectively. This caused some seemingly unrelated tests to fail, as they were relying on the side effect of running the RepositoryWorkItem with nothing to do. To combat this, I've introduced a mock NullRepositoryListener for these tests. LGTM ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1285 From kcr at openjdk.java.net Tue Feb 15 13:02:17 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Feb 2022 13:02:17 GMT Subject: RFR: 1344: Support notifications operating on a repository mirror In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 22:43:45 GMT, Erik Joelsson wrote: > We would like to move some NotifierBot configurations to operate off of a mirror of a repo instead of the original repo. In order to support this I would like to add these two new configuration options in the issue notifier: > > 1. "originalrepository": Setting this implies that the repo the notifier is operating on is a mirror, and this original repo should be used for any links generated in notifications. > 2. "repoonly": Similar to the existing "pronly", this limits what kind of notifications the notifier acts on. This is needed to be able to separate the PR event based notifications from the repo event based notifications. PRs aren't mirrored so those can't be moved to operate from the mirror. > > When implementing repoonly, I also changed the NotifyBot to only return WorkItems for either pr or repo if there are actually listeners registered for them respectively. This caused some seemingly unrelated tests to fail, as they were relying on the side effect of running the RepositoryWorkItem with nothing to do. To combat this, I've introduced a mock NullRepositoryListener for these tests. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1285 From erikj at openjdk.java.net Tue Feb 15 15:58:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Feb 2022 15:58:20 GMT Subject: Integrated: 1344: Support notifications operating on a repository mirror In-Reply-To: References: Message-ID: On Mon, 14 Feb 2022 22:43:45 GMT, Erik Joelsson wrote: > We would like to move some NotifierBot configurations to operate off of a mirror of a repo instead of the original repo. In order to support this I would like to add these two new configuration options in the issue notifier: > > 1. "originalrepository": Setting this implies that the repo the notifier is operating on is a mirror, and this original repo should be used for any links generated in notifications. > 2. "repoonly": Similar to the existing "pronly", this limits what kind of notifications the notifier acts on. This is needed to be able to separate the PR event based notifications from the repo event based notifications. PRs aren't mirrored so those can't be moved to operate from the mirror. > > When implementing repoonly, I also changed the NotifyBot to only return WorkItems for either pr or repo if there are actually listeners registered for them respectively. This caused some seemingly unrelated tests to fail, as they were relying on the side effect of running the RepositoryWorkItem with nothing to do. To combat this, I've introduced a mock NullRepositoryListener for these tests. This pull request has now been integrated. Changeset: 5dbc91be Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/5dbc91be892ddf178a77749b3f1232f43b83d0c3 Stats: 156 lines in 7 files changed: 128 ins; 5 del; 23 mod 1344: Support notifications operating on a repository mirror Reviewed-by: ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1285 From erikj at openjdk.java.net Tue Feb 15 18:44:06 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Feb 2022 18:44:06 GMT Subject: RFR: 1350: Altfixversions isn't checking Backport resolution Message-ID: This patch fixes a flaw in the altfixversion feature. Currently a backport with an altfixversion is considered valid if the state is "resolved". There are two problems with this. It misses backports that are in state closed. It could also cause false positives by accepting backports that aren't set to resolution "Fixed". To fix this, I've introduced a new method on the Issue interface "isFixed()". The default implementation (which will get used in testing) just delegates to isResolved(). For JiraIssue, it checks both the state and the resolution. ------------- Commit messages: - SKARA-1350 Changes: https://git.openjdk.java.net/skara/pull/1286/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1286&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1350 Stats: 28 lines in 3 files changed: 24 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1286.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1286/head:pull/1286 PR: https://git.openjdk.java.net/skara/pull/1286 From kcr at openjdk.java.net Tue Feb 15 20:43:04 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Feb 2022 20:43:04 GMT Subject: RFR: 1350: Altfixversions isn't checking Backport resolution In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 18:39:56 GMT, Erik Joelsson wrote: > This patch fixes a flaw in the altfixversion feature. Currently a backport with an altfixversion is considered valid if the state is "resolved". There are two problems with this. It misses backports that are in state closed. It could also cause false positives by accepting backports that aren't set to resolution "Fixed". > > To fix this, I've introduced a new method on the Issue interface "isFixed()". The default implementation (which will get used in testing) just delegates to isResolved(). For JiraIssue, it checks both the state and the resolution. Looks good. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 190: > 188: @Override > 189: public boolean isFixed() { > 190: if (isResolved() || isClosed()) { This test might not be needed -- the resolution will be empty or null for unresolved issues. I don't see any harm in leaving it if you prefer to have the extra check. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1286 From erikj at openjdk.java.net Wed Feb 16 15:27:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Feb 2022 15:27:56 GMT Subject: RFR: 1350: Altfixversions isn't checking Backport resolution In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 20:40:07 GMT, Kevin Rushforth wrote: >> This patch fixes a flaw in the altfixversion feature. Currently a backport with an altfixversion is considered valid if the state is "resolved". There are two problems with this. It misses backports that are in state closed. It could also cause false positives by accepting backports that aren't set to resolution "Fixed". >> >> To fix this, I've introduced a new method on the Issue interface "isFixed()". The default implementation (which will get used in testing) just delegates to isResolved(). For JiraIssue, it checks both the state and the resolution. > > issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 190: > >> 188: @Override >> 189: public boolean isFixed() { >> 190: if (isResolved() || isClosed()) { > > This test might not be needed -- the resolution will be empty or null for unresolved issues. I don't see any harm in leaving it if you prefer to have the extra check. I agree that JBS should guarantee this to be true. I went back and forth on this myself, but in the end I think it's clearer like this. ------------- PR: https://git.openjdk.java.net/skara/pull/1286 From erikj at openjdk.java.net Wed Feb 16 15:27:56 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Feb 2022 15:27:56 GMT Subject: Integrated: 1350: Altfixversions isn't checking Backport resolution In-Reply-To: References: Message-ID: On Tue, 15 Feb 2022 18:39:56 GMT, Erik Joelsson wrote: > This patch fixes a flaw in the altfixversion feature. Currently a backport with an altfixversion is considered valid if the state is "resolved". There are two problems with this. It misses backports that are in state closed. It could also cause false positives by accepting backports that aren't set to resolution "Fixed". > > To fix this, I've introduced a new method on the Issue interface "isFixed()". The default implementation (which will get used in testing) just delegates to isResolved(). For JiraIssue, it checks both the state and the resolution. This pull request has now been integrated. Changeset: 9ec7de68 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/9ec7de689d747c894d3c762e0c31f77dd69b44ae Stats: 28 lines in 3 files changed: 24 ins; 0 del; 4 mod 1350: Altfixversions isn't checking Backport resolution Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1286 From erikj at openjdk.java.net Wed Feb 16 21:20:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Feb 2022 21:20:21 GMT Subject: RFR: 1352: Configure GithubHost as offline Message-ID: As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. ------------- Commit messages: - SKARA-1352 Changes: https://git.openjdk.java.net/skara/pull/1287/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1287&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1352 Stats: 30 lines in 5 files changed: 22 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1287.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1287/head:pull/1287 PR: https://git.openjdk.java.net/skara/pull/1287 From ihse at openjdk.java.net Thu Feb 17 13:25:19 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Feb 2022 13:25:19 GMT Subject: RFR: 1352: Configure GithubHost as offline In-Reply-To: References: Message-ID: On Wed, 16 Feb 2022 21:16:18 GMT, Erik Joelsson wrote: > As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. > > Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. > > I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. LGTM, barring the null casting part. :) forge/src/main/java/org/openjdk/skara/forge/Forge.java line 62: > 60: > 61: static Forge from(String name, URI uri) { > 62: return from(name, uri, (Credential) null); Not entirely sure I like this. Maybe "from" has been overloaded too much? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1287 From ihse at openjdk.java.net Thu Feb 17 13:25:20 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Feb 2022 13:25:20 GMT Subject: RFR: 1352: Configure GithubHost as offline In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 13:19:44 GMT, Magnus Ihse Bursie wrote: >> As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. >> >> Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. >> >> I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. > > forge/src/main/java/org/openjdk/skara/forge/Forge.java line 62: > >> 60: >> 61: static Forge from(String name, URI uri) { >> 62: return from(name, uri, (Credential) null); > > Not entirely sure I like this. Maybe "from" has been overloaded too much? Or you could return `from(name, uri, null, null)`, could you not? Anything but casting null... ------------- PR: https://git.openjdk.java.net/skara/pull/1287 From erikj at openjdk.java.net Thu Feb 17 14:28:22 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Feb 2022 14:28:22 GMT Subject: RFR: 1352: Configure GithubHost as offline [v2] In-Reply-To: References: Message-ID: <1H8I_1rXCsd5G1i4RY_Aoq3vvdzZiFxXj_Z6-adHqfQ=.24729f86-d894-4e6e-8bb5-46fec0768e90@github.com> > As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. > > Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. > > I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Remove null cast ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1287/files - new: https://git.openjdk.java.net/skara/pull/1287/files/cd0dcd8f..3be90724 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1287&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1287&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1287.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1287/head:pull/1287 PR: https://git.openjdk.java.net/skara/pull/1287 From ihse at openjdk.java.net Thu Feb 17 14:51:02 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Feb 2022 14:51:02 GMT Subject: RFR: 1352: Configure GithubHost as offline [v2] In-Reply-To: <1H8I_1rXCsd5G1i4RY_Aoq3vvdzZiFxXj_Z6-adHqfQ=.24729f86-d894-4e6e-8bb5-46fec0768e90@github.com> References: <1H8I_1rXCsd5G1i4RY_Aoq3vvdzZiFxXj_Z6-adHqfQ=.24729f86-d894-4e6e-8bb5-46fec0768e90@github.com> Message-ID: On Thu, 17 Feb 2022 14:28:22 GMT, Erik Joelsson wrote: >> As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. >> >> Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. >> >> I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Remove null cast Much better, thank you! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1287 From erikj at openjdk.java.net Thu Feb 17 18:48:05 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Feb 2022 18:48:05 GMT Subject: Integrated: 1352: Configure GithubHost as offline In-Reply-To: References: Message-ID: <3bjsvvqKGULzkACUothKvpn_TyWDhq1w5LJD8YgyiHI=.96733592-725b-482c-a16b-e2ee33914223@github.com> On Wed, 16 Feb 2022 21:16:18 GMT, Erik Joelsson wrote: > As a followup to [SKARA-1344](https://bugs.openjdk.java.net/browse/SKARA-1344), to better support the notifier to act through a mirror, we need another configuration option. When configuring a forge for the "originalrepository" option, we need to make it possible to not need to make any remote calls to that forge. > > Currently, when Skara creates a HostedRepository from a forge, it will always make a call to validate and initiate things. At least for GithubRepositories, this call isn't strictly necessary (and one could argue that it should be possible to get around this for Gitlab as well). Most callers for Forge::repository do expect this validation however, so we do not want to change the default behavior. > > I propose adding a new configure parameter to github forge, "offline", which defaults to false. If set to true, then it indicates that this forge is expected to be offline and the caller is not expected to try to perform any remote operations. This concept could certainly be expanded, but for now, the only thing we explicitly need to prevent is that validation/initialization when creating a repository. I would rather not spend more time implementing a more complete feature that is unlikely to be used. This pull request has now been integrated. Changeset: 858beedb Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/858beedb0aff2d9832c8484089026bd4a6025c22 Stats: 30 lines in 5 files changed: 22 ins; 0 del; 8 mod 1352: Configure GithubHost as offline Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1287 From erikj at openjdk.java.net Thu Feb 17 21:21:50 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Feb 2022 21:21:50 GMT Subject: RFR: 1356: Notifer option to only interact with PRs Message-ID: The "pronly" option was introduced in [SKARA-445](https://bugs.openjdk.java.net/browse/SKARA-445) with the intention of support running just a PR based IssueNotifier, which includes resolving issues when a PR is integrated. We need to run an IssueNotifier without it trying to resolve issues and without reacting to repo events. To support this, I've introduced a new config parameter on IssueNotifier: "resolve". Since we only need this when pronly is true, I didn't bother implementing support for that case and instead added a validation check in the factory so we don't accidentally try to run with an unsupported configuration. ------------- Commit messages: - Adjusted patch - SKARA-1356 Changes: https://git.openjdk.java.net/skara/pull/1288/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1288&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1356 Stats: 28 lines in 3 files changed: 25 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1288.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1288/head:pull/1288 PR: https://git.openjdk.java.net/skara/pull/1288 From ihse at openjdk.java.net Thu Feb 17 21:24:14 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 17 Feb 2022 21:24:14 GMT Subject: RFR: 1356: Notifer option to only interact with PRs In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:17:47 GMT, Erik Joelsson wrote: > The "pronly" option was introduced in [SKARA-445](https://bugs.openjdk.java.net/browse/SKARA-445) with the intention of support running just a PR based IssueNotifier, which includes resolving issues when a PR is integrated. > > We need to run an IssueNotifier without it trying to resolve issues and without reacting to repo events. To support this, I've introduced a new config parameter on IssueNotifier: "resolve". Since we only need this when pronly is true, I didn't bother implementing support for that case and instead added a validation check in the factory so we don't accidentally try to run with an unsupported configuration. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1288 From kcr at openjdk.java.net Thu Feb 17 21:28:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Feb 2022 21:28:33 GMT Subject: RFR: 1356: Notifer option to only interact with PRs In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:17:47 GMT, Erik Joelsson wrote: > The "pronly" option was introduced in [SKARA-445](https://bugs.openjdk.java.net/browse/SKARA-445) with the intention of support running just a PR based IssueNotifier, which includes resolving issues when a PR is integrated. > > We need to run an IssueNotifier without it trying to resolve issues and without reacting to repo events. To support this, I've introduced a new config parameter on IssueNotifier: "resolve". Since we only need this when pronly is true, I didn't bother implementing support for that case and instead added a validation check in the factory so we don't accidentally try to run with an unsupported configuration. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1288 From erikj at openjdk.java.net Thu Feb 17 21:42:29 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Feb 2022 21:42:29 GMT Subject: Integrated: 1356: Notifer option to only interact with PRs In-Reply-To: References: Message-ID: On Thu, 17 Feb 2022 21:17:47 GMT, Erik Joelsson wrote: > The "pronly" option was introduced in [SKARA-445](https://bugs.openjdk.java.net/browse/SKARA-445) with the intention of support running just a PR based IssueNotifier, which includes resolving issues when a PR is integrated. > > We need to run an IssueNotifier without it trying to resolve issues and without reacting to repo events. To support this, I've introduced a new config parameter on IssueNotifier: "resolve". Since we only need this when pronly is true, I didn't bother implementing support for that case and instead added a validation check in the factory so we don't accidentally try to run with an unsupported configuration. This pull request has now been integrated. Changeset: ba76661c Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/ba76661c850ba8e0d4c5e87fbfcee560c4ea93bb Stats: 29 lines in 3 files changed: 26 ins; 0 del; 3 mod 1356: Notifer option to only interact with PRs Reviewed-by: ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1288 From erikj at openjdk.java.net Thu Feb 17 21:42:29 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Feb 2022 21:42:29 GMT Subject: RFR: 1356: Notifer option to only interact with PRs [v2] In-Reply-To: References: Message-ID: > The "pronly" option was introduced in [SKARA-445](https://bugs.openjdk.java.net/browse/SKARA-445) with the intention of support running just a PR based IssueNotifier, which includes resolving issues when a PR is integrated. > > We need to run an IssueNotifier without it trying to resolve issues and without reacting to repo events. To support this, I've introduced a new config parameter on IssueNotifier: "resolve". Since we only need this when pronly is true, I didn't bother implementing support for that case and instead added a validation check in the factory so we don't accidentally try to run with an unsupported configuration. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Corrected comment ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1288/files - new: https://git.openjdk.java.net/skara/pull/1288/files/f795c61f..d3c48cca Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1288&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1288&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1288.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1288/head:pull/1288 PR: https://git.openjdk.java.net/skara/pull/1288 From Matthew.Carter at microsoft.com Fri Feb 18 20:00:38 2022 From: Matthew.Carter at microsoft.com (Mat Carter) Date: Fri, 18 Feb 2022 20:00:38 +0000 Subject: Github issues with jdk18u PR pipeline Message-ID: I have an PR to backprot to 18u [1] However the jchecks failed twice First the test step failed to copy the build artifacts [2] Second attempt failed to build due to server issues [3] Any help appreciated as I'm trying to get this backported from tip -> 18u -> 17u-dev in tiem for 17.0.3 (rampdown is March 1st) [1]?https://github.com/openjdk/jdk18u/pull/29 [2]?https://github.com/macarte/jdk18u/actions/runs/1859839007 [3]?https://github.com/openjdk/jdk18u/pull/29/runs/5252599136 Sent from Outlook From david.holmes at oracle.com Sun Feb 20 21:45:49 2022 From: david.holmes at oracle.com (David Holmes) Date: Mon, 21 Feb 2022 07:45:49 +1000 Subject: Github issues with jdk18u PR pipeline In-Reply-To: References: Message-ID: <0b419976-a4ff-4eb1-4953-86f382e76140@oracle.com> Hi Mat, On 19/02/2022 6:00 am, Mat Carter wrote: > I have an PR to backprot to 18u [1] > > However the jchecks failed twice Not jcheck, these are the GitHub Actions (GHA). > First the test step failed to copy the build artifacts [2] > > Second attempt failed to build due to server issues [3] The "server" issue is a transient compiler issue we sometimes see in builds, and typically indicates the some problem on the build host at the time. If there is no build then pre-submit job for the tests will naturally fail to be able to download the build. > Any help appreciated as I'm trying to get this backported from tip -> 18u -> 17u-dev in tiem for 17.0.3 (rampdown is March 1st) Although the GHA have not run (you can manually re-trigger) the backport is marked as clean and ready so can be pushed. Cheers, David > [1]?https://github.com/openjdk/jdk18u/pull/29 > [2]?https://github.com/macarte/jdk18u/actions/runs/1859839007 > [3]?https://github.com/openjdk/jdk18u/pull/29/runs/5252599136 > > > > Sent from Outlook From ihse at openjdk.java.net Mon Feb 21 11:51:49 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 21 Feb 2022 11:51:49 GMT Subject: RFR: 1360: SKARA-1352 is missing null check Message-ID: The recent fix for [SKARA-1352](https://bugs.openjdk.java.net/browse/SKARA-1352) ("Configure GithubHost as offline") is missing a null check for the configuration object. ------------- Commit messages: - 1360: SKARA-1352 is missing null check Changes: https://git.openjdk.java.net/skara/pull/1289/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1289&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1360 Stats: 26 lines in 1 file changed: 12 ins; 9 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1289.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1289/head:pull/1289 PR: https://git.openjdk.java.net/skara/pull/1289 From aph-open at littlepinkcloud.com Tue Feb 22 13:21:41 2022 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 22 Feb 2022 13:21:41 +0000 Subject: Merge changeset messages going to aarch64-port-dev list Message-ID: Can we stop the flow of these now, please? They're swamping everything so people don't use the list for discussion. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erikj at openjdk.java.net Tue Feb 22 13:54:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Feb 2022 13:54:20 GMT Subject: RFR: 1360: SKARA-1352 is missing null check In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 11:47:49 GMT, Magnus Ihse Bursie wrote: > The recent fix for [SKARA-1352](https://bugs.openjdk.java.net/browse/SKARA-1352) ("Configure GithubHost as offline") is missing a null check for the configuration object. Oops, thanks for catching and fixing this! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1289 From ihse at openjdk.java.net Tue Feb 22 14:10:24 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Feb 2022 14:10:24 GMT Subject: Integrated: 1360: SKARA-1352 is missing null check In-Reply-To: References: Message-ID: On Mon, 21 Feb 2022 11:47:49 GMT, Magnus Ihse Bursie wrote: > The recent fix for [SKARA-1352](https://bugs.openjdk.java.net/browse/SKARA-1352) ("Configure GithubHost as offline") is missing a null check for the configuration object. This pull request has now been integrated. Changeset: 9359c95e Author: Magnus Ihse Bursie URL: https://git.openjdk.java.net/skara/commit/9359c95eb0e6d4339a3a3b6b991d182dc336f311 Stats: 26 lines in 1 file changed: 12 ins; 9 del; 5 mod 1360: SKARA-1352 is missing null check Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1289 From erik.joelsson at oracle.com Tue Feb 22 15:28:05 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 22 Feb 2022 07:28:05 -0800 Subject: Merge changeset messages going to aarch64-port-dev list In-Reply-To: References: Message-ID: I have disabled commit notifications on the master branch for the aarch64-port repo. That branch is currently configured to be a direct mirror of the jdk repo master branch, so I agree that there is no point notifying the changes going there. /Erik On 2022-02-22 05:21, Andrew Haley wrote: > Can we stop the flow of these now, please? They're swamping > everything so people don't use the list for discussion. > From kcr at openjdk.java.net Tue Feb 22 19:56:08 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Feb 2022 19:56:08 GMT Subject: RFR: SKARA-1362: PR suggestion for fixing username is wrong Message-ID: The Skara PR bot warns when the Author name in the git commit doesn't match the preferred name in the GitHub profile. The recommended fix that the bot adds as a PR comment is wrong. This PR fixes the message. ------------- Commit messages: - SKARA-1362: PR suggestion for fixing username is wrong Changes: https://git.openjdk.java.net/skara/pull/1290/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1290&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1362 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1290.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1290/head:pull/1290 PR: https://git.openjdk.java.net/skara/pull/1290 From kcr at openjdk.java.net Tue Feb 22 20:04:05 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 22 Feb 2022 20:04:05 GMT Subject: RFR: SKARA-1362: PR suggestion for fixing username is wrong In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 19:52:20 GMT, Kevin Rushforth wrote: > The Skara PR bot warns when the Author name in the git commit doesn't match the preferred name in the GitHub profile. The recommended fix that the bot adds as a PR comment is wrong. > > This PR fixes the message. As noted in the JBS issue, the Skara PR bot warns about the mismatch and suggests pushing a new commit to correct it, using the following commands: $ git checkout BRANCHNAME $ git commit -c user.name='Preferred Full Name' --allow-empty -m 'Update full name' $ git push The `git commit` command is wrong and produces an error: fatal: Option -m cannot be combined with -c/-C/-F. Removing the '-m' option makes it succeed, but does so by amending the existing commit (thus requiring a force-push), rather than by adding a new one. This PR proposes using a command that works, and adds a new commit: $ git commit --author='Preferred Full Name ' --allow-empty -m 'Update full name' ------------- PR: https://git.openjdk.java.net/skara/pull/1290 From erikj at openjdk.java.net Tue Feb 22 20:34:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Feb 2022 20:34:54 GMT Subject: RFR: SKARA-1362: PR suggestion for fixing username is wrong In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 19:52:20 GMT, Kevin Rushforth wrote: > The Skara PR bot warns when the Author name in the git commit doesn't match the preferred name in the GitHub profile. The recommended fix that the bot adds as a PR comment is wrong. > > This PR fixes the message. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.java.net/skara/pull/1290 From ihse at openjdk.java.net Wed Feb 23 12:43:30 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Wed, 23 Feb 2022 12:43:30 GMT Subject: RFR: SKARA-1362: PR suggestion for fixing username is wrong In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 19:52:20 GMT, Kevin Rushforth wrote: > The Skara PR bot warns when the Author name in the git commit doesn't match the preferred name in the GitHub profile. The recommended fix that the bot adds as a PR comment is wrong. > > This PR fixes the message. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1290 From kcr at openjdk.java.net Wed Feb 23 14:22:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 23 Feb 2022 14:22:38 GMT Subject: Integrated: SKARA-1362: PR suggestion for fixing username is wrong In-Reply-To: References: Message-ID: On Tue, 22 Feb 2022 19:52:20 GMT, Kevin Rushforth wrote: > The Skara PR bot warns when the Author name in the git commit doesn't match the preferred name in the GitHub profile. The recommended fix that the bot adds as a PR comment is wrong. > > This PR fixes the message. This pull request has now been integrated. Changeset: 2c1f1477 Author: Kevin Rushforth URL: https://git.openjdk.java.net/skara/commit/2c1f14771e006a7db48c669bc0e90961643bf1fd Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1362: PR suggestion for fixing username is wrong Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1290 From erikj at openjdk.java.net Thu Feb 24 19:34:50 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Feb 2022 19:34:50 GMT Subject: RFR: 1363: update-sync incorrect sync label Message-ID: In SKARA-964, we fixed the labelsync bot to only consider "Fixed" issues when calculating label assignment. That fix only considered the backport issues and not the main bug. This fix tries to address this by applying the check for isFixed to the main bug as well. While working on this, I also decided to refactor Backports a bit and remove the isFixed method from that class and instead use the newly introduced Issue::isFixed. ------------- Commit messages: - Fix comment - SKARA-1363 Changes: https://git.openjdk.java.net/skara/pull/1291/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1291&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1363 Stats: 83 lines in 4 files changed: 55 ins; 20 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1291.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1291/head:pull/1291 PR: https://git.openjdk.java.net/skara/pull/1291 From kcr at openjdk.java.net Thu Feb 24 19:53:55 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Feb 2022 19:53:55 GMT Subject: RFR: 1363: update-sync incorrect sync label In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 19:30:34 GMT, Erik Joelsson wrote: > In SKARA-964, we fixed the labelsync bot to only consider "Fixed" issues when calculating label assignment. That fix only considered the backport issues and not the main bug. This fix tries to address this by applying the check for isFixed to the main bug as well. > > While working on this, I also decided to refactor Backports a bit and remove the isFixed method from that class and instead use the newly introduced Issue::isFixed. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1291 From erikj at openjdk.java.net Thu Feb 24 22:16:51 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Feb 2022 22:16:51 GMT Subject: RFR: Log warning on wrapped UncheckedRestExceptions Message-ID: In SKARA-1063, I introduced UncheckedRestException in order to avoid logging for errors that are very likely transient, and that are tracked with metrics as well. In some cases, specifically when running Jcheck in a bot, we end up wrapping that exception in a RuntimeException, which in turn causes us to log an error instead of warning. This patch tries to fix this by also checking nested exceptions in when catching RuntimeException in the BotRunner. ------------- Commit messages: - Log warning on wrapped UncheckedRestExceptions Changes: https://git.openjdk.java.net/skara/pull/1292/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1292&range=00 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1292.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1292/head:pull/1292 PR: https://git.openjdk.java.net/skara/pull/1292 From erikj at openjdk.java.net Fri Feb 25 15:38:43 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 25 Feb 2022 15:38:43 GMT Subject: Integrated: 1363: update-sync incorrect sync label In-Reply-To: References: Message-ID: <2EPb0wlV3z6NwEhTA3Zaazvu_BXVIb33ALCMOfhxoN0=.9a3525db-f402-4893-b854-eddedf64dd3a@github.com> On Thu, 24 Feb 2022 19:30:34 GMT, Erik Joelsson wrote: > In SKARA-964, we fixed the labelsync bot to only consider "Fixed" issues when calculating label assignment. That fix only considered the backport issues and not the main bug. This fix tries to address this by applying the check for isFixed to the main bug as well. > > While working on this, I also decided to refactor Backports a bit and remove the isFixed method from that class and instead use the newly introduced Issue::isFixed. This pull request has now been integrated. Changeset: e2cc3cd9 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/e2cc3cd96d19e93445f1e97202dfa25a07158e94 Stats: 83 lines in 4 files changed: 55 ins; 20 del; 8 mod 1363: update-sync incorrect sync label Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1291 From ihse at openjdk.java.net Mon Feb 28 11:29:44 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 28 Feb 2022 11:29:44 GMT Subject: RFR: Log warning on wrapped UncheckedRestException In-Reply-To: References: Message-ID: <0j6e5JhnwCCPMfU_LzBwPslMsnRARbtnbhZNlbQuA5w=.db4456b1-fadc-48e4-9293-75ea32040e30@github.com> On Thu, 24 Feb 2022 22:12:46 GMT, Erik Joelsson wrote: > In SKARA-1063, I introduced UncheckedRestException in order to avoid logging for errors that are very likely transient, and that are tracked with metrics as well. In some cases, specifically when running Jcheck in a bot, we end up wrapping that exception in a RuntimeException, which in turn causes us to log an error instead of warning. > > This patch tries to fix this by also checking nested exceptions in when catching RuntimeException in the BotRunner. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1292 From kcr at openjdk.java.net Mon Feb 28 13:39:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 28 Feb 2022 13:39:41 GMT Subject: RFR: Log warning on wrapped UncheckedRestException In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 22:12:46 GMT, Erik Joelsson wrote: > In SKARA-1063, I introduced UncheckedRestException in order to avoid logging for errors that are very likely transient, and that are tracked with metrics as well. In some cases, specifically when running Jcheck in a bot, we end up wrapping that exception in a RuntimeException, which in turn causes us to log an error instead of warning. > > This patch tries to fix this by also checking nested exceptions in when catching RuntimeException in the BotRunner. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1292 From erikj at openjdk.java.net Mon Feb 28 14:41:02 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 28 Feb 2022 14:41:02 GMT Subject: Integrated: Log warning on wrapped UncheckedRestException In-Reply-To: References: Message-ID: On Thu, 24 Feb 2022 22:12:46 GMT, Erik Joelsson wrote: > In SKARA-1063, I introduced UncheckedRestException in order to avoid logging for errors that are very likely transient, and that are tracked with metrics as well. In some cases, specifically when running Jcheck in a bot, we end up wrapping that exception in a RuntimeException, which in turn causes us to log an error instead of warning. > > This patch tries to fix this by also checking nested exceptions in when catching RuntimeException in the BotRunner. This pull request has now been integrated. Changeset: b97f76f4 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/b97f76f4621406b331950fb672ebbe15f636139a Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Log warning on wrapped UncheckedRestException Reviewed-by: ihse, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1292