From erikj at openjdk.java.net Mon Jan 3 14:07:40 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 14:07:40 GMT Subject: RFR: 1295: CSRBot throws intermittent exception when looking up JiraIssue links In-Reply-To: References: Message-ID: <63eBeCcJXRh51fY3sf6IgwUfjIKLHwCRiOnJ3cNNcZk=.31f0dfa6-d1fd-427c-aa39-d3ace3e2f14a@github.com> On Thu, 23 Dec 2021 22:23:23 GMT, Erik Joelsson wrote: > 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. I still see failures. Please ignore this review for now. ------------- PR: https://git.openjdk.java.net/skara/pull/1268 From erikj at openjdk.java.net Mon Jan 3 14:42:49 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 14:42:49 GMT Subject: RFR: 1298: IssueNotifier removes and re-adds review links and comments In-Reply-To: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> References: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> Message-ID: On Sun, 26 Dec 2021 11:21:47 GMT, Guoxiong Li wrote: > 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 Nice find! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1269 From gli at openjdk.java.net Mon Jan 3 14:47:32 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 3 Jan 2022 14:47:32 GMT Subject: RFR: 1298: IssueNotifier removes and re-adds review links and comments In-Reply-To: References: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> Message-ID: On Mon, 3 Jan 2022 14:40:18 GMT, Erik Joelsson wrote: >> 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 > > Nice find! @erikj79 Thanks for the review. Could I get your help to sponsor this patch? ------------- PR: https://git.openjdk.java.net/skara/pull/1269 From gli at openjdk.java.net Mon Jan 3 14:57:16 2022 From: gli at openjdk.java.net (Guoxiong Li) Date: Mon, 3 Jan 2022 14:57:16 GMT Subject: Integrated: 1298: IssueNotifier removes and re-adds review links and comments In-Reply-To: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> References: <-56WPSNz-5iVsV6eT03OZHdrvjx_NCNyV4NW5DfgjRc=.ca5d1993-22ae-49ed-9e51-375f6c66f9c4@github.com> Message-ID: On Sun, 26 Dec 2021 11:21:47 GMT, Guoxiong Li wrote: > 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 This pull request has now been integrated. Changeset: 8aab2a59 Author: Guoxiong Li Committer: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/8aab2a590929de7d98c8bd1e8c6cf12e40cb6433 Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod 1298: IssueNotifier removes and re-adds review links and comments Reviewed-by: erikj ------------- PR: https://git.openjdk.java.net/skara/pull/1269 From erikj at openjdk.java.net Mon Jan 3 18:32:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 18:32:54 GMT Subject: RFR: 1295: CSRBot throws intermittent exception when looking up JiraIssue links [v2] In-Reply-To: References: 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. Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'SKARA-1295-csr-exception' of https://github.com/erikj79/skara into SKARA-1295-csr-exception - Overwrite old auth headers on retry ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1268/files - new: https://git.openjdk.java.net/skara/pull/1268/files/625e5254..fc65fe36 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1268&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1268&range=00-01 Stats: 29 lines in 1 file changed: 22 ins; 3 del; 4 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 erikj at openjdk.java.net Mon Jan 3 21:03:10 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 21:03:10 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 Message-ID: While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: * Created String constants for the special custom fields we have in JBS. * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. ------------- Commit messages: - Refactor out common functionality - SKARA-1146 Changes: https://git.openjdk.java.net/skara/pull/1270/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1270&range=00 Stats: 110 lines in 10 files changed: 38 ins; 26 del; 46 mod Patch: https://git.openjdk.java.net/skara/pull/1270.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1270/head:pull/1270 PR: https://git.openjdk.java.net/skara/pull/1270 From erikj at openjdk.java.net Mon Jan 3 21:25:37 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 21:25:37 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags Message-ID: The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. ------------- Depends on: https://git.openjdk.java.net/skara/pull/1270 Commit messages: - Require branch fixVersion and backport fixVersion to match to update resolved in build Changes: https://git.openjdk.java.net/skara/pull/1271/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1271&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1146 Stats: 28 lines in 3 files changed: 15 ins; 3 del; 10 mod Patch: https://git.openjdk.java.net/skara/pull/1271.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1271/head:pull/1271 PR: https://git.openjdk.java.net/skara/pull/1271 From erikj at openjdk.java.net Mon Jan 3 21:52:10 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 3 Jan 2022 21:52:10 GMT Subject: RFR: 1295: CSRBot throws intermittent exception when looking up JiraIssue links [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 18:32:54 GMT, Erik Joelsson wrote: >> 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. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'SKARA-1295-csr-exception' of https://github.com/erikj79/skara into SKARA-1295-csr-exception > - Overwrite old auth headers on retry I believe I have it working now. Before retrying, the auth headers need to be explicitly overwritten. The currently used headers method just adds more values to the same headers, which the server will most likely not accept. ------------- PR: https://git.openjdk.java.net/skara/pull/1268 From kcr at openjdk.java.net Thu Jan 6 21:45:26 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 21:45:26 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 20:59:56 GMT, Erik Joelsson wrote: > While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: > > * Created String constants for the special custom fields we have in JBS. > * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. Looks good. I left a couple questions. bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 408: > 406: } > 407: > 408: private String getRequestedVersion(Repository localRepository, Commit commit, String tagBranch) { Minor: would `branch` be a better name? Or is it always a tag name in this method? bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/JbsBackport.java line 55: > 53: var finalProperties = new HashMap<>(primary.properties()); > 54: finalProperties.put("issuetype", JSON.of("Backport")); > 55: finalProperties.remove(RESOLVED_IN_BUILD); Minor: did you mean to make this change in this PR? It doesn't seem behavior neutral (might be related to the follow-on PR?) ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1270 From kcr at openjdk.java.net Thu Jan 6 21:52:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 21:52:48 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 21:21:46 GMT, Erik Joelsson wrote: > The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1271 From kcr at openjdk.java.net Thu Jan 6 21:57:23 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 21:57:23 GMT Subject: RFR: 1295: CSRBot throws intermittent exception when looking up JiraIssue links [v2] In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 18:32:54 GMT, Erik Joelsson wrote: >> 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. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch 'SKARA-1295-csr-exception' of https://github.com/erikj79/skara into SKARA-1295-csr-exception > - Overwrite old auth headers on retry Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1268 From erikj at openjdk.java.net Thu Jan 6 22:00:57 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 22:00:57 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 21:39:00 GMT, Kevin Rushforth wrote: >> While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: >> >> * Created String constants for the special custom fields we have in JBS. >> * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 408: > >> 406: } >> 407: >> 408: private String getRequestedVersion(Repository localRepository, Commit commit, String tagBranch) { > > Minor: would `branch` be a better name? Or is it always a tag name in this method? I agree. It seems I was lazy and just went with the IDE generated extracted method signature. > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/JbsBackport.java line 55: > >> 53: var finalProperties = new HashMap<>(primary.properties()); >> 54: finalProperties.put("issuetype", JSON.of("Backport")); >> 55: finalProperties.remove(RESOLVED_IN_BUILD); > > Minor: did you mean to make this change in this PR? It doesn't seem behavior neutral (might be related to the follow-on PR?) You are right, this was part of my initial solution for the follow-on PR and I had forgotten about doing it. ------------- PR: https://git.openjdk.java.net/skara/pull/1270 From erikj at openjdk.java.net Thu Jan 6 22:14:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 22:14:54 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 [v2] In-Reply-To: References: Message-ID: > While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: > > * Created String constants for the special custom fields we have in JBS. > * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: - Rename variable - Remove unwanted change ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1270/files - new: https://git.openjdk.java.net/skara/pull/1270/files/9ea6deed..bc66d6e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1270&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1270&range=00-01 Stats: 4 lines in 3 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1270.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1270/head:pull/1270 PR: https://git.openjdk.java.net/skara/pull/1270 From erikj at openjdk.java.net Thu Jan 6 22:14:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 22:14:54 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 [v2] In-Reply-To: References: Message-ID: <64ZD6iOcU6tuzOzLwZwnzaPZ2PKZRLqa71va6kL1zXU=.d135d671-8fc8-48a9-b45f-5141635f5107@github.com> On Thu, 6 Jan 2022 21:58:12 GMT, Erik Joelsson wrote: >> bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/JbsBackport.java line 55: >> >>> 53: var finalProperties = new HashMap<>(primary.properties()); >>> 54: finalProperties.put("issuetype", JSON.of("Backport")); >>> 55: finalProperties.remove(RESOLVED_IN_BUILD); >> >> Minor: did you mean to make this change in this PR? It doesn't seem behavior neutral (might be related to the follow-on PR?) > > You are right, this was part of my initial solution for the follow-on PR and I had forgotten about doing it. Removed from this change and applied in the follow-on. ------------- PR: https://git.openjdk.java.net/skara/pull/1270 From erikj at openjdk.java.net Thu Jan 6 22:15:58 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 22:15:58 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v2] In-Reply-To: References: Message-ID: > The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Applying fix for the fallback backport creation mechanism - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build - Require branch fixVersion and backport fixVersion to match to update resolved in build ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1271/files - new: https://git.openjdk.java.net/skara/pull/1271/files/b853c6ab..894d0719 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1271&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1271&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1271.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1271/head:pull/1271 PR: https://git.openjdk.java.net/skara/pull/1271 From erikj at openjdk.java.net Thu Jan 6 22:21:34 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 22:21:34 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 22:15:58 GMT, Erik Joelsson wrote: >> The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Applying fix for the fallback backport creation mechanism > - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build > - Require branch fixVersion and backport fixVersion to match to update resolved in build Adding another potential fix for the issue. Skara has two implementations for creating backports in the first place. The main one is to call the backport extension API we have in JBS, which handles it correctly. There is also a fallback mechanism in Skara. The fallback mechanism, if used, would copy the Resolved in Build field from the main bug. This change makes sure that field is cleared. In reality, I don't think the fallback mechanism is used anywhere other than in the tests themselves. ------------- PR: https://git.openjdk.java.net/skara/pull/1271 From kcr at openjdk.java.net Thu Jan 6 22:38:25 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 22:38:25 GMT Subject: RFR: Refactoring in preparation for SKARA-1146 [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 22:14:54 GMT, Erik Joelsson wrote: >> While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: >> >> * Created String constants for the special custom fields we have in JBS. >> * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. > > Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision: > > - Rename variable > - Remove unwanted change Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1270 From kcr at openjdk.java.net Thu Jan 6 22:44:10 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 22:44:10 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v2] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 22:15:58 GMT, Erik Joelsson wrote: >> The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Applying fix for the fallback backport creation mechanism > - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build > - Require branch fixVersion and backport fixVersion to match to update resolved in build Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1271 From kcr at openjdk.java.net Thu Jan 6 22:50:27 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 6 Jan 2022 22:50:27 GMT Subject: RFR: 1296: ArchiveWorkItem throws repeated exceptions after force push to PR In-Reply-To: References: Message-ID: <9T7fK6svVoxhpuiqKqBVYqxFHkUkM5QNq-bz-PfqTZo=.4299c3bb-b5ee-4c47-b717-77debb68d7bf@github.com> On Wed, 22 Dec 2021 19:21:31 GMT, Erik Joelsson wrote: > 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. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1267 From erikj at openjdk.java.net Thu Jan 6 23:03:09 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 23:03:09 GMT Subject: Integrated: 1295: CSRBot throws intermittent exception when looking up JiraIssue links In-Reply-To: References: Message-ID: <6d4SDLh9gfFUTAmkOu9tyVP8trsK7YHL__TVgib8FNk=.dc0af1f5-ed4e-412b-bfd3-30799c4adce2@github.com> On Thu, 23 Dec 2021 22:23:23 GMT, Erik Joelsson wrote: > 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. This pull request has now been integrated. Changeset: 6a7ae943 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/6a7ae9436fa21757f11ff84e44ddfd4b778520be Stats: 37 lines in 2 files changed: 32 ins; 3 del; 2 mod 1295: CSRBot throws intermittent exception when looking up JiraIssue links Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1268 From erikj at openjdk.java.net Thu Jan 6 23:03:49 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 23:03:49 GMT Subject: Integrated: Refactoring in preparation for SKARA-1146 In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 20:59:56 GMT, Erik Joelsson wrote: > While working on SKARA-1146, I felt that I needed to do some refactoring. To ease the review process, I've separated those changes into a separate PR. Nothing should change functionally from this change. Here is what I've done: > > * Created String constants for the special custom fields we have in JBS. > * In IssueNotifier, created a method for finding the fixVersion for a branch. This code block is actually copied and sprinkled all over the code base, but for now, I will just unify the copies in the same class. This pull request has now been integrated. Changeset: 6ebda450 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/6ebda450ec0adb58dbc60d071d1386622912c9fd Stats: 108 lines in 10 files changed: 36 ins; 26 del; 46 mod Refactoring in preparation for SKARA-1146 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1270 From duke at openjdk.java.net Thu Jan 6 23:03:59 2022 From: duke at openjdk.java.net (openjdk-notifier[bot]) Date: Thu, 6 Jan 2022 23:03:59 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v2] In-Reply-To: References: Message-ID: <9lOdOFNxMOaAmb1gAqsvYGe0Ye8JhAIvg_xCT-gj8lA=.6bc1825e-4319-4138-b73b-834b070a96cd@github.com> On Thu, 6 Jan 2022 22:15:58 GMT, Erik Joelsson wrote: >> The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Applying fix for the fallback backport creation mechanism > - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build > - Require branch fixVersion and backport fixVersion to match to update resolved in build The dependent pull request has now been integrated, and the target branch of this pull request has been updated. This means that changes from the dependent pull request can start to show up as belonging to this pull request, which may be confusing for reviewers. To remedy this situation, simply merge the latest changes from the new target branch into this pull request by running commands similar to these in the local repository for your personal fork: git checkout SKARA-1146-refactor git fetch https://git.openjdk.java.net/skara master git merge FETCH_HEAD # if there are conflicts, follow the instructions given by git merge git commit -m "Merge master" git push ------------- PR: https://git.openjdk.java.net/skara/pull/1271 From erikj at openjdk.java.net Thu Jan 6 23:15:21 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 6 Jan 2022 23:15:21 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v3] In-Reply-To: References: Message-ID: > The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into SKARA-1146-fixed-in-build - Applying fix for the fallback backport creation mechanism - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build - Rename variable - Remove unwanted change - Require branch fixVersion and backport fixVersion to match to update resolved in build - Refactor out common functionality - SKARA-1146 ------------- Changes: https://git.openjdk.java.net/skara/pull/1271/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1271&range=02 Stats: 28 lines in 4 files changed: 16 ins; 3 del; 9 mod Patch: https://git.openjdk.java.net/skara/pull/1271.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1271/head:pull/1271 PR: https://git.openjdk.java.net/skara/pull/1271 From kcr at openjdk.java.net Fri Jan 7 11:33:22 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 7 Jan 2022 11:33:22 GMT Subject: RFR: 1146: IssueNotifier updates wrong backport records on new build tags [v3] In-Reply-To: References: Message-ID: On Thu, 6 Jan 2022 23:15:21 GMT, Erik Joelsson wrote: >> The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. > > Erik Joelsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into SKARA-1146-fixed-in-build > - Applying fix for the fallback backport creation mechanism > - Merge branch 'SKARA-1146-refactor' into SKARA-1146-fixed-in-build > - Rename variable > - Remove unwanted change > - Require branch fixVersion and backport fixVersion to match to update resolved in build > - Refactor out common functionality > - SKARA-1146 Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1271 From erikj at openjdk.java.net Fri Jan 7 14:48:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 7 Jan 2022 14:48:35 GMT Subject: Integrated: 1146: IssueNotifier updates wrong backport records on new build tags In-Reply-To: References: Message-ID: On Mon, 3 Jan 2022 21:21:46 GMT, Erik Joelsson wrote: > The IssueNotifier currently updates the Resolved in Build field for any and all backports regardless of if the fixVersion of the backport matches the tag or not. This patch fixes that. I didn't need to implement new tests, just adjusting the existing ones seems to be enough to verify the functionality, as one of the existing ones actually was verifying the faulty behavior already. This pull request has now been integrated. Changeset: 157bbfff Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/157bbfffdb4523745b43984605ad83572b570c46 Stats: 28 lines in 4 files changed: 16 ins; 3 del; 9 mod 1146: IssueNotifier updates wrong backport records on new build tags Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1271 From erikj at openjdk.java.net Fri Jan 7 14:49:58 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 7 Jan 2022 14:49:58 GMT Subject: Integrated: 1296: ArchiveWorkItem throws repeated exceptions after force push to PR In-Reply-To: References: Message-ID: <1kj7dDtrRFbmwWFdeH1-XBLTHVepVlpPwnKF4Z_lLxI=.3c580413-633e-4140-b551-ac4f2e8008c0@github.com> On Wed, 22 Dec 2021 19:21:31 GMT, Erik Joelsson wrote: > 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. This pull request has now been integrated. Changeset: 45386784 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/453867848fe3e8d80af4667741decbb50010d49e Stats: 235 lines in 6 files changed: 188 ins; 5 del; 42 mod 1296: ArchiveWorkItem throws repeated exceptions after force push to PR Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1267 From erikj at openjdk.java.net Tue Jan 11 20:00:46 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 11 Jan 2022 20:00:46 GMT Subject: RFR: 1306: IssueNotifier fails to update Resolved In Build for issues with *-oracle fixVersion Message-ID: <2VVx4YavNtEa7JEXGveW-kUaoCXxX3jRK37Kfu8Gm2o=.9a94302a-0ed1-4ae2-b336-e7c7c49972d6@github.com> In SKARA-1146 I made the IssueNotifier for build tags only update Resolved In Build in issues where the fixVersion of the issue/backport matches the version in the build tag. I missed taking fixversions of the format N-foo into account. This patch addresses this by comparing just the number components of the JdkVersions so ignoring the the "opt" part. I chose to just adjust an existing test case to cover this case instead of creating a new one. ------------- Commit messages: - SKARA-1306 Changes: https://git.openjdk.java.net/skara/pull/1272/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1272&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1306 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1272.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1272/head:pull/1272 PR: https://git.openjdk.java.net/skara/pull/1272 From erikj at openjdk.java.net Tue Jan 11 21:16:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 11 Jan 2022 21:16:35 GMT Subject: RFR: 1304: The 'git skara sync' command often fails Message-ID: This is a partial rework of the rather recent change to "git skara fork" and "git skara sync". That patch tried to protect the user from syncing changes to the wrong host unintentionally, but unfortunately, it turned out to make it a bit too hard. With this patch I'm fixing some outright bugs as well as dialing back the protection a little bit. First the clear bugfixes: 1. When trying to figure out the official fork parent from the origin, setup and use credentials properly. 2. When forking and cloning a repository into a sub directory of an existing local repository, do not set the forge.name config in the existing local repository. Behavioral changes: 1. Do not require --force when explicitly setting --to and/or --from. I believe that if you set those parameters, you are already explicit enough. 2. Do require --force whenever the derived to and from do not share the same hostname. This should better catch the sensitive situation when changes are likely to be going the wrong way. 3. Since looking up the fork parent from the origin forge is unreliable, only use it when possible and mostly for verification, and only use it as the last option for default from repo. So to summarize, here is the expected behavior for choosing the repository from which to sync changes from (this now matches the existing documentation at https://wiki.openjdk.java.net/display/SKARA/git-sync). 1. The --from option if set either on the command line or configuration 2. A remote named "upstream" 3. The fork parent from the origin forge ------------- Commit messages: - Fixed comment - Fix fork - SKARA-1304 Changes: https://git.openjdk.java.net/skara/pull/1273/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1273&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1304 Stats: 140 lines in 2 files changed: 69 ins; 42 del; 29 mod Patch: https://git.openjdk.java.net/skara/pull/1273.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1273/head:pull/1273 PR: https://git.openjdk.java.net/skara/pull/1273 From kcr at openjdk.java.net Wed Jan 12 13:49:41 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 13:49:41 GMT Subject: RFR: 1304: The 'git skara sync' command often fails In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 21:12:42 GMT, Erik Joelsson wrote: > This is a partial rework of the rather recent change to "git skara fork" and "git skara sync". That patch tried to protect the user from syncing changes to the wrong host unintentionally, but unfortunately, it turned out to make it a bit too hard. > > With this patch I'm fixing some outright bugs as well as dialing back the protection a little bit. First the clear bugfixes: > > 1. When trying to figure out the official fork parent from the origin, setup and use credentials properly. > 2. When forking and cloning a repository into a sub directory of an existing local repository, do not set the forge.name config in the existing local repository. > > Behavioral changes: > > 1. Do not require --force when explicitly setting --to and/or --from. I believe that if you set those parameters, you are already explicit enough. > 2. Do require --force whenever the derived to and from do not share the same hostname. This should better catch the sensitive situation when changes are likely to be going the wrong way. > 3. Since looking up the fork parent from the origin forge is unreliable, only use it when possible and mostly for verification, and only use it as the last option for default from repo. > > So to summarize, here is the expected behavior for choosing the repository from which to sync changes from (this now matches the existing documentation at https://wiki.openjdk.java.net/display/SKARA/git-sync). > > 1. The --from option if set either on the command line or configuration > 2. A remote named "upstream" > 3. The fork parent from the origin forge The reworked logic looks good, although I have one question. I see that you call `findRemoteForkParent` even when there is an `upstream` remote configured. Is this necessary? Given your comments about it being unreliable and, in some cases, very slow, do you think that is needed? Or might it be better to only call `findRemoteForkParent` in the case where there is no `--from` option and no `upstream` remote configured? ------------- PR: https://git.openjdk.java.net/skara/pull/1273 From kcr at openjdk.java.net Wed Jan 12 13:50:37 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 13:50:37 GMT Subject: RFR: 1306: IssueNotifier fails to update Resolved In Build for issues with *-oracle fixVersion In-Reply-To: <2VVx4YavNtEa7JEXGveW-kUaoCXxX3jRK37Kfu8Gm2o=.9a94302a-0ed1-4ae2-b336-e7c7c49972d6@github.com> References: <2VVx4YavNtEa7JEXGveW-kUaoCXxX3jRK37Kfu8Gm2o=.9a94302a-0ed1-4ae2-b336-e7c7c49972d6@github.com> Message-ID: On Tue, 11 Jan 2022 19:57:01 GMT, Erik Joelsson wrote: > In SKARA-1146 I made the IssueNotifier for build tags only update Resolved In Build in issues where the fixVersion of the issue/backport matches the version in the build tag. I missed taking fixversions of the format N-foo into account. This patch addresses this by comparing just the number components of the JdkVersions so ignoring the the "opt" part. > > I chose to just adjust an existing test case to cover this case instead of creating a new one. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1272 From erikj at openjdk.java.net Wed Jan 12 14:25:15 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 12 Jan 2022 14:25:15 GMT Subject: RFR: 1304: The 'git skara sync' command often fails In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 21:12:42 GMT, Erik Joelsson wrote: > This is a partial rework of the rather recent change to "git skara fork" and "git skara sync". That patch tried to protect the user from syncing changes to the wrong host unintentionally, but unfortunately, it turned out to make it a bit too hard. > > With this patch I'm fixing some outright bugs as well as dialing back the protection a little bit. First the clear bugfixes: > > 1. When trying to figure out the official fork parent from the origin, setup and use credentials properly. > 2. When forking and cloning a repository into a sub directory of an existing local repository, do not set the forge.name config in the existing local repository. > > Behavioral changes: > > 1. Do not require --force when explicitly setting --to and/or --from. I believe that if you set those parameters, you are already explicit enough. > 2. Do require --force whenever the derived to and from do not share the same hostname. This should better catch the sensitive situation when changes are likely to be going the wrong way. > 3. Since looking up the fork parent from the origin forge is unreliable, only use it when possible and mostly for verification, and only use it as the last option for default from repo. > > So to summarize, here is the expected behavior for choosing the repository from which to sync changes from (this now matches the existing documentation at https://wiki.openjdk.java.net/display/SKARA/git-sync). > > 1. The --from option if set either on the command line or configuration > 2. A remote named "upstream" > 3. The fork parent from the origin forge I think when it works, it does provide a good extra sanity check. I've also fixed some of the cases where it didn't work (when the 'fork' command misconfigured the repository with forge.name for example), so with a correctly configured proxy, it's not noticeably slow now. The only case left that I know about is my own, when you don't have a general proxy config in the shell, but instead use the git config "http..proxy=". This git config is recommended in internal Skara documentation, but not picked up by Skara itself. I hope to fix this in a later enhancement. For other cases where we know that it won't work, or isn't needed, we just skip it. That would be when the remote is ssh based, or --force is set. This made me realize that there is a corner case where this patch doesn't work well. If the user has no upstream and runs with just '--force' on the command line, then 'sync' will not find any from repo at all. I could fix this. ------------- PR: https://git.openjdk.java.net/skara/pull/1273 From erikj at openjdk.java.net Wed Jan 12 14:27:00 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 12 Jan 2022 14:27:00 GMT Subject: Integrated: 1306: IssueNotifier fails to update Resolved In Build for issues with *-oracle fixVersion In-Reply-To: <2VVx4YavNtEa7JEXGveW-kUaoCXxX3jRK37Kfu8Gm2o=.9a94302a-0ed1-4ae2-b336-e7c7c49972d6@github.com> References: <2VVx4YavNtEa7JEXGveW-kUaoCXxX3jRK37Kfu8Gm2o=.9a94302a-0ed1-4ae2-b336-e7c7c49972d6@github.com> Message-ID: On Tue, 11 Jan 2022 19:57:01 GMT, Erik Joelsson wrote: > In SKARA-1146 I made the IssueNotifier for build tags only update Resolved In Build in issues where the fixVersion of the issue/backport matches the version in the build tag. I missed taking fixversions of the format N-foo into account. This patch addresses this by comparing just the number components of the JdkVersions so ignoring the the "opt" part. > > I chose to just adjust an existing test case to cover this case instead of creating a new one. This pull request has now been integrated. Changeset: a3c21256 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/a3c21256639171b369b7afcb6b12087b20c1d919 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 1306: IssueNotifier fails to update Resolved In Build for issues with *-oracle fixVersion Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1272 From kcr at openjdk.java.net Wed Jan 12 16:16:33 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 12 Jan 2022 16:16:33 GMT Subject: RFR: 1304: The 'git skara sync' command often fails In-Reply-To: References: Message-ID: <9f951Rx8703vNROU5L1SPlFhXMhkbpyJCVfyC8Jyy14=.870e10b8-fff0-4b44-b735-b20419d8760a@github.com> On Tue, 11 Jan 2022 21:12:42 GMT, Erik Joelsson wrote: > This is a partial rework of the rather recent change to "git skara fork" and "git skara sync". That patch tried to protect the user from syncing changes to the wrong host unintentionally, but unfortunately, it turned out to make it a bit too hard. > > With this patch I'm fixing some outright bugs as well as dialing back the protection a little bit. First the clear bugfixes: > > 1. When trying to figure out the official fork parent from the origin, setup and use credentials properly. > 2. When forking and cloning a repository into a sub directory of an existing local repository, do not set the forge.name config in the existing local repository. > > Behavioral changes: > > 1. Do not require --force when explicitly setting --to and/or --from. I believe that if you set those parameters, you are already explicit enough. > 2. Do require --force whenever the derived to and from do not share the same hostname. This should better catch the sensitive situation when changes are likely to be going the wrong way. > 3. Since looking up the fork parent from the origin forge is unreliable, only use it when possible and mostly for verification, and only use it as the last option for default from repo. > > So to summarize, here is the expected behavior for choosing the repository from which to sync changes from (this now matches the existing documentation at https://wiki.openjdk.java.net/display/SKARA/git-sync). > > 1. The --from option if set either on the command line or configuration > 2. A remote named "upstream" > 3. The fork parent from the origin forge > I think when it works, it does provide a good extra sanity check. ... so with a correctly configured proxy, it's not noticeably slow now. OK, good. > This made me realize that there is a corner case where this patch doesn't work well. If the user has no upstream and runs with just '--force' on the command line, then 'sync' will not find any from repo at all. I could fix this. Hmm. It looks like it should work with your existing patch, but maybe I'm missing something. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1273 From erikj at openjdk.java.net Thu Jan 13 14:38:20 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 13 Jan 2022 14:38:20 GMT Subject: Integrated: 1304: The 'git skara sync' command often fails In-Reply-To: References: Message-ID: On Tue, 11 Jan 2022 21:12:42 GMT, Erik Joelsson wrote: > This is a partial rework of the rather recent change to "git skara fork" and "git skara sync". That patch tried to protect the user from syncing changes to the wrong host unintentionally, but unfortunately, it turned out to make it a bit too hard. > > With this patch I'm fixing some outright bugs as well as dialing back the protection a little bit. First the clear bugfixes: > > 1. When trying to figure out the official fork parent from the origin, setup and use credentials properly. > 2. When forking and cloning a repository into a sub directory of an existing local repository, do not set the forge.name config in the existing local repository. > > Behavioral changes: > > 1. Do not require --force when explicitly setting --to and/or --from. I believe that if you set those parameters, you are already explicit enough. > 2. Do require --force whenever the derived to and from do not share the same hostname. This should better catch the sensitive situation when changes are likely to be going the wrong way. > 3. Since looking up the fork parent from the origin forge is unreliable, only use it when possible and mostly for verification, and only use it as the last option for default from repo. > > So to summarize, here is the expected behavior for choosing the repository from which to sync changes from (this now matches the existing documentation at https://wiki.openjdk.java.net/display/SKARA/git-sync). > > 1. The --from option if set either on the command line or configuration > 2. A remote named "upstream" > 3. The fork parent from the origin forge This pull request has now been integrated. Changeset: b068ba75 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/b068ba7543de3aa19886d39fcf924c7523c299bf Stats: 140 lines in 2 files changed: 69 ins; 42 del; 29 mod 1304: The 'git skara sync' command often fails Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1273 From erikj at openjdk.java.net Thu Jan 13 21:19:55 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 13 Jan 2022 21:19:55 GMT Subject: RFR: 1308: CSRBot only reacts to approved CSR if PR is touched Message-ID: When a CSR issue is approved, any associated PR is only updated once someone touches the PR. The CSRBot will not evaluate anything about a PR unless there is a change to the PR. Since a CSR issue update only happens in JBS, the CSRBot cannot be limited by PR updates, it needs to check Jira for changes. This patch removes the use of the PullRequestUpdateCache to limit when the bot evaluates a PR. If this turns out to generate too much load on JBS, we will have to implement a limiter in some way, but I don't think it will be a big issue in practice. ------------- Commit messages: - Remove dead code - SKARA-1308 Changes: https://git.openjdk.java.net/skara/pull/1274/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1274&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1308 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1274.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1274/head:pull/1274 PR: https://git.openjdk.java.net/skara/pull/1274 From kcr at openjdk.java.net Thu Jan 13 22:12:11 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 22:12:11 GMT Subject: RFR: 1308: CSRBot only reacts to approved CSR if PR is touched In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 21:15:50 GMT, Erik Joelsson wrote: > When a CSR issue is approved, any associated PR is only updated once someone touches the PR. The CSRBot will not evaluate anything about a PR unless there is a change to the PR. Since a CSR issue update only happens in JBS, the CSRBot cannot be limited by PR updates, it needs to check Jira for changes. > > This patch removes the use of the PullRequestUpdateCache to limit when the bot evaluates a PR. If this turns out to generate too much load on JBS, we will have to implement a limiter in some way, but I don't think it will be a big issue in practice. Looks good. I left one comment about a possible alternative, but it might not be worth doing. bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 75: > 73: if (!cache.needsUpdate(pr)) { > 74: continue; > 75: } An alternative to eliminating this check would be to poll JBS either if the PR was updated or if the PR has a csr label. But as you say, maybe it won't be a performance problem, in which case your proposed change is better. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1274 From erikj at openjdk.java.net Thu Jan 13 22:17:54 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 13 Jan 2022 22:17:54 GMT Subject: RFR: 1308: CSRBot only reacts to approved CSR if PR is touched In-Reply-To: References: Message-ID: <-vwaDu3v59vI-y1-Jjinja325T_9v9hxQIcroZ4c8ag=.ca9a5cc2-1006-489b-9b5c-f8c111f3ce37@github.com> On Thu, 13 Jan 2022 22:08:51 GMT, Kevin Rushforth wrote: >> When a CSR issue is approved, any associated PR is only updated once someone touches the PR. The CSRBot will not evaluate anything about a PR unless there is a change to the PR. Since a CSR issue update only happens in JBS, the CSRBot cannot be limited by PR updates, it needs to check Jira for changes. >> >> This patch removes the use of the PullRequestUpdateCache to limit when the bot evaluates a PR. If this turns out to generate too much load on JBS, we will have to implement a limiter in some way, but I don't think it will be a big issue in practice. > > bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 75: > >> 73: if (!cache.needsUpdate(pr)) { >> 74: continue; >> 75: } > > An alternative to eliminating this check would be to poll JBS either if the PR was updated or if the PR has a csr label. But as you say, maybe it won't be a performance problem, in which case your proposed change is better. Note that we also want to react if a CSR issue is created when the label isn't there. In that case we automatically add the CSR label. ------------- PR: https://git.openjdk.java.net/skara/pull/1274 From kcr at openjdk.java.net Thu Jan 13 22:25:00 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 13 Jan 2022 22:25:00 GMT Subject: RFR: 1308: CSRBot only reacts to approved CSR if PR is touched In-Reply-To: <-vwaDu3v59vI-y1-Jjinja325T_9v9hxQIcroZ4c8ag=.ca9a5cc2-1006-489b-9b5c-f8c111f3ce37@github.com> References: <-vwaDu3v59vI-y1-Jjinja325T_9v9hxQIcroZ4c8ag=.ca9a5cc2-1006-489b-9b5c-f8c111f3ce37@github.com> Message-ID: <6XVa3DtyT6FdGTjjd8yKYmjK2nBGX9GqK8hQ4UHTvLM=.a7462cf8-7557-4119-aa0e-e1c014c436d6@github.com> On Thu, 13 Jan 2022 22:15:18 GMT, Erik Joelsson wrote: >> bots/csr/src/main/java/org/openjdk/skara/bots/csr/CSRBot.java line 75: >> >>> 73: if (!cache.needsUpdate(pr)) { >>> 74: continue; >>> 75: } >> >> An alternative to eliminating this check would be to poll JBS either if the PR was updated or if the PR has a csr label. But as you say, maybe it won't be a performance problem, in which case your proposed change is better. > > Note that we also want to react if a CSR issue is created when the label isn't there. In that case we automatically add the CSR label. Yeah, that's the main reason your fix is better. ------------- PR: https://git.openjdk.java.net/skara/pull/1274 From erikj at openjdk.java.net Fri Jan 14 18:49:25 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 14 Jan 2022 18:49:25 GMT Subject: Integrated: 1308: CSRBot only reacts to approved CSR if PR is touched In-Reply-To: References: Message-ID: On Thu, 13 Jan 2022 21:15:50 GMT, Erik Joelsson wrote: > When a CSR issue is approved, any associated PR is only updated once someone touches the PR. The CSRBot will not evaluate anything about a PR unless there is a change to the PR. Since a CSR issue update only happens in JBS, the CSRBot cannot be limited by PR updates, it needs to check Jira for changes. > > This patch removes the use of the PullRequestUpdateCache to limit when the bot evaluates a PR. If this turns out to generate too much load on JBS, we will have to implement a limiter in some way, but I don't think it will be a big issue in practice. This pull request has now been integrated. Changeset: 677bf943 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/677bf943d78a45c0e561a53109c1fb4de709fd10 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod 1308: CSRBot only reacts to approved CSR if PR is touched Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1274 From david.holmes at oracle.com Tue Jan 18 07:20:07 2022 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Jan 2022 17:20:07 +1000 Subject: Email collation of PR comments Message-ID: Not sure if something was recently changed but I'm now noticing some emails from PR's are collating comments in a way that makes the email very awkward to read/understand. For example in: https://github.com/openjdk/jdk/pull/7079 I made two comments (one stand-alone and one as part of approving the change): ------------ dholmes-ora commented 11 minutes ago Thanks Thomas! I was too focused on the original string and didn't check that the exception code was going to make a copy anyway. There's likely multiple copies made on the way to the final String object. dholmes-ora approved these changes 10 minutes ago dholmes-ora left a comment Seems fine. Thanks, David ------------ but the email that was sent flipped the order and just ran them together, so the email has: ------------ Seems fine. Thanks, David Thanks Thomas! I was too focused on the original string and didn't check that the exception code was going to make a copy anyway. There's likely multiple copies made on the way to the final String object. ------------- I would have expected the comments to be presented in the order in which they were written, and that there would be some kind of delimiter between them so you could tell they were distinct comments. Cheers, David From erik.joelsson at oracle.com Tue Jan 18 14:16:00 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 18 Jan 2022 06:16:00 -0800 Subject: Email collation of PR comments In-Reply-To: References: Message-ID: <28533535-e510-3261-0524-913f0479aa91@oracle.com> Hello David, Nothing has changed in this area since I've been involved in the project (that I know of). I have also noticed that my comments aren't always included in the order I would have preferred, but I haven't looked further into it. Feel free to file a bug about it. /Erik On 2022-01-17 23:20, David Holmes wrote: > Not sure if something was recently changed but I'm now noticing some > emails from PR's are collating comments in a way that makes the email > very awkward to read/understand. > > For example in: > > https://github.com/openjdk/jdk/pull/7079 > > I made two comments (one stand-alone and one as part of approving the > change): > > ------------ > dholmes-ora commented 11 minutes ago > > Thanks Thomas! I was too focused on the original string and didn't > check that the exception code was going to make a copy anyway. There's > likely multiple copies made on the way to the final String object. > > dholmes-ora approved these changes 10 minutes ago > > dholmes-ora left a comment > > Seems fine. > > Thanks, > David > ------------ > > but the email that was sent flipped the order and just ran them > together, so the email has: > > ------------ > Seems fine. > > Thanks, > David > > Thanks Thomas! I was too focused on the original string and didn't > check that the exception code was going to make a copy anyway. There's > likely multiple copies made on the way to the final String object. > > ------------- > > > I would have expected the comments to be presented in the order in > which they were written, and that there would be some kind of > delimiter between them so you could tell they were distinct comments. > > Cheers, > David From erikj at openjdk.java.net Tue Jan 18 21:53:03 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 18 Jan 2022 21:53:03 GMT Subject: RFR: 1316: Review comment on a commit triggers error in CommitCommentsWorkItem Message-ID: Add additional filtering of notes when looking for comments on commits on Gitlab, to avoid picking up comments on other things, such as MR diffs. ------------- Commit messages: - SKARA-1316 Changes: https://git.openjdk.java.net/skara/pull/1275/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1275&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1316 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1275.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1275/head:pull/1275 PR: https://git.openjdk.java.net/skara/pull/1275 From kcr at openjdk.java.net Tue Jan 18 22:36:58 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 18 Jan 2022 22:36:58 GMT Subject: RFR: 1316: Review comment on a commit triggers error in CommitCommentsWorkItem In-Reply-To: References: Message-ID: <8VOqwgkM54vs92dAHJvplyGjFilNM1PnLPI0-pPgJeo=.43171684-51d0-45c0-ab6d-3d206755fbbc@github.com> On Tue, 18 Jan 2022 21:49:01 GMT, Erik Joelsson wrote: > Add additional filtering of notes when looking for comments on commits on Gitlab, to avoid picking up comments on other things, such as MR diffs. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1275 From erikj at openjdk.java.net Wed Jan 19 17:21:59 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 19 Jan 2022 17:21:59 GMT Subject: RFR: 1320: Skara failing to create backport records for fixes synced into mainline Message-ID: When forward merging changes from jdk18 to mainline, we are no longer correctly creating backport entries for jdk19. This is because we switched from a Skara configuration for fixVersion to using the .jcheck/conf version from the repo in mainline. When Skara figures out the correct fixVersion from .jcheck/conf, it uses the file at the commit in question. In the case of a forward merge, that commit will have an outdated version in .jcheck/conf, as the commit is not a descendant of the version update change. This change fixes this situation, by optionally (through a configuration parameter) have Skara use the HEAD version of .jcheck/conf (for the given branch) when resolving fixVersion for a commit. Some care needs to be taken when using this option, but essentially no more so than we already had to do when configuring the fixVersion in the Skara config. The plan is to enable this option just for mainline jdk and jfx. ------------- Commit messages: - SKARA-1320 Changes: https://git.openjdk.java.net/skara/pull/1276/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1276&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1320 Stats: 82 lines in 4 files changed: 79 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1276.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1276/head:pull/1276 PR: https://git.openjdk.java.net/skara/pull/1276 From erikj at openjdk.java.net Wed Jan 19 17:24:27 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 19 Jan 2022 17:24:27 GMT Subject: Integrated: 1316: Review comment on a commit triggers error in CommitCommentsWorkItem In-Reply-To: References: Message-ID: On Tue, 18 Jan 2022 21:49:01 GMT, Erik Joelsson wrote: > Add additional filtering of notes when looking for comments on commits on Gitlab, to avoid picking up comments on other things, such as MR diffs. This pull request has now been integrated. Changeset: 09b1e6bc Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/09b1e6bc2dc89ab0786bacc9d058018fa7565b93 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 1316: Review comment on a commit triggers error in CommitCommentsWorkItem Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1275 From kcr at openjdk.java.net Wed Jan 19 17:36:48 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 17:36:48 GMT Subject: RFR: 1320: Skara failing to create backport records for fixes synced into mainline In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:17:45 GMT, Erik Joelsson wrote: > When forward merging changes from jdk18 to mainline, we are no longer correctly creating backport entries for jdk19. This is because we switched from a Skara configuration for fixVersion to using the .jcheck/conf version from the repo in mainline. When Skara figures out the correct fixVersion from .jcheck/conf, it uses the file at the commit in question. In the case of a forward merge, that commit will have an outdated version in .jcheck/conf, as the commit is not a descendant of the version update change. > > This change fixes this situation, by optionally (through a configuration parameter) have Skara use the HEAD version of .jcheck/conf (for the given branch) when resolving fixVersion for a commit. Some care needs to be taken when using this option, but essentially no more so than we already had to do when configuring the fixVersion in the Skara config. > > The plan is to enable this option just for mainline jdk and jfx. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1276 From erikj at openjdk.java.net Wed Jan 19 17:43:52 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 19 Jan 2022 17:43:52 GMT Subject: Integrated: 1320: Skara failing to create backport records for fixes synced into mainline In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 17:17:45 GMT, Erik Joelsson wrote: > When forward merging changes from jdk18 to mainline, we are no longer correctly creating backport entries for jdk19. This is because we switched from a Skara configuration for fixVersion to using the .jcheck/conf version from the repo in mainline. When Skara figures out the correct fixVersion from .jcheck/conf, it uses the file at the commit in question. In the case of a forward merge, that commit will have an outdated version in .jcheck/conf, as the commit is not a descendant of the version update change. > > This change fixes this situation, by optionally (through a configuration parameter) have Skara use the HEAD version of .jcheck/conf (for the given branch) when resolving fixVersion for a commit. Some care needs to be taken when using this option, but essentially no more so than we already had to do when configuring the fixVersion in the Skara config. > > The plan is to enable this option just for mainline jdk and jfx. This pull request has now been integrated. Changeset: 556c63d5 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/556c63d5a0f18cb7dea1ab8a46f41a0e1551a469 Stats: 82 lines in 4 files changed: 79 ins; 0 del; 3 mod 1320: Skara failing to create backport records for fixes synced into mainline Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1276 From erikj at openjdk.java.net Wed Jan 19 19:27:43 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 19 Jan 2022 19:27:43 GMT Subject: RFR: Fix NPE in 'notes' filter after SKARA-1316 Message-ID: The fix for SKARA-1316 resulted in NPE in several cases. It appears the field "target_type" is often explicitly set to null. To mitigate this, I added a null check and moved this filter a bit lower in the order (so we only apply it to notes that are a bit closer to what we want). ------------- Commit messages: - Fix NPE in 'notes' filter Changes: https://git.openjdk.java.net/skara/pull/1277/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1277&range=00 Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1277.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1277/head:pull/1277 PR: https://git.openjdk.java.net/skara/pull/1277 From kcr at openjdk.java.net Wed Jan 19 19:27:43 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 19 Jan 2022 19:27:43 GMT Subject: RFR: Fix NPE in 'notes' filter after SKARA-1316 In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 19:22:10 GMT, Erik Joelsson wrote: > The fix for SKARA-1316 resulted in NPE in several cases. It appears the field "target_type" is often explicitly set to null. To mitigate this, I added a null check and moved this filter a bit lower in the order (so we only apply it to notes that are a bit closer to what we want). Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1277 From erikj at openjdk.java.net Wed Jan 19 19:34:58 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 19 Jan 2022 19:34:58 GMT Subject: Integrated: Fix NPE in 'notes' filter after SKARA-1316 In-Reply-To: References: Message-ID: On Wed, 19 Jan 2022 19:22:10 GMT, Erik Joelsson wrote: > The fix for SKARA-1316 resulted in NPE in several cases. It appears the field "target_type" is often explicitly set to null. To mitigate this, I added a null check and moved this filter a bit lower in the order (so we only apply it to notes that are a bit closer to what we want). This pull request has now been integrated. Changeset: ab4c9f4f Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/ab4c9f4fc47c9918c4bc54de205b1bb641c6635d Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 mod Fix NPE in 'notes' filter after SKARA-1316 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1277 From erikj at openjdk.java.net Thu Jan 20 19:00:33 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 20 Jan 2022 19:00:33 GMT Subject: RFR: 1311: Pull Request not closed automatically Message-ID: <29IW27x8KpfKmPMBUlMVZm35W2ZJDCg-55vYGJkEyys=.629b12b1-b769-4180-a155-2fb6a91a6bc0@github.com> If an integration gets interrupted or fails at the wrong time, a PR may end up in a state where it gets stuck without ever being closed. I fixed this by making sure we give any commit commands the chance to run even when a PR is marked as integrated. I've also extended the test to verify recovering from interruption at each of the steps we take when integrating. ------------- Commit messages: - SKARA-1311 Changes: https://git.openjdk.java.net/skara/pull/1278/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1278&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1311 Stats: 88 lines in 3 files changed: 41 ins; 29 del; 18 mod Patch: https://git.openjdk.java.net/skara/pull/1278.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1278/head:pull/1278 PR: https://git.openjdk.java.net/skara/pull/1278 From kcr at openjdk.java.net Fri Jan 21 00:41:03 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 21 Jan 2022 00:41:03 GMT Subject: RFR: 1311: Pull Request not closed automatically In-Reply-To: <29IW27x8KpfKmPMBUlMVZm35W2ZJDCg-55vYGJkEyys=.629b12b1-b769-4180-a155-2fb6a91a6bc0@github.com> References: <29IW27x8KpfKmPMBUlMVZm35W2ZJDCg-55vYGJkEyys=.629b12b1-b769-4180-a155-2fb6a91a6bc0@github.com> Message-ID: On Thu, 20 Jan 2022 18:56:18 GMT, Erik Joelsson wrote: > If an integration gets interrupted or fails at the wrong time, a PR may end up in a state where it gets stuck without ever being closed. I fixed this by making sure we give any commit commands the chance to run even when a PR is marked as integrated. > > I've also extended the test to verify recovering from interruption at each of the steps we take when integrating. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1278 From erikj at openjdk.java.net Fri Jan 21 13:52:32 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 21 Jan 2022 13:52:32 GMT Subject: Integrated: 1311: Pull Request not closed automatically In-Reply-To: <29IW27x8KpfKmPMBUlMVZm35W2ZJDCg-55vYGJkEyys=.629b12b1-b769-4180-a155-2fb6a91a6bc0@github.com> References: <29IW27x8KpfKmPMBUlMVZm35W2ZJDCg-55vYGJkEyys=.629b12b1-b769-4180-a155-2fb6a91a6bc0@github.com> Message-ID: On Thu, 20 Jan 2022 18:56:18 GMT, Erik Joelsson wrote: > If an integration gets interrupted or fails at the wrong time, a PR may end up in a state where it gets stuck without ever being closed. I fixed this by making sure we give any commit commands the chance to run even when a PR is marked as integrated. > > I've also extended the test to verify recovering from interruption at each of the steps we take when integrating. This pull request has now been integrated. Changeset: 8ad1c7ab Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/8ad1c7ab7e5d1c582ccf5ae429246a8aaa15e8f9 Stats: 88 lines in 3 files changed: 41 ins; 29 del; 18 mod 1311: Pull Request not closed automatically Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1278 From christoph.langer at sap.com Mon Jan 24 07:53:58 2022 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 24 Jan 2022 07:53:58 +0000 Subject: Openjdk bot repo write access missing for backport branches In-Reply-To: References: Message-ID: Hi, forwarding to skara-dev, cc Kevin/Erik to help you with that one. They'll probably have to do this. Cheers Christoph > -----Original Message----- > From: jdk-updates-dev On > Behalf Of Thomas St?fe > Sent: Montag, 24. Januar 2022 07:17 > To: jdk-updates-dev > Subject: Openjdk bot repo write access missing for backport branches > > Hi, > > I miss write access to backport PR branches created by the OpenJDK bot. I > assume I missed the original invite mails? I found them, but they are expired. > > This only matters if I need to adapt a PR branch created by the OpenJDK bot > on my behalf (so it applied cleanly but needs changing), which does not > happen often. Therefore I did not notice the missing access until now. > > Is there a way to trigger the resending of invites for openjdk-bots/jdk17u- > dev and openjdk-bots/jdk11u-dev? > > Thanks, Thomas From erik.joelsson at oracle.com Mon Jan 24 13:46:14 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 24 Jan 2022 05:46:14 -0800 Subject: [External] : RE: Openjdk bot repo write access missing for backport branches In-Reply-To: References: Message-ID: <951fdbda-8ab6-f65b-1cc8-851aac681d29@oracle.com> Hello Thomas, Permissions to the OpenJDK bot repos we use for backport PRs/branches are handed out dynamically when you create a /backport. No bulk invites have been sent out AFAIK. /Erik On 2022-01-23 23:53, Langer, Christoph wrote: > Hi, > > forwarding to skara-dev, cc Kevin/Erik to help you with that one. They'll probably have to do this. > > Cheers > Christoph > >> -----Original Message----- >> From: jdk-updates-dev On >> Behalf Of Thomas St?fe >> Sent: Montag, 24. Januar 2022 07:17 >> To: jdk-updates-dev >> Subject: Openjdk bot repo write access missing for backport branches >> >> Hi, >> >> I miss write access to backport PR branches created by the OpenJDK bot. I >> assume I missed the original invite mails? I found them, but they are expired. >> >> This only matters if I need to adapt a PR branch created by the OpenJDK bot >> on my behalf (so it applied cleanly but needs changing), which does not >> happen often. Therefore I did not notice the missing access until now. >> >> Is there a way to trigger the resending of invites for openjdk-bots/jdk17u- >> dev and openjdk-bots/jdk11u-dev? >> >> Thanks, Thomas From thomas.stuefe at gmail.com Mon Jan 24 14:12:59 2022 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 24 Jan 2022 15:12:59 +0100 Subject: [External] : RE: Openjdk bot repo write access missing for backport branches In-Reply-To: <951fdbda-8ab6-f65b-1cc8-851aac681d29@oracle.com> References: <951fdbda-8ab6-f65b-1cc8-851aac681d29@oracle.com> Message-ID: Hi Erik, (removing updates-dev) thanks for looking at this. This morning I tried to backport this patch: https://github.com/openjdk/jdk/commit/110e38ded8e09361f24c582c770d35f5cfdabf82 to jdk17u-dev. Since I needed to change the patch before creating the PR, I followed the instructions printed by the bot under "If you need to update the source branch ..." but found that I could not push my changes back to the OpenJDK bot repo. This morning, I did not get an invite mail when issuing the /backport command. However, ten days ago I created my first /backport for jdk17u-dev, and I got an invite mail then. But I had ignored that invite since the patch applied cleanly and no change was needed. And now that first invite is expired. Does the bot send an invite each time or only the first time I issue /backport on a given repo? Thanks, Thomas On Mon, Jan 24, 2022 at 2:46 PM wrote: > Hello Thomas, > > Permissions to the OpenJDK bot repos we use for backport PRs/branches > are handed out dynamically when you create a /backport. No bulk invites > have been sent out AFAIK. > > /Erik > > On 2022-01-23 23:53, Langer, Christoph wrote: > > Hi, > > > > forwarding to skara-dev, cc Kevin/Erik to help you with that one. > They'll probably have to do this. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Thomas St?fe > >> Sent: Montag, 24. Januar 2022 07:17 > >> To: jdk-updates-dev > >> Subject: Openjdk bot repo write access missing for backport branches > >> > >> Hi, > >> > >> I miss write access to backport PR branches created by the OpenJDK bot. > I > >> assume I missed the original invite mails? I found them, but they are > expired. > >> > >> This only matters if I need to adapt a PR branch created by the OpenJDK > bot > >> on my behalf (so it applied cleanly but needs changing), which does not > >> happen often. Therefore I did not notice the missing access until now. > >> > >> Is there a way to trigger the resending of invites for > openjdk-bots/jdk17u- > >> dev and openjdk-bots/jdk11u-dev? > >> > >> Thanks, Thomas > From erik.joelsson at oracle.com Mon Jan 24 14:43:43 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 24 Jan 2022 06:43:43 -0800 Subject: [External] : RE: Openjdk bot repo write access missing for backport branches In-Reply-To: References: <951fdbda-8ab6-f65b-1cc8-851aac681d29@oracle.com> Message-ID: <86260048-e8fc-fb98-9d7d-16c68794703c@oracle.com> Hello Thomas, On 2022-01-24 06:12, Thomas St?fe wrote: > Hi Erik, > > (removing updates-dev) > > thanks for looking at this. > > This morning I tried to backport this patch: > https://github.com/openjdk/jdk/commit/110e38ded8e09361f24c582c770d35f5cfdabf82 > > to jdk17u-dev. > > Since I needed to change the patch before creating the PR, I followed > the instructions printed by the bot under "If you need to update the > source branch > ?..." > but found that I could not push my changes back to the OpenJDK bot > repo. This morning, I did not get an invite mail when issuing the > /backport command. However, ten days ago I created?my first /backport > for jdk17u-dev, and I got an invite mail then. But I had ignored that > invite since the patch applied cleanly and no change was needed. And > now that first invite is expired. > > Does the bot send an invite each time or only the first time I issue > /backport on a given repo? > I'm not sure how Github handles "invites", but the bot will try to add you with write permissions through the github API unless you already have write permission. Looking at the repo, you weren't in the collaborators, probably because the invite had timed out. My best guess is that the invite was still active when you created the last backport, so the bot didn't add you again, then it timed out soon after. I have manually added you to this repo again. /Erik > Thanks, Thomas > > > > > On Mon, Jan 24, 2022 at 2:46 PM wrote: > > Hello Thomas, > > Permissions to the OpenJDK bot repos we use for backport PRs/branches > are handed out dynamically when you create a /backport. No bulk > invites > have been sent out AFAIK. > > /Erik > > On 2022-01-23 23:53, Langer, Christoph wrote: > > Hi, > > > > forwarding to skara-dev, cc Kevin/Erik to help you with that > one. They'll probably have to do this. > > > > Cheers > > Christoph > > > >> -----Original Message----- > >> From: jdk-updates-dev On > >> Behalf Of Thomas St?fe > >> Sent: Montag, 24. Januar 2022 07:17 > >> To: jdk-updates-dev > >> Subject: Openjdk bot repo write access missing for backport > branches > >> > >> Hi, > >> > >> I miss write access to backport PR branches created by the > OpenJDK bot. I > >> assume I missed the original invite mails? I found them, but > they are expired. > >> > >> This only matters if I need to adapt a PR branch created by the > OpenJDK bot > >> on my behalf (so it applied cleanly but needs changing), which > does not > >> happen often. Therefore I did not notice the missing access > until now. > >> > >> Is there a way to trigger the resending of invites for > openjdk-bots/jdk17u- > >> dev and openjdk-bots/jdk11u-dev? > >> > >> Thanks, Thomas > From erikj at openjdk.java.net Mon Jan 24 20:54:31 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 24 Jan 2022 20:54:31 GMT Subject: RFR: 1325: Update Skara to recognize the FX 8uNNN-bXX tag format Message-ID: Add support for the legacy (8u) jfx tag format. ------------- Commit messages: - Simplify regexp a bit - SKARA-1325 Changes: https://git.openjdk.java.net/skara/pull/1279/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1279&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1325 Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1279.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1279/head:pull/1279 PR: https://git.openjdk.java.net/skara/pull/1279 From kcr at openjdk.java.net Mon Jan 24 21:36:38 2022 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 24 Jan 2022 21:36:38 GMT Subject: RFR: 1325: Update Skara to recognize the FX 8uNNN-bXX tag format In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 20:50:22 GMT, Erik Joelsson wrote: > Add support for the legacy (8u) jfx tag format. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1279 From erikj at openjdk.java.net Mon Jan 24 21:58:12 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 24 Jan 2022 21:58:12 GMT Subject: Integrated: 1325: Update Skara to recognize the FX 8uNNN-bXX tag format In-Reply-To: References: Message-ID: On Mon, 24 Jan 2022 20:50:22 GMT, Erik Joelsson wrote: > Add support for the legacy (8u) jfx tag format. This pull request has now been integrated. Changeset: 69aa9482 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/69aa9482b96fcab75868ff6bc97c7e843a691e7d Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod 1325: Update Skara to recognize the FX 8uNNN-bXX tag format Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1279 From duke at openjdk.java.net Wed Jan 26 12:52:20 2022 From: duke at openjdk.java.net (duke) Date: Wed, 26 Jan 2022 12:52:20 GMT Subject: Withdrawn: 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/skara/pull/1247 From erikj at openjdk.java.net Wed Jan 26 20:20:17 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 26 Jan 2022 20:20:17 GMT Subject: RFR: 1329: incorrect hgupdate label for JDK 7 updates Message-ID: This patch adds special handling of Backports for a couple of historic releases where we have 30 or more builds (and no BPRs). ------------- Commit messages: - SKARA-1329 Changes: https://git.openjdk.java.net/skara/pull/1280/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1280&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1329 Stats: 64 lines in 2 files changed: 54 ins; 2 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1280.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1280/head:pull/1280 PR: https://git.openjdk.java.net/skara/pull/1280 From duke at openjdk.java.net Wed Jan 26 22:13:59 2022 From: duke at openjdk.java.net (duke) Date: Wed, 26 Jan 2022 22:13:59 GMT Subject: Withdrawn: 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 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/skara/pull/1262 From ihse at openjdk.java.net Thu Jan 27 09:58:17 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 27 Jan 2022 09:58:17 GMT Subject: RFR: 1329: incorrect hgupdate label for JDK 7 updates In-Reply-To: References: Message-ID: <1ekN1J37VwzFuw2U8XDt1wHq4otDlcjVubBp41YHHPs=.65f16011-4af4-4833-ad6e-8fbe080b0714@github.com> On Wed, 26 Jan 2022 20:16:23 GMT, Erik Joelsson wrote: > This patch adds special handling of Backports for a couple of historic releases where we have 30 or more builds (and no BPRs). LGTM barring my question about the upper bound for BPRs. jbs/src/main/java/org/openjdk/skara/jbs/Backports.java line 320: > 318: if (resolvedInBuildNumber < 30) { > 319: ret.add(jdkVersion.feature()); > 320: } else if (resolvedInBuildNumber < 60) { In the JBS comment you stated that the spec says BPR builds should only be < 39. Did you chose not to change the current formulation, or did you forget? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1280 From erikj at openjdk.java.net Thu Jan 27 14:49:35 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 Jan 2022 14:49:35 GMT Subject: RFR: 1329: incorrect hgupdate label for JDK 7 updates In-Reply-To: <1ekN1J37VwzFuw2U8XDt1wHq4otDlcjVubBp41YHHPs=.65f16011-4af4-4833-ad6e-8fbe080b0714@github.com> References: <1ekN1J37VwzFuw2U8XDt1wHq4otDlcjVubBp41YHHPs=.65f16011-4af4-4833-ad6e-8fbe080b0714@github.com> Message-ID: <-Np6zioYA05xDpy4izJXnPIy7usXftKkig-OqWrnWKk=.1214f798-21ca-41b3-8c58-bab987dbccb8@github.com> On Thu, 27 Jan 2022 09:55:04 GMT, Magnus Ihse Bursie wrote: >> This patch adds special handling of Backports for a couple of historic releases where we have 30 or more builds (and no BPRs). > > jbs/src/main/java/org/openjdk/skara/jbs/Backports.java line 320: > >> 318: if (resolvedInBuildNumber < 30) { >> 319: ret.add(jdkVersion.feature()); >> 320: } else if (resolvedInBuildNumber < 60) { > > In the JBS comment you stated that the spec says BPR builds should only be < 39. Did you chose not to change the current formulation, or did you forget? I initially changed this to 40, as the specification we have says BPR between 30 and 39. The problem is that this leaves a gap between 40 and 59 which is undefined. Builds 60 and up are special and should never be considered for hgupdate-sync, but after contemplating this, I agree with the original author's conclusion that the best way to deal with 40-59 is to assume they are also BPRs. In reality, I don't think we have any release with builds in that range, so it doesn't actually matter. ------------- PR: https://git.openjdk.java.net/skara/pull/1280 From erik.joelsson at oracle.com Thu Jan 27 14:51:25 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 27 Jan 2022 06:51:25 -0800 Subject: [External] : Possible improvements to /clean command In-Reply-To: References: Message-ID: <94327b2c-a470-768f-6a89-719c4cf52638@oracle.com> Please file a bug/enhancement on SKARA. I agree that at least the clean command is missing some crucial functionality for removing the label. Please understand that resourcing for Skara features is thin, so I can't promise when or if this will be fixed. /Erik On 2022-01-27 04:05, Lindenmaier, Goetz wrote: > > Hi, > > we encountered the following situation: > > A backport was made, clean except for the Copyright issues. > > So the /clean command was used on the PR. > > After this, an additional fix was pushed to the backport. > > Now, there are significant changes, it is no more clean. > > But as the /clean command was used, the change is > > still marked as clean. > > Is it possible to adapt the bots so that a /clean command > > is revoked after any further pushes? > > Example: https://github.com/openjdk/jdk11u-dev/pull/796 > > > I also tried using the /reviewers 1 command, but that neither > > removed the clean nor the ready label. > > Eventually the bots are still working on it at time of writing > > this? > > Best regards, > > ? Goetz. > From ihse at openjdk.java.net Thu Jan 27 14:54:49 2022 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 27 Jan 2022 14:54:49 GMT Subject: RFR: 1329: incorrect hgupdate label for JDK 7 updates In-Reply-To: <-Np6zioYA05xDpy4izJXnPIy7usXftKkig-OqWrnWKk=.1214f798-21ca-41b3-8c58-bab987dbccb8@github.com> References: <1ekN1J37VwzFuw2U8XDt1wHq4otDlcjVubBp41YHHPs=.65f16011-4af4-4833-ad6e-8fbe080b0714@github.com> <-Np6zioYA05xDpy4izJXnPIy7usXftKkig-OqWrnWKk=.1214f798-21ca-41b3-8c58-bab987dbccb8@github.com> Message-ID: On Thu, 27 Jan 2022 14:46:16 GMT, Erik Joelsson wrote: >> jbs/src/main/java/org/openjdk/skara/jbs/Backports.java line 320: >> >>> 318: if (resolvedInBuildNumber < 30) { >>> 319: ret.add(jdkVersion.feature()); >>> 320: } else if (resolvedInBuildNumber < 60) { >> >> In the JBS comment you stated that the spec says BPR builds should only be < 39. Did you chose not to change the current formulation, or did you forget? > > I initially changed this to 40, as the specification we have says BPR between 30 and 39. The problem is that this leaves a gap between 40 and 59 which is undefined. Builds 60 and up are special and should never be considered for hgupdate-sync, but after contemplating this, I agree with the original author's conclusion that the best way to deal with 40-59 is to assume they are also BPRs. In reality, I don't think we have any release with builds in that range, so it doesn't actually matter. That's okay for me. Just wanted to check that this was a conscious decision. (Maybe perhaps it should be commented upon in the code?) ------------- PR: https://git.openjdk.java.net/skara/pull/1280 From erikj at openjdk.java.net Thu Jan 27 20:10:15 2022 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 27 Jan 2022 20:10:15 GMT Subject: Integrated: 1329: incorrect hgupdate label for JDK 7 updates In-Reply-To: References: Message-ID: <4vpUxoge-fwZb-tkpzIKJ9N8tDlVIEiRrHexNBuBWVE=.8e9ce265-f83b-496b-b9a1-52ed04295da3@github.com> On Wed, 26 Jan 2022 20:16:23 GMT, Erik Joelsson wrote: > This patch adds special handling of Backports for a couple of historic releases where we have 30 or more builds (and no BPRs). This pull request has now been integrated. Changeset: 39785f26 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/39785f26f571cb64ddc43d9776081b53833a90e8 Stats: 64 lines in 2 files changed: 54 ins; 2 del; 8 mod 1329: incorrect hgupdate label for JDK 7 updates Reviewed-by: ihse ------------- PR: https://git.openjdk.java.net/skara/pull/1280