From erik.joelsson at oracle.com Tue Jun 1 17:39:55 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 1 Jun 2021 10:39:55 -0700 Subject: Result: New Skara Reviewer: Kevin Rushforth Message-ID: <49c5b2d8-8010-52c7-8e44-ebdcee662a1f@oracle.com> Voting for Kevin Rushforth [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Three-Vote Consensus, this is sufficient to approve the nomination. Erik Joelsson [1] https://mail.openjdk.java.net/pipermail/skara-dev/2021-May/004896.html From erikj at openjdk.java.net Tue Jun 1 18:05:06 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 1 Jun 2021 18:05:06 GMT Subject: Integrated: 1031: Declare Skara 1.0 In-Reply-To: References: Message-ID: On Fri, 28 May 2021 19:30:06 GMT, Erik Joelsson wrote: > This patch updates the version field in .jcheck/conf to 1.0. We do this to declare that Skara is now considered feature complete and will go into maintenance mode. We will continue to fix issues, but we will not be focusing on any new features in the foreseeable future. This pull request has now been integrated. Changeset: 2cc74365 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/2cc74365b383563c1067ee0b5ea890f7e122cc86 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1031: Declare Skara 1.0 Reviewed-by: iris, darcy ------------- PR: https://git.openjdk.java.net/skara/pull/1176 From erikj at openjdk.java.net Tue Jun 1 20:10:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 1 Jun 2021 20:10:44 GMT Subject: RFR: 1065: New prometheus labels have illegal characters Message-ID: This patch changes the metrics label name work-item to work_item. In prometheus, dash '-' is not a valid character for label names. ------------- Commit messages: - SKARA-1065 Changes: https://git.openjdk.java.net/skara/pull/1179/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1179&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1065 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1179.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1179/head:pull/1179 PR: https://git.openjdk.java.net/skara/pull/1179 From kcr at openjdk.java.net Wed Jun 2 15:39:04 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 15:39:04 GMT Subject: RFR: 1065: New prometheus labels have illegal characters In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 20:07:28 GMT, Erik Joelsson wrote: > This patch changes the metrics label name work-item to work_item. In prometheus, dash '-' is not a valid character for label names. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1179 From erikj at openjdk.java.net Wed Jun 2 18:12:37 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 18:12:37 GMT Subject: Integrated: 1065: New prometheus labels have illegal characters In-Reply-To: References: Message-ID: On Tue, 1 Jun 2021 20:07:28 GMT, Erik Joelsson wrote: > This patch changes the metrics label name work-item to work_item. In prometheus, dash '-' is not a valid character for label names. This pull request has now been integrated. Changeset: 8998a077 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/8998a0771cabff68290c2a3a481e8e1ba9178b4a Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod 1065: New prometheus labels have illegal characters Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1179 From tbell at openjdk.java.net Wed Jun 2 19:54:48 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Wed, 2 Jun 2021 19:54:48 GMT Subject: RFR: 1056: Mirror service is no longer syncing tags In-Reply-To: References: Message-ID: On Fri, 28 May 2021 21:54:05 GMT, Erik Joelsson wrote: > We currently have two modes of mirroring repositories using the MirrorBot, either a set of branches, or everything. When limiting branches, tags are excluded, and when mirroring everything, tags are included. > > I'm adding a new configuration option "tags": true/false. The purpose is to be able to include tags when only mirroring a set of branches. Default is false (to mimic current behavior). I can't see a use case for being able to exclude tags in the all branches case, and implementing it would add quite a bit of complexity. Marked as reviewed by tbell (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1177 From tbell at openjdk.java.net Wed Jun 2 19:56:48 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Wed, 2 Jun 2021 19:56:48 GMT Subject: RFR: 1051: JCheck complains about issue already used In-Reply-To: References: Message-ID: On Fri, 28 May 2021 23:16:12 GMT, Erik Joelsson wrote: > The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. Marked as reviewed by tbell (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1178 From kcr at openjdk.java.net Wed Jun 2 20:35:58 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 20:35:58 GMT Subject: RFR: 1051: JCheck complains about issue already used In-Reply-To: References: Message-ID: On Fri, 28 May 2021 23:16:12 GMT, Erik Joelsson wrote: > The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. Looks good with one minor suggestion. jcheck/src/main/java/org/openjdk/skara/jcheck/DuplicateIssuesCheck.java line 77: > 75: for (var issue : message.issues()) { > 76: var hashes = issuesToHashes.get(issue.id()); > 77: if (hashes != null) { You can save the additional process if `hashes.size()` is 1, so I recommend leaving this test as it was before: if (hashes != null && hashes.size() > 1) { ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1178 From kcr at openjdk.java.net Wed Jun 2 20:43:20 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 20:43:20 GMT Subject: RFR: 1056: Mirror service is no longer syncing tags In-Reply-To: References: Message-ID: <22G3DLputfpp0Nw5Jdz43ro64QIaM393cWqHgOCdu98=.62d55b3e-33b0-408f-a3b6-4d6bb75af7d5@github.com> On Fri, 28 May 2021 21:54:05 GMT, Erik Joelsson wrote: > We currently have two modes of mirroring repositories using the MirrorBot, either a set of branches, or everything. When limiting branches, tags are excluded, and when mirroring everything, tags are included. > > I'm adding a new configuration option "tags": true/false. The purpose is to be able to include tags when only mirroring a set of branches. Default is false (to mimic current behavior). I can't see a use case for being able to exclude tags in the all branches case, and implementing it would add quite a bit of complexity. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1177 From erikj at openjdk.java.net Wed Jun 2 20:50:31 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 20:50:31 GMT Subject: RFR: 1051: JCheck complains about issue already used In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:31:37 GMT, Kevin Rushforth wrote: >> The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. > > jcheck/src/main/java/org/openjdk/skara/jcheck/DuplicateIssuesCheck.java line 77: > >> 75: for (var issue : message.issues()) { >> 76: var hashes = issuesToHashes.get(issue.id()); >> 77: if (hashes != null) { > > You can save the additional processing if `hashes.size()` is 1, so I recommend leaving this test as it was before: > > > if (hashes != null && hashes.size() > 1) { Good point. ------------- PR: https://git.openjdk.java.net/skara/pull/1178 From erikj at openjdk.java.net Wed Jun 2 20:53:22 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 20:53:22 GMT Subject: Integrated: 1056: Mirror service is no longer syncing tags In-Reply-To: References: Message-ID: <3CSBGyXwPSa5xcsDy4MPByLblfC-Xt_a1XHkg0ATH44=.a3037386-2039-42fb-8242-b031af3f59cc@github.com> On Fri, 28 May 2021 21:54:05 GMT, Erik Joelsson wrote: > We currently have two modes of mirroring repositories using the MirrorBot, either a set of branches, or everything. When limiting branches, tags are excluded, and when mirroring everything, tags are included. > > I'm adding a new configuration option "tags": true/false. The purpose is to be able to include tags when only mirroring a set of branches. Default is false (to mimic current behavior). I can't see a use case for being able to exclude tags in the all branches case, and implementing it would add quite a bit of complexity. This pull request has now been integrated. Changeset: f8e97f7a Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/f8e97f7a9b501f754f870ca753957307c6858ab4 Stats: 158 lines in 6 files changed: 146 ins; 0 del; 12 mod 1056: Mirror service is no longer syncing tags Reviewed-by: tbell, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1177 From erikj at openjdk.java.net Wed Jun 2 20:59:14 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 20:59:14 GMT Subject: RFR: 1051: JCheck complains about issue already used [v2] In-Reply-To: References: Message-ID: > The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Restore size check ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1178/files - new: https://git.openjdk.java.net/skara/pull/1178/files/1ca68381..bd9cf8a0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1178&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1178&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1178.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1178/head:pull/1178 PR: https://git.openjdk.java.net/skara/pull/1178 From erikj at openjdk.java.net Wed Jun 2 20:59:15 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 20:59:15 GMT Subject: Integrated: 1051: JCheck complains about issue already used In-Reply-To: References: Message-ID: On Fri, 28 May 2021 23:16:12 GMT, Erik Joelsson wrote: > The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. This pull request has now been integrated. Changeset: bce5f6f9 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/bce5f6f961069f49b340c0969bc76a7602e05f56 Stats: 48 lines in 2 files changed: 45 ins; 0 del; 3 mod 1051: JCheck complains about issue already used Reviewed-by: tbell, kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1178 From kcr at openjdk.java.net Wed Jun 2 20:59:15 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 20:59:15 GMT Subject: RFR: 1051: JCheck complains about issue already used [v2] In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 20:56:29 GMT, Erik Joelsson wrote: >> The DuplicateIssuesCheck can sometimes report false positives when the same issueId has been used in separate branches. This patch fixes the check so that only commits that are ancestors of the commit being checked are considered. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Restore size check Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1178 From erikj at openjdk.java.net Wed Jun 2 23:16:00 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 2 Jun 2021 23:16:00 GMT Subject: RFR: 1063: Lower log severity on HTTP errors Message-ID: The Skara bots currently log all HTTP errors as SEVERE. With the log configuration we use, this results in admin alarms being sent whenever this happens (with some throttling). Now that we have metrics, we should instead leverage those and rely on alarms from our metrics gathering system instead. Typically HTTP errors aren't severe on their own, but if we get a lot of them, across multiple bot runners, then we need to react. This patch does the following: 1. Introduces a new specific exception which the RestRequest class throws when a bad HTTP response code is received. 2. Changes the logging behavior in the BotRunner when this new exception is caught. 3. Improves the logging of bad RestRequests so we actually log the request (instead of just the class name of the RequestBuilder). 4. Adds a new label on the skara_http_response counter to track if an error code was handled or not. We have a defined way of handling a bad HTTP response, and if this was used, we shouldn't send alarms as it's expected behavior. 5. Applies the http counters in two places where they were currently missing. ------------- Commit messages: - Add class name to toString - SKARA-1063 Changes: https://git.openjdk.java.net/skara/pull/1180/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1180&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1063 Stats: 43 lines in 3 files changed: 37 ins; 1 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1180.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1180/head:pull/1180 PR: https://git.openjdk.java.net/skara/pull/1180 From kcr at openjdk.java.net Wed Jun 2 23:23:32 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 2 Jun 2021 23:23:32 GMT Subject: RFR: 1063: Lower log severity on HTTP errors In-Reply-To: References: Message-ID: <_3g0ze4qIbLywEjOWasqBjXcK43brivQ-NNVl6x6aXo=.3b8e2ad2-cb97-46ec-9bb3-0642bd97038f@github.com> On Wed, 2 Jun 2021 23:12:32 GMT, Erik Joelsson wrote: > The Skara bots currently log all HTTP errors as SEVERE. With the log configuration we use, this results in admin alarms being sent whenever this happens (with some throttling). Now that we have metrics, we should instead leverage those and rely on alarms from our metrics gathering system instead. Typically HTTP errors aren't severe on their own, but if we get a lot of them, across multiple bot runners, then we need to react. > > This patch does the following: > > 1. Introduces a new specific exception which the RestRequest class throws when a bad HTTP response code is received. > 2. Changes the logging behavior in the BotRunner when this new exception is caught. > 3. Improves the logging of bad RestRequests so we actually log the request (instead of just the class name of the RequestBuilder). > 4. Adds a new label on the skara_http_response counter to track if an error code was handled or not. We have a defined way of handling a bad HTTP response, and if this was used, we shouldn't send alarms as it's expected behavior. > 5. Applies the http counters in two places where they were currently missing. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1180 From erikj at openjdk.java.net Thu Jun 3 13:46:01 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 13:46:01 GMT Subject: Integrated: 1063: Lower log severity on HTTP errors In-Reply-To: References: Message-ID: On Wed, 2 Jun 2021 23:12:32 GMT, Erik Joelsson wrote: > The Skara bots currently log all HTTP errors as SEVERE. With the log configuration we use, this results in admin alarms being sent whenever this happens (with some throttling). Now that we have metrics, we should instead leverage those and rely on alarms from our metrics gathering system instead. Typically HTTP errors aren't severe on their own, but if we get a lot of them, across multiple bot runners, then we need to react. > > This patch does the following: > > 1. Introduces a new specific exception which the RestRequest class throws when a bad HTTP response code is received. > 2. Changes the logging behavior in the BotRunner when this new exception is caught. > 3. Improves the logging of bad RestRequests so we actually log the request (instead of just the class name of the RequestBuilder). > 4. Adds a new label on the skara_http_response counter to track if an error code was handled or not. We have a defined way of handling a bad HTTP response, and if this was used, we shouldn't send alarms as it's expected behavior. > 5. Applies the http counters in two places where they were currently missing. This pull request has now been integrated. Changeset: 8e3c563a Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/8e3c563aea20761a350c997552dbde577f865517 Stats: 43 lines in 3 files changed: 37 ins; 1 del; 5 mod 1063: Lower log severity on HTTP errors Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1180 From erikj at openjdk.java.net Thu Jun 3 21:36:01 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 3 Jun 2021 21:36:01 GMT Subject: RFR: 1028: Skara notify bot fails to retry if JBS update fails at the wrong time Message-ID: This patch makes the JBS notifier more resilient to failures. The Notify bot has to deal with different kinds of listeners, some which can handle repeated calls with the same notification (typically JBS) and some which can not (mail, slack). This is currently handled in a less than ideal way. Each notification is recorded in a history repo to avoid repeating it and limit reevaluation of potential notifications. If all listeners could handle repeat notifications, we would simply notify first, and update the history after. That would guarantee that every notification was eventually sent even if there was a failure. The problem is that we don't want any risk of things like emails being sent multiple times. So the current solution is to update the history first, and then notify the listener. If there is a recoverable failure, we then attempt to roll back. This works most of the time, but we have seen situations where bad timing causes JBS bugs to not be updated, requiring manual admin work to fix. The solution I present here is a new property of the listener "idempotent". If true, the notifier will call the listener first and update history after. If false it will employ the old strategy (and attempt the rollback unless a NonRetriableException is thrown). The code gets quite messy so I tried to explain all this in a big class comment. I didn't write any new tests for this as I can't think of a way to explicitly test the race with a failure. The exiting tests should be good enough. ------------- Commit messages: - SKARA-1028 Changes: https://git.openjdk.java.net/skara/pull/1181/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1181&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1028 Stats: 91 lines in 7 files changed: 82 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/skara/pull/1181.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1181/head:pull/1181 PR: https://git.openjdk.java.net/skara/pull/1181 From kcr at openjdk.java.net Fri Jun 4 12:07:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 12:07:16 GMT Subject: RFR: 1028: Skara notify bot fails to retry if JBS update fails at the wrong time In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:32:45 GMT, Erik Joelsson wrote: > This patch makes the JBS notifier more resilient to failures. The Notify bot has to deal with different kinds of listeners, some which can handle repeated calls with the same notification (typically JBS) and some which can not (mail, slack). This is currently handled in a less than ideal way. > > Each notification is recorded in a history repo to avoid repeating it and limit reevaluation of potential notifications. If all listeners could handle repeat notifications, we would simply notify first, and update the history after. That would guarantee that every notification was eventually sent even if there was a failure. The problem is that we don't want any risk of things like emails being sent multiple times. So the current solution is to update the history first, and then notify the listener. If there is a recoverable failure, we then attempt to roll back. This works most of the time, but we have seen situations where bad timing causes JBS bugs to not be updated, requiring manual admin work to fix. > > The solution I present here is a new property of the listener "idempotent". If true, the notifier will call the listener first and update history after. If false it will employ the old strategy (and attempt the rollback unless a NonRetriableException is thrown). The code gets quite messy so I tried to explain all this in a big class comment. > > I didn't write any new tests for this as I can't think of a way to explicitly test the race with a failure. The exiting tests should be good enough. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1181 From erikj at openjdk.java.net Fri Jun 4 22:24:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 4 Jun 2021 22:24:48 GMT Subject: RFR: 1070: An invalid /backport command target causes bot to fail endlessly Message-ID: If a user issues a /backport command on a commit on a repository that exists, but for which we haven't properly configured backports to work (they need a fork defined where the PR can be created from), we currently end up with endless failures. This patch adds handling of the situation by printing a helpful message for the user, which also includes a list of all valid repositories. ------------- Commit messages: - SKARA-1070 Changes: https://git.openjdk.java.net/skara/pull/1182/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1182&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1070 Stats: 65 lines in 3 files changed: 60 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1182.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1182/head:pull/1182 PR: https://git.openjdk.java.net/skara/pull/1182 From kcr at openjdk.java.net Fri Jun 4 22:58:07 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 4 Jun 2021 22:58:07 GMT Subject: RFR: 1070: An invalid /backport command target causes bot to fail endlessly In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 22:21:31 GMT, Erik Joelsson wrote: > If a user issues a /backport command on a commit on a repository that exists, but for which we haven't properly configured backports to work (they need a fork defined where the PR can be created from), we currently end up with endless failures. This patch adds handling of the situation by printing a helpful message for the user, which also includes a list of all valid repositories. Looks good. I made a suggestion (for a follow-up). bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 113: > 111: reply.print("@" + username + " [" + repoName + "](" + targetRepo.webUrl() + ") is not a valid target for backports. "); > 112: reply.print("List of valid repositories: "); > 113: reply.println(String.join(", ", bot.forkRepoNames())); Should this be further filtered to only list repos that have the same "base" (share some commits) as the source repo? For example, if we some day configure one of the `jfx` or `jmc` update release repos to allow backport APIs, you wouldn't want to target it from a commit in the `jdk` repo, so listing those repos could be confusing. This could be done as a follow-up, since it is only a hypothetical problem for now. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1182 From erikj at openjdk.java.net Mon Jun 7 12:45:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 12:45:39 GMT Subject: RFR: 1070: An invalid /backport command target causes bot to fail endlessly In-Reply-To: References: Message-ID: On Fri, 4 Jun 2021 22:54:18 GMT, Kevin Rushforth wrote: >> If a user issues a /backport command on a commit on a repository that exists, but for which we haven't properly configured backports to work (they need a fork defined where the PR can be created from), we currently end up with endless failures. This patch adds handling of the situation by printing a helpful message for the user, which also includes a list of all valid repositories. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 113: > >> 111: reply.print("@" + username + " [" + repoName + "](" + targetRepo.webUrl() + ") is not a valid target for backports. "); >> 112: reply.print("List of valid repositories: "); >> 113: reply.println(String.join(", ", bot.forkRepoNames())); > > Should this be further filtered to only list repos that have the same "base" (share some commits) as the source repo? For example, if we some day configure one of the `jfx` or `jmc` update release repos to allow backport APIs, you wouldn't want to target it from a commit in the `jdk` repo, so listing those repos could be confusing. This could be done as a follow-up, since it is only a hypothetical problem for now. I agree that it would be much better to filter the list of repos, but I'm not sure how to easily implement this. I figured this list was easily available and better than nothing. ------------- PR: https://git.openjdk.java.net/skara/pull/1182 From erikj at openjdk.java.net Mon Jun 7 13:13:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 13:13:48 GMT Subject: Integrated: 1070: An invalid /backport command target causes bot to fail endlessly In-Reply-To: References: Message-ID: <-zpGixUk4pUgmDamPzmomSOtFM0o1KDp4zrU1Fn8q5o=.4194412c-815b-4794-b8b3-e5f907c9f0f0@github.com> On Fri, 4 Jun 2021 22:21:31 GMT, Erik Joelsson wrote: > If a user issues a /backport command on a commit on a repository that exists, but for which we haven't properly configured backports to work (they need a fork defined where the PR can be created from), we currently end up with endless failures. This patch adds handling of the situation by printing a helpful message for the user, which also includes a list of all valid repositories. This pull request has now been integrated. Changeset: 2b30c7e0 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/2b30c7e0cd2063fa7a658772cada5c1ffd6ba797 Stats: 65 lines in 3 files changed: 60 ins; 0 del; 5 mod 1070: An invalid /backport command target causes bot to fail endlessly Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1182 From erikj at openjdk.java.net Mon Jun 7 21:49:50 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 21:49:50 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push Message-ID: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. ------------- Commit messages: - SKARA-1069 Changes: https://git.openjdk.java.net/skara/pull/1183/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1183&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1069 Stats: 261 lines in 5 files changed: 242 ins; 14 del; 5 mod Patch: https://git.openjdk.java.net/skara/pull/1183.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1183/head:pull/1183 PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Mon Jun 7 21:49:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 21:49:51 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Mon, 7 Jun 2021 21:44:02 GMT, Erik Joelsson wrote: > This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. > > The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. > > I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 127: > 125: > 126: // Run a final jcheck to ensure the change has been properly reviewed > 127: var success = false; This variable was dead. bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 196: > 194: } > 195: > 196: var backportLines = allComments This is a slight optimization. We already have a list of all comments, so no need to reach out to github to fetch them again. I can't see any need in this situation to refresh either. forge/src/main/java/org/openjdk/skara/forge/PullRequestUtils.java line 166: > 164: } > 165: > 166: public static boolean isAncestorOfTarget(Repository localRepo, Hash hash) throws IOException { I put this in the utils class because it needs the "prutils_tagetref" reference, which is currently only used in this class. ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Mon Jun 7 23:12:39 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 7 Jun 2021 23:12:39 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR Message-ID: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. ------------- Commit messages: - SKARA-1072 Changes: https://git.openjdk.java.net/skara/pull/1184/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1184&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1072 Stats: 102 lines in 2 files changed: 89 ins; 7 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1184.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1184/head:pull/1184 PR: https://git.openjdk.java.net/skara/pull/1184 From kcr at openjdk.java.net Mon Jun 7 23:20:41 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 23:20:41 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR In-Reply-To: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: On Mon, 7 Jun 2021 23:09:25 GMT, Erik Joelsson wrote: > Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. > > While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232: > 230: if (m.matches()) { > 231: var hash = new Hash(m.group(1)); > 232: if (pr.headHash().equals(hash)) { Isn't it the hash of the first commit in the PR, rather than the HEAD commit of the PR, that is likely to cause the problem? In case there is more than one commit in the PR, might it be better to check whether it is an ancestor of the HEAD commit? ------------- PR: https://git.openjdk.java.net/skara/pull/1184 From kcr at openjdk.java.net Mon Jun 7 23:36:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 23:36:08 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Mon, 7 Jun 2021 21:44:02 GMT, Erik Joelsson wrote: > This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. > > The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. > > I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. It looks OK to me. I added a couple inline questions. bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 233: > 231: var amendedHash = checkablePr.amendManualReviewers(localHash, censusInstance.namespace(), original); > 232: addPrePushComment(pr, amendedHash, rebaseMessage.toString()); > 233: localRepo.push(amendedHash, pr.repository().url(), pr.targetRef()); If the push fails and the bot dies, will it still be retried after this fix? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1183 From kcr at openjdk.java.net Mon Jun 7 23:36:08 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 7 Jun 2021 23:36:08 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: <3OGzXDp8-GG9fsFWpjQHGyuqxGDNcO55HChux5Dc-EQ=.c51fd701-1afe-4c51-af79-27a0dd5dadaa@github.com> On Mon, 7 Jun 2021 21:45:03 GMT, Erik Joelsson wrote: >> This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. >> >> The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. >> >> I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 196: > >> 194: } >> 195: >> 196: var backportLines = allComments > > This is a slight optimization. We already have a list of all comments, so no need to reach out to github to fetch them again. I can't see any need in this situation to refresh either. So there's no need to ever refresh after acquiring the integration lock? ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Tue Jun 8 13:43:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 13:43:26 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: <3OGzXDp8-GG9fsFWpjQHGyuqxGDNcO55HChux5Dc-EQ=.c51fd701-1afe-4c51-af79-27a0dd5dadaa@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> <3OGzXDp8-GG9fsFWpjQHGyuqxGDNcO55HChux5Dc-EQ=.c51fd701-1afe-4c51-af79-27a0dd5dadaa@github.com> Message-ID: <77U-Y9OOUcY2VuaZ5rAIwqBqE3XhYzzb0kJAh6JxAs8=.84552a15-c123-425a-b0cd-1e90badaafdb@github.com> On Mon, 7 Jun 2021 23:23:16 GMT, Kevin Rushforth wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 196: >> >>> 194: } >>> 195: >>> 196: var backportLines = allComments >> >> This is a slight optimization. We already have a list of all comments, so no need to reach out to github to fetch them again. I can't see any need in this situation to refresh either. > > So there's no need to ever refresh after acquiring the integration lock? Not sure, I don't think the IntegrationLock is relevant for this, as it's not involved in the CheckWorkItem where this comment would potentially be created, but maybe I should still leave this alone as I'm not sure about how the concurrency could play out here. Investigating this made me discover that there is a duplicate implementation of this whole thing in the SponsorCommand that I need to address. ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Tue Jun 8 13:46:26 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 13:46:26 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Mon, 7 Jun 2021 23:25:03 GMT, Kevin Rushforth wrote: >> This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. >> >> The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. >> >> I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 233: > >> 231: var amendedHash = checkablePr.amendManualReviewers(localHash, censusInstance.namespace(), original); >> 232: addPrePushComment(pr, amendedHash, rebaseMessage.toString()); >> 233: localRepo.push(amendedHash, pr.repository().url(), pr.targetRef()); > > If the push fails and the bot dies, will it still be retried after this fix? Yes, that's the idea at least, but I should write a test for it. If the push fails, the next time around, the prepush comment is found, but the hash is not found in the target, so the IntegrationCommand will continue as if nothing has happened. ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Tue Jun 8 18:52:40 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 18:52:40 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR In-Reply-To: References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: On Mon, 7 Jun 2021 23:18:13 GMT, Kevin Rushforth wrote: >> Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. >> >> While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 232: > >> 230: if (m.matches()) { >> 231: var hash = new Hash(m.group(1)); >> 232: if (pr.headHash().equals(hash)) { > > Isn't it the hash of the first commit in the PR, rather than the HEAD commit of the PR, that is likely to cause the problem? In case there is more than one commit in the PR, might it be better to check whether it is an ancestor of the HEAD commit? Right, if there are multiple changes in the PR branch, any one of them could potentially be the original change. Checking that is a bit more complicated though as I think it requires a local clone to inspect. I will need to investigate how best to solve it. ------------- PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Tue Jun 8 23:15:29 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 23:15:29 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR [v2] In-Reply-To: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: > Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. > > While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Check if backport hash is ancestor of PR change. Also check if a PR only contains changes already present in the target. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1184/files - new: https://git.openjdk.java.net/skara/pull/1184/files/136cb2fc..f0cfcfff Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1184&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1184&range=00-01 Stats: 78 lines in 4 files changed: 63 ins; 5 del; 10 mod Patch: https://git.openjdk.java.net/skara/pull/1184.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1184/head:pull/1184 PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Tue Jun 8 23:18:16 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 8 Jun 2021 23:18:16 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR [v2] In-Reply-To: References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: On Tue, 8 Jun 2021 23:15:29 GMT, Erik Joelsson wrote: >> Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. >> >> While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Check if backport hash is ancestor of PR change. Also check if a PR only contains changes already present in the target. As we found another instance of this issue, that instance highlighted another, related, problem. If a proposed backport (or any change for that matter, but backports seem more likely) has already been done, basically making the changes in the PR redundant when merged with the target, this wasn't handled well today. I have added a check for this as well. ------------- PR: https://git.openjdk.java.net/skara/pull/1184 From kcr at openjdk.java.net Tue Jun 8 23:34:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 8 Jun 2021 23:34:24 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR [v2] In-Reply-To: References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: <5EodLQAaO42iL8elvhsAguOq5Jzu9GMwMKUM9Jgouvg=.47834cbf-a2ca-4a37-b5cd-59f33e2f4f5b@github.com> On Tue, 8 Jun 2021 23:15:29 GMT, Erik Joelsson wrote: >> Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. >> >> While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Check if backport hash is ancestor of PR change. Also check if a PR only contains changes already present in the target. Looks good. Did you want to add a test where the specified backport hash was a commit in the PR other than the head? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Wed Jun 9 15:01:17 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 15:01:17 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR [v3] In-Reply-To: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: > Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. > > While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1184/files - new: https://git.openjdk.java.net/skara/pull/1184/files/f0cfcfff..bb129b9e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1184&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1184&range=01-02 Stats: 72 lines in 1 file changed: 72 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1184.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1184/head:pull/1184 PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Wed Jun 9 15:01:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 15:01:18 GMT Subject: RFR: 1072: Skara should validate the commit hash of a Backport PR [v2] In-Reply-To: References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: On Tue, 8 Jun 2021 23:15:29 GMT, Erik Joelsson wrote: >> Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. >> >> While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Check if backport hash is ancestor of PR change. Also check if a PR only contains changes already present in the target. Added test as asked. ------------- PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Wed Jun 9 15:01:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 15:01:18 GMT Subject: Integrated: 1072: Skara should validate the commit hash of a Backport PR In-Reply-To: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> References: <1aLfqj5kjcwAiyAMZkzU-GmM1H0H3-X7q9PFdYc_x6M=.eb8bfafe-95e7-4712-a3b2-6068c9dbb0bf@github.com> Message-ID: On Mon, 7 Jun 2021 23:09:25 GMT, Erik Joelsson wrote: > Add a check for "Backport " titles that the given hash isn't the head of the PR itself. If the user mistakenly uses that hash, Skara is very likely to get fooled into thinking the backport is clean. > > While investigating this, I also discovered that the CheckWorkItem was inconsistent with not repeating "backport" errors, so I implemented a general mechanism for this, which guarantees that the same exact error message is never repeated. I believe this will be good enough, and certainly better than the existing behavior. This pull request has now been integrated. Changeset: 5b081a79 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/5b081a7954c53ecb9e74fea4a89b039885677fbe Stats: 244 lines in 4 files changed: 224 ins; 12 del; 8 mod 1072: Skara should validate the commit hash of a Backport PR Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1184 From erikj at openjdk.java.net Wed Jun 9 18:49:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 18:49:25 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push [v2] In-Reply-To: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: > This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. > > The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. > > I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. 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: - Review comments and fix SponsorCommand - Merge branch 'master' into SKARA-1069-push-interrupt - SKARA-1069 ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1183/files - new: https://git.openjdk.java.net/skara/pull/1183/files/746585dc..fd4a8831 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1183&range=00-01 Stats: 602 lines in 11 files changed: 515 ins; 58 del; 29 mod Patch: https://git.openjdk.java.net/skara/pull/1183.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1183/head:pull/1183 PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Wed Jun 9 18:49:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 18:49:25 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Mon, 7 Jun 2021 21:44:02 GMT, Erik Joelsson wrote: > This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. > > The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. > > I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. Adding new patch addressing review comments. Reverted the allComments change. Added testing of interruption between posting the prepush comment and doing the push. The big change here is I discovered the SponsorCommand had a lot of duplicate code that needed to be updated in the same way. The Skara codebase seem to shun inheritance to share logic, so I tried to just move some things to static methods on IntegrateCommand and have SponsorCommand call them when suitable. There are more duplicates that could be given the same treatment, but I tried to limit the changes here to what was relevant for this fix. I'm thinking a super class could help a lot here in a future change. I also duplicated the main test I wrote from IntegrateTests to SponsorTests to verify the same behaviors since we have two almost identical code paths for the same thing. ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From kcr at openjdk.java.net Wed Jun 9 20:10:55 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Wed, 9 Jun 2021 20:10:55 GMT Subject: RFR: 1069: PR ends up in bad state if interrupted just after push [v2] In-Reply-To: References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Wed, 9 Jun 2021 18:49:25 GMT, Erik Joelsson wrote: >> This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. >> >> The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. >> >> I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. > > 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: > > - Review comments and fix SponsorCommand > - Merge branch 'master' into SKARA-1069-push-interrupt > - SKARA-1069 Looks good as far as I can tell. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Wed Jun 9 20:52:51 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 9 Jun 2021 20:52:51 GMT Subject: Integrated: 1069: PR ends up in bad state if interrupted just after push In-Reply-To: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> References: <8u_A3gD6anP-I4Q3U-8wGA00fqDxwZF1Qgt3A_qKzHQ=.716ee52d-41aa-4577-93fa-8156b3248f86@github.com> Message-ID: On Mon, 7 Jun 2021 21:44:02 GMT, Erik Joelsson wrote: > This change adds a new transaction step when integrating a PR, to better handle if the bot gets interrupted mid integration. Currently, if the change is pushed and the bot is interrupted before closing, changing labels or adding the final "commit pushed" comment, the PR can end up in a limbo state. > > The new step is another comment "Going to push commit as ..." which gets added right before the git push command is run. Using this comment, it's now possible to automatically recover if the bot gets interrupted. The integration command checks for any such comments and if found, checks if the commit hash is present in the target. If it is, the PR was already pushed, and the command will just close it out as normal. > > I also decided to move the output of any rebase command to this prepush comment, so we don't risk losing it. This pull request has now been integrated. Changeset: 3091beec Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/3091beece5098928a554ad4dc5226259869da233 Stats: 487 lines in 7 files changed: 445 ins; 32 del; 10 mod 1069: PR ends up in bad state if interrupted just after push Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1183 From erikj at openjdk.java.net Thu Jun 10 19:26:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 10 Jun 2021 19:26:42 GMT Subject: Integrated: 1028: Skara notify bot fails to retry if JBS update fails at the wrong time In-Reply-To: References: Message-ID: On Thu, 3 Jun 2021 21:32:45 GMT, Erik Joelsson wrote: > This patch makes the JBS notifier more resilient to failures. The Notify bot has to deal with different kinds of listeners, some which can handle repeated calls with the same notification (typically JBS) and some which can not (mail, slack). This is currently handled in a less than ideal way. > > Each notification is recorded in a history repo to avoid repeating it and limit reevaluation of potential notifications. If all listeners could handle repeat notifications, we would simply notify first, and update the history after. That would guarantee that every notification was eventually sent even if there was a failure. The problem is that we don't want any risk of things like emails being sent multiple times. So the current solution is to update the history first, and then notify the listener. If there is a recoverable failure, we then attempt to roll back. This works most of the time, but we have seen situations where bad timing causes JBS bugs to not be updated, requiring manual admin work to fix. > > The solution I present here is a new property of the listener "idempotent". If true, the notifier will call the listener first and update history after. If false it will employ the old strategy (and attempt the rollback unless a NonRetriableException is thrown). The code gets quite messy so I tried to explain all this in a big class comment. > > I didn't write any new tests for this as I can't think of a way to explicitly test the race with a failure. The exiting tests should be good enough. This pull request has now been integrated. Changeset: 67f40c7c Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/67f40c7c05faa544b2bc3f3807bd9e771b1c6b0d Stats: 91 lines in 7 files changed: 82 ins; 0 del; 9 mod 1028: Skara notify bot fails to retry if JBS update fails at the wrong time Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1181 From erikj at openjdk.java.net Thu Jun 10 21:30:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 10 Jun 2021 21:30:20 GMT Subject: RFR: Refactor and cleanup Message-ID: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> I have been working quite a bit in the area of the Integrate and SponsorCommand classes recently, and while doing so noted that they have a lot of duplicate code. Some of that I fixed, but I didn't want to include unrelated refactoring and cleanup in a functional change, so here is a separate change with just that. Nothing should change from a functional perspective. This change only touches a limited set of classes where I had noted specific issues. Here is a breakdown of the changes. 1. Moved logic for finding the original change hash in a backport PR to the CheckablePullRequest class. All three locations where this was done already had an instance of this class, and that class has all the data needed for the operation, so seemed like a decent fit. 2. Put a lazily initialized wrapper of PullRequestUtils.targetHash(localRepo) in CheckablePullRequest. This method is called quite often, and each time it results in running a git command to resolve the hash from the ref name. When browsing logs, this git command is sprinkled all over the place so reducing it will improve both performance and log browsing. Unfortunately I can't figure out a good way to completely reduce it as PullRequestUtils is a static class and it calls this method quite a bit itself. 3. Moved a duplicate piece of code (for running and reacting to jcheck checks) in IntegrateCommand.handle() and SponsorCommand.handle() to a new static method in IntegrateCommand. I still didn't dare dabbling in a super class. 4. Removed all dead parameters and variables that I could find in these classes. 5. Applied some other Intellij suggested code fixes, like removing exceptions never thrown and unneeded calls to toString(). I also let it convert a switch statements to the new fancy switch expression, which looks a lot better. Finally I also let it introduce a text block (this happened because I had left Intellij in JDK 16 mode). I think this looks good enough to warrant a bump in required JDK version for the project. We run everything default with JDK 16 already, and I can't see a reason to stick with 14. JDK 15 should be just as accessible. ------------- Commit messages: - Refactor and cleanup Changes: https://git.openjdk.java.net/skara/pull/1185/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1185&range=00 Stats: 167 lines in 7 files changed: 49 ins; 62 del; 56 mod Patch: https://git.openjdk.java.net/skara/pull/1185.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1185/head:pull/1185 PR: https://git.openjdk.java.net/skara/pull/1185 From erikj at openjdk.java.net Thu Jun 10 23:36:04 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 10 Jun 2021 23:36:04 GMT Subject: RFR: Refactor and cleanup [v2] In-Reply-To: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> References: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> Message-ID: > I have been working quite a bit in the area of the Integrate and SponsorCommand classes recently, and while doing so noted that they have a lot of duplicate code. Some of that I fixed, but I didn't want to include unrelated refactoring and cleanup in a functional change, so here is a separate change with just that. Nothing should change from a functional perspective. This change only touches a limited set of classes where I had noted specific issues. Here is a breakdown of the changes. > > 1. Moved logic for finding the original change hash in a backport PR to the CheckablePullRequest class. All three locations where this was done already had an instance of this class, and that class has all the data needed for the operation, so seemed like a decent fit. > 2. Put a lazily initialized wrapper of PullRequestUtils.targetHash(localRepo) in CheckablePullRequest. This method is called quite often, and each time it results in running a git command to resolve the hash from the ref name. When browsing logs, this git command is sprinkled all over the place so reducing it will improve both performance and log browsing. Unfortunately I can't figure out a good way to completely reduce it as PullRequestUtils is a static class and it calls this method quite a bit itself. > 3. Moved a duplicate piece of code (for running and reacting to jcheck checks) in IntegrateCommand.handle() and SponsorCommand.handle() to a new static method in IntegrateCommand. I still didn't dare dabbling in a super class. > 4. Removed all dead parameters and variables that I could find in these classes. > 5. Applied some other Intellij suggested code fixes, like removing exceptions never thrown and unneeded calls to toString(). I also let it convert a switch statements to the new fancy switch expression, which looks a lot better. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Revert JDK 15 bump ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1185/files - new: https://git.openjdk.java.net/skara/pull/1185/files/49127d54..b934e265 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1185&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1185&range=00-01 Stats: 9 lines in 2 files changed: 0 ins; 3 del; 6 mod Patch: https://git.openjdk.java.net/skara/pull/1185.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1185/head:pull/1185 PR: https://git.openjdk.java.net/skara/pull/1185 From erikj at openjdk.java.net Thu Jun 10 23:36:05 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 10 Jun 2021 23:36:05 GMT Subject: RFR: Refactor and cleanup In-Reply-To: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> References: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> Message-ID: On Thu, 10 Jun 2021 21:27:17 GMT, Erik Joelsson wrote: > I have been working quite a bit in the area of the Integrate and SponsorCommand classes recently, and while doing so noted that they have a lot of duplicate code. Some of that I fixed, but I didn't want to include unrelated refactoring and cleanup in a functional change, so here is a separate change with just that. Nothing should change from a functional perspective. This change only touches a limited set of classes where I had noted specific issues. Here is a breakdown of the changes. > > 1. Moved logic for finding the original change hash in a backport PR to the CheckablePullRequest class. All three locations where this was done already had an instance of this class, and that class has all the data needed for the operation, so seemed like a decent fit. > 2. Put a lazily initialized wrapper of PullRequestUtils.targetHash(localRepo) in CheckablePullRequest. This method is called quite often, and each time it results in running a git command to resolve the hash from the ref name. When browsing logs, this git command is sprinkled all over the place so reducing it will improve both performance and log browsing. Unfortunately I can't figure out a good way to completely reduce it as PullRequestUtils is a static class and it calls this method quite a bit itself. > 3. Moved a duplicate piece of code (for running and reacting to jcheck checks) in IntegrateCommand.handle() and SponsorCommand.handle() to a new static method in IntegrateCommand. I still didn't dare dabbling in a super class. > 4. Removed all dead parameters and variables that I could find in these classes. > 5. Applied some other Intellij suggested code fixes, like removing exceptions never thrown and unneeded calls to toString(). I also let it convert a switch statements to the new fancy switch expression, which looks a lot better. I reverted the text block change and the bump of the required JDK version to 15. If we are to do that, it should be in a proper change. ------------- PR: https://git.openjdk.java.net/skara/pull/1185 From erikj at openjdk.java.net Fri Jun 11 18:05:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 18:05:53 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha Message-ID: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. ------------- Depends on: https://git.openjdk.java.net/skara/pull/1185 Commit messages: - sha -> hash - SKARA-1076 Changes: https://git.openjdk.java.net/skara/pull/1186/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1076 Stats: 148 lines in 2 files changed: 143 ins; 1 del; 4 mod Patch: https://git.openjdk.java.net/skara/pull/1186.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1186/head:pull/1186 PR: https://git.openjdk.java.net/skara/pull/1186 From kcr at openjdk.java.net Fri Jun 11 18:44:06 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Jun 2021 18:44:06 GMT Subject: RFR: Refactor and cleanup [v2] In-Reply-To: References: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> Message-ID: On Thu, 10 Jun 2021 23:36:04 GMT, Erik Joelsson wrote: >> I have been working quite a bit in the area of the Integrate and SponsorCommand classes recently, and while doing so noted that they have a lot of duplicate code. Some of that I fixed, but I didn't want to include unrelated refactoring and cleanup in a functional change, so here is a separate change with just that. Nothing should change from a functional perspective. This change only touches a limited set of classes where I had noted specific issues. Here is a breakdown of the changes. >> >> 1. Moved logic for finding the original change hash in a backport PR to the CheckablePullRequest class. All three locations where this was done already had an instance of this class, and that class has all the data needed for the operation, so seemed like a decent fit. >> 2. Put a lazily initialized wrapper of PullRequestUtils.targetHash(localRepo) in CheckablePullRequest. This method is called quite often, and each time it results in running a git command to resolve the hash from the ref name. When browsing logs, this git command is sprinkled all over the place so reducing it will improve both performance and log browsing. Unfortunately I can't figure out a good way to completely reduce it as PullRequestUtils is a static class and it calls this method quite a bit itself. >> 3. Moved a duplicate piece of code (for running and reacting to jcheck checks) in IntegrateCommand.handle() and SponsorCommand.handle() to a new static method in IntegrateCommand. I still didn't dare dabbling in a super class. >> 4. Removed all dead parameters and variables that I could find in these classes. >> 5. Applied some other Intellij suggested code fixes, like removing exceptions never thrown and unneeded calls to toString(). I also let it convert a switch statements to the new fancy switch expression, which looks a lot better. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Revert JDK 15 bump Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1185 From kcr at openjdk.java.net Fri Jun 11 18:56:23 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Jun 2021 18:56:23 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 18:02:28 GMT, Erik Joelsson wrote: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. Looks good. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 302: > 300: } > 301: > 302: // Check for a title on the form Backport Minor: "'of' the form ..."? bots/pr/src/test/java/org/openjdk/skara/bots/pr/BackportTests.java line 1458: > 1456: assertEquals(List.of(), message.contributors()); > 1457: assertEquals(List.of(), message.summaries()); > 1458: assertEquals(List.of(), message.additional()); It might be good to also check that the commit message does not contain "Backport of", or is this covered by checking that `message.additional()` is empty? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1186 From erikj at openjdk.java.net Fri Jun 11 19:52:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 19:52:21 GMT Subject: Integrated: Refactor and cleanup In-Reply-To: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> References: <4bLzAVw4jGLvsAma-bhKwUwINbuCTxJ7QfNHMjHlOTE=.f44bde01-2036-4927-b3ce-6f371dbf6c95@github.com> Message-ID: On Thu, 10 Jun 2021 21:27:17 GMT, Erik Joelsson wrote: > I have been working quite a bit in the area of the Integrate and SponsorCommand classes recently, and while doing so noted that they have a lot of duplicate code. Some of that I fixed, but I didn't want to include unrelated refactoring and cleanup in a functional change, so here is a separate change with just that. Nothing should change from a functional perspective. This change only touches a limited set of classes where I had noted specific issues. Here is a breakdown of the changes. > > 1. Moved logic for finding the original change hash in a backport PR to the CheckablePullRequest class. All three locations where this was done already had an instance of this class, and that class has all the data needed for the operation, so seemed like a decent fit. > 2. Put a lazily initialized wrapper of PullRequestUtils.targetHash(localRepo) in CheckablePullRequest. This method is called quite often, and each time it results in running a git command to resolve the hash from the ref name. When browsing logs, this git command is sprinkled all over the place so reducing it will improve both performance and log browsing. Unfortunately I can't figure out a good way to completely reduce it as PullRequestUtils is a static class and it calls this method quite a bit itself. > 3. Moved a duplicate piece of code (for running and reacting to jcheck checks) in IntegrateCommand.handle() and SponsorCommand.handle() to a new static method in IntegrateCommand. I still didn't dare dabbling in a super class. > 4. Removed all dead parameters and variables that I could find in these classes. > 5. Applied some other Intellij suggested code fixes, like removing exceptions never thrown and unneeded calls to toString(). I also let it convert a switch statements to the new fancy switch expression, which looks a lot better. This pull request has now been integrated. Changeset: 9371c001 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/9371c0019dfa81cbdf69f5d421da9748a5c8228a Stats: 158 lines in 6 files changed: 46 ins; 62 del; 50 mod Refactor and cleanup Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1185 From erikj at openjdk.java.net Fri Jun 11 19:54:18 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 19:54:18 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v2] In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. 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 five additional commits since the last revision: - Merge branch 'master' of https://git.openjdk.java.net/skara into SKARA-1076-backport-issue - sha -> hash - SKARA-1076 - Revert JDK 15 bump - Refactor and cleanup ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1186/files - new: https://git.openjdk.java.net/skara/pull/1186/files/41110916..df0b3d82 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1186.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1186/head:pull/1186 PR: https://git.openjdk.java.net/skara/pull/1186 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Fri Jun 11 19:54:19 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Fri, 11 Jun 2021 19:54:19 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 18:02:28 GMT, Erik Joelsson wrote: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. 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 refactor-pr 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/1186 From erikj at openjdk.java.net Fri Jun 11 19:59:49 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 19:59:49 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v3] In-Reply-To: References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 18:53:50 GMT, Kevin Rushforth wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > bots/pr/src/test/java/org/openjdk/skara/bots/pr/BackportTests.java line 1458: > >> 1456: assertEquals(List.of(), message.contributors()); >> 1457: assertEquals(List.of(), message.summaries()); >> 1458: assertEquals(List.of(), message.additional()); > > It might be good to also check that the commit message does not contain "Backport of", or is this covered by checking that `message.additional()` is empty? Good point. I just removed the assert for the existence of the original hash without thinking about inverting that assert. ------------- PR: https://git.openjdk.java.net/skara/pull/1186 From erikj at openjdk.java.net Fri Jun 11 19:59:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Fri, 11 Jun 2021 19:59:48 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v3] In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1186/files - new: https://git.openjdk.java.net/skara/pull/1186/files/df0b3d82..d119cc0c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=02 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=01-02 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/skara/pull/1186.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1186/head:pull/1186 PR: https://git.openjdk.java.net/skara/pull/1186 From kcr at openjdk.java.net Fri Jun 11 20:13:16 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 11 Jun 2021 20:13:16 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v3] In-Reply-To: References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 19:59:48 GMT, Erik Joelsson wrote: >> This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. >> >> To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1186 From kcr at openjdk.java.net Sat Jun 12 14:46:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Sat, 12 Jun 2021 14:46:52 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v3] In-Reply-To: References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 19:59:48 GMT, Erik Joelsson wrote: >> This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. >> >> To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I just thought of one more thing you might need to handle. In the JBS issue, you mentioned two things that the "backport" label is used for: 1. Whether to print the warning about the issue not being open. 2. Whether to allow the /clean command to be run to mark a backport "clean". For the case of no public SHA hash, Skara should not allow a Committer to declare it as clean. There isn't any way for anyone -- including the contributor -- to know whether or not it is clean. For the case being covered by this fix, there isn't a public patch to look at in the first place. ------------- PR: https://git.openjdk.java.net/skara/pull/1186 From lgxbslgx at gmail.com Sat Jun 12 15:26:46 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 12 Jun 2021 23:26:46 +0800 Subject: The pre-integration checks of the jtreg is not work Message-ID: Hi all, I submitted a PR[1] to the project `jtreg` just now. The bot reminds that `This change now passes all *automated* pre-integration checks` and checks the checkbox item `Change must be properly reviewed`. But actually, the patch has not been reviewed. Is it an issue about skara or/and jtreg config? Any ideas are appreciated. [1] https://github.com/openjdk/jtreg/pull/12 Best Regards, -- Guoxiong From philip.race at oracle.com Sat Jun 12 15:32:54 2021 From: philip.race at oracle.com (Philip Race) Date: Sat, 12 Jun 2021 08:32:54 -0700 Subject: The pre-integration checks of the jtreg is not work In-Reply-To: References: Message-ID: <3bfe69d6-acec-4ef4-b683-9b9bdd4c857e@oracle.com> It means the jtreg project isn't configured to require reviewers. But you won't be able to push since as the PR notes you aren't a committer in the project. You can type /integrate but then it needs to wait for a /sponsor. phil. On 6/12/21 8:26 AM, Guoxiong Li wrote: > Hi all, > > I submitted a PR[1] to the project `jtreg` just now. > The bot reminds that `This change now passes all *automated* pre-integration > checks` > and checks the checkbox item `Change must be properly reviewed`. > But actually, the patch has not been reviewed. > > Is it an issue about skara or/and jtreg config? > Any ideas are appreciated. > > [1] https://github.com/openjdk/jtreg/pull/12 > > Best Regards, > -- Guoxiong From lgxbslgx at gmail.com Sat Jun 12 15:35:48 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sat, 12 Jun 2021 23:35:48 +0800 Subject: The pre-integration checks of the project jtreg seem to be wrong Message-ID: Revising the title and resending. Please reply to this email. Hi all, I submitted a PR[1] to the project `jtreg` just now. The bot reminds that `This change now passes all *automated* pre-integration checks` and checks the checkbox item `Change must be properly reviewed`. But actually, the patch has not been reviewed. Is it an issue about skara or/and jtreg config? Any ideas are appreciated. [1] https://github.com/openjdk/jtreg/pull/12 Best Regards, -- Guoxiong From lgxbslgx at gmail.com Sun Jun 13 08:31:01 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Sun, 13 Jun 2021 16:31:01 +0800 Subject: The pre-integration checks of the project jtreg seem to be wrong In-Reply-To: <12ed319c-86ed-ed21-ddea-12c6d84f0fc4@oracle.com> References: <12ed319c-86ed-ed21-ddea-12c6d84f0fc4@oracle.com> Message-ID: Thanks Phil and Jon for your kind reply. I found the jcheck `conf` files of other projects[1][2] have the checks about reviewers: ``` [checks "reviewers"] reviewers=1 ``` But the jcheck `conf` file of the jtreg[3] doesn't have the similar item. Does it affect the bot? [1] https://github.com/openjdk/skara/blob/master/.jcheck/conf [2] https://github.com/openjdk/jmh/blob/master/.jcheck/conf [3] https://github.com/openjdk/jtreg/blob/master/.jcheck/conf Best Regards, -- Guoxiong On Sun, Jun 13, 2021 at 2:55 AM Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > It's probably a side-effect of the combination of Skara and the jtreg > configuration. > > I'll follow up with Skara folk. > > -- Jon > From erik.joelsson at oracle.com Mon Jun 14 13:01:20 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 14 Jun 2021 06:01:20 -0700 Subject: The pre-integration checks of the project jtreg seem to be wrong In-Reply-To: References: <12ed319c-86ed-ed21-ddea-12c6d84f0fc4@oracle.com> Message-ID: <16d7f0d8-eb7b-855f-1527-2a5324c13fce@oracle.com> On 2021-06-13 01:31, Guoxiong Li wrote: > Thanks Phil and Jon for your kind reply. > > I found the jcheck `conf` files of other projects[1][2] have the checks > about reviewers: > > ``` > [checks "reviewers"] > reviewers=1 > ``` > > But the jcheck `conf` file of the jtreg[3] doesn't have the similar item. > > Does it affect the bot? Yes, that conf file is what the bots are looking at to know how to treat each repository. The configuration for each repository is managed by the project owning that repository. In this case it's Jon's call (as the code-tools lead) whether to require reviews or not. /Erik > [1] https://github.com/openjdk/skara/blob/master/.jcheck/conf > [2] https://github.com/openjdk/jmh/blob/master/.jcheck/conf > [3] https://github.com/openjdk/jtreg/blob/master/.jcheck/conf > > Best Regards, > -- Guoxiong > > > On Sun, Jun 13, 2021 at 2:55 AM Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > >> It's probably a side-effect of the combination of Skara and the jtreg >> configuration. >> >> I'll follow up with Skara folk. >> >> -- Jon >> From erikj at openjdk.java.net Mon Jun 14 19:36:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 14 Jun 2021 19:36:21 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v4] In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Disallow /clean to work on backport PR without an original commit hash ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1186/files - new: https://git.openjdk.java.net/skara/pull/1186/files/d119cc0c..8c1a4a0d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=03 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1186&range=02-03 Stats: 54 lines in 3 files changed: 51 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/skara/pull/1186.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1186/head:pull/1186 PR: https://git.openjdk.java.net/skara/pull/1186 From kcr at openjdk.java.net Mon Jun 14 19:48:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Mon, 14 Jun 2021 19:48:49 GMT Subject: RFR: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha [v4] In-Reply-To: References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Mon, 14 Jun 2021 19:36:21 GMT, Erik Joelsson wrote: >> This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. >> >> To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Disallow /clean to work on backport PR without an original commit hash Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1186 From erikj at openjdk.java.net Mon Jun 14 20:02:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 14 Jun 2021 20:02:19 GMT Subject: Integrated: 1076: Not possible to use 'Backport ' if original bug doesn't have public sha In-Reply-To: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> References: <0LHYsbCn7MUn_8Xyrg1H9ArenDhgzrwz69PS3EbLaww=.df287990-b099-4e89-a36b-1a595e469ee7@github.com> Message-ID: On Fri, 11 Jun 2021 18:02:28 GMT, Erik Joelsson wrote: > This patch adds a new way of declaring a pull requests to be a backport for situations where the original hash of the original change is not known or available. Technically such a PR should already work without the backport label, but it will display a warning about the issue not being open. By being able to declare a backport, that warning will be eliminated, which should make the user experience smoother and hopefully help avoid mistakes. > > To use the new feature, you create a PR with a title "Backport " instead of "Backport ". Once this goes live, I will update the Skara wiki documentation. This pull request has now been integrated. Changeset: ec8b6637 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/ec8b6637f3703810a51f48eb0e91b3e153175115 Stats: 203 lines in 5 files changed: 195 ins; 1 del; 7 mod 1076: Not possible to use 'Backport ' if original bug doesn't have public sha Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1186 From erikj at openjdk.java.net Mon Jun 14 22:22:53 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Mon, 14 Jun 2021 22:22:53 GMT Subject: RFR: Code cleanup before starting SKARA-1080 Message-ID: Remove dead variables, unused imports and unused assignments before I make real changes in a followup. ------------- Commit messages: - Code cleanup before starting SKARA-1080 Changes: https://git.openjdk.java.net/skara/pull/1187/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1187&range=00 Stats: 46 lines in 3 files changed: 0 ins; 22 del; 24 mod Patch: https://git.openjdk.java.net/skara/pull/1187.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1187/head:pull/1187 PR: https://git.openjdk.java.net/skara/pull/1187 From erikj at openjdk.java.net Tue Jun 15 00:34:28 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 00:34:28 GMT Subject: RFR: 1080: /backport command reports conflict even though there isn't any Message-ID: This patch fixes a bug with the /backport commit command. It currently materializes the workspace where the cherry-picking is done from the wrong repository. It should be using the target repository, but instead it's using the "fork" (which is the repo from which we create the pull request if /backport is successful). In the tests, this wasn't handled at all. All the tests used the same hosted repository for the "fork" as the target. I introduced a separate "fork" repository in the tests where it would make a difference. I changed the backportDoesNotApply test so that it would fail without this fix. I also think I made it clearer why the backport shouldn't apply as well. Finally I added a new test which verifies a situation very similar to the original issue reported. ------------- Depends on: https://git.openjdk.java.net/skara/pull/1187 Commit messages: - SKARA-1080 Changes: https://git.openjdk.java.net/skara/pull/1188/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1188&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1080 Stats: 88 lines in 2 files changed: 81 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/skara/pull/1188.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1188/head:pull/1188 PR: https://git.openjdk.java.net/skara/pull/1188 From kcr at openjdk.java.net Tue Jun 15 12:54:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 12:54:33 GMT Subject: RFR: Code cleanup before starting SKARA-1080 In-Reply-To: References: Message-ID: <9awfKrFtBnt4MOFVYmp0rfV0caGi4ZE7tvkExFGafUk=.d56a7a17-6c1b-452c-ac07-f7cd92b96c89@github.com> On Mon, 14 Jun 2021 22:18:21 GMT, Erik Joelsson wrote: > Remove dead variables, unused imports and unused assignments before I make real changes in a followup. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1187 From kcr at openjdk.java.net Tue Jun 15 12:58:13 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 12:58:13 GMT Subject: RFR: 1080: /backport command reports conflict even though there isn't any In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 00:31:03 GMT, Erik Joelsson wrote: > This patch fixes a bug with the /backport commit command. It currently materializes the workspace where the cherry-picking is done from the wrong repository. It should be using the target repository, but instead it's using the "fork" (which is the repo from which we create the pull request if /backport is successful). > > In the tests, this wasn't handled at all. All the tests used the same hosted repository for the "fork" as the target. I introduced a separate "fork" repository in the tests where it would make a difference. > > I changed the backportDoesNotApply test so that it would fail without this fix. I also think I made it clearer why the backport shouldn't apply as well. > > Finally I added a new test which verifies a situation very similar to the original issue reported. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1188 From "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net Tue Jun 15 13:41:45 2021 From: "github.com+73116608+openjdk-notifier[bot]" at openjdk.java.net (openjdk-notifier [bot]) Date: Tue, 15 Jun 2021 13:41:45 GMT Subject: RFR: 1080: /backport command reports conflict even though there isn't any In-Reply-To: References: Message-ID: <79r-ku9FmjsHfvbxt2QMCTI7Lg9LyzkWn2aqO7vuqZM=.37378943-b2b6-42a5-ad8c-f5f62c2bc7c9@github.com> On Tue, 15 Jun 2021 00:31:03 GMT, Erik Joelsson wrote: > This patch fixes a bug with the /backport commit command. It currently materializes the workspace where the cherry-picking is done from the wrong repository. It should be using the target repository, but instead it's using the "fork" (which is the repo from which we create the pull request if /backport is successful). > > In the tests, this wasn't handled at all. All the tests used the same hosted repository for the "fork" as the target. I introduced a separate "fork" repository in the tests where it would make a difference. > > I changed the backportDoesNotApply test so that it would fail without this fix. I also think I made it clearer why the backport shouldn't apply as well. > > Finally I added a new test which verifies a situation very similar to the original issue reported. 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 backport-cleanup 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/1188 From erikj at openjdk.java.net Tue Jun 15 13:41:44 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 13:41:44 GMT Subject: RFR: 1080: /backport command reports conflict even though there isn't any [v2] In-Reply-To: References: Message-ID: > This patch fixes a bug with the /backport commit command. It currently materializes the workspace where the cherry-picking is done from the wrong repository. It should be using the target repository, but instead it's using the "fork" (which is the repo from which we create the pull request if /backport is successful). > > In the tests, this wasn't handled at all. All the tests used the same hosted repository for the "fork" as the target. I introduced a separate "fork" repository in the tests where it would make a difference. > > I changed the backportDoesNotApply test so that it would fail without this fix. I also think I made it clearer why the backport shouldn't apply as well. > > Finally I added a new test which verifies a situation very similar to the original issue reported. 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. ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1188/files - new: https://git.openjdk.java.net/skara/pull/1188/files/fe8fcfd6..fe8fcfd6 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1188&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1188&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1188.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1188/head:pull/1188 PR: https://git.openjdk.java.net/skara/pull/1188 From erikj at openjdk.java.net Tue Jun 15 13:41:45 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 13:41:45 GMT Subject: Integrated: 1080: /backport command reports conflict even though there isn't any In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 00:31:03 GMT, Erik Joelsson wrote: > This patch fixes a bug with the /backport commit command. It currently materializes the workspace where the cherry-picking is done from the wrong repository. It should be using the target repository, but instead it's using the "fork" (which is the repo from which we create the pull request if /backport is successful). > > In the tests, this wasn't handled at all. All the tests used the same hosted repository for the "fork" as the target. I introduced a separate "fork" repository in the tests where it would make a difference. > > I changed the backportDoesNotApply test so that it would fail without this fix. I also think I made it clearer why the backport shouldn't apply as well. > > Finally I added a new test which verifies a situation very similar to the original issue reported. This pull request has now been integrated. Changeset: 5cf9d46c Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/5cf9d46c6a6faa6e25dfe756ccba3671ed67d6b7 Stats: 88 lines in 2 files changed: 81 ins; 0 del; 7 mod 1080: /backport command reports conflict even though there isn't any Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1188 From erikj at openjdk.java.net Tue Jun 15 13:40:27 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 13:40:27 GMT Subject: Integrated: Code cleanup before starting SKARA-1080 In-Reply-To: References: Message-ID: On Mon, 14 Jun 2021 22:18:21 GMT, Erik Joelsson wrote: > Remove dead variables, unused imports and unused assignments before I make real changes in a followup. This pull request has now been integrated. Changeset: ada4e376 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/ada4e3765b8ad5f236800c67751bddd9d8b75d46 Stats: 46 lines in 3 files changed: 0 ins; 22 del; 24 mod Code cleanup before starting SKARA-1080 Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1187 From erikj at openjdk.java.net Tue Jun 15 19:35:52 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 19:35:52 GMT Subject: RFR: 1082: Add ide label and ide-support-dev to JDK repos Message-ID: Add automatic PR label "ide-support" for IDE related files. ------------- Commit messages: - SKARA-1082 Changes: https://git.openjdk.java.net/skara/pull/1189/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1189&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1082 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1189.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1189/head:pull/1189 PR: https://git.openjdk.java.net/skara/pull/1189 From kcr at openjdk.java.net Tue Jun 15 19:47:49 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 15 Jun 2021 19:47:49 GMT Subject: RFR: 1082: Add ide label and ide-support-dev to JDK repos In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 19:32:30 GMT, Erik Joelsson wrote: > Add automatic PR label "ide-support" for IDE related files. The rest of the configuration is done elsewhere. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.java.net/skara/pull/1189 From tbell at openjdk.java.net Tue Jun 15 19:50:48 2021 From: tbell at openjdk.java.net (Tim Bell) Date: Tue, 15 Jun 2021 19:50:48 GMT Subject: RFR: 1082: Add ide label and ide-support-dev to JDK repos In-Reply-To: References: Message-ID: <06GS_ouXYVVXLRF-Uq7cZFtG4a4OVAXkD2yKVufmxgk=.33fa88ad-3e7a-4153-a8a8-7bebbb58ee15@github.com> On Tue, 15 Jun 2021 19:32:30 GMT, Erik Joelsson wrote: > Add automatic PR label "ide-support" for IDE related files. The rest of the configuration is done elsewhere. Good catch. ------------- Marked as reviewed by tbell (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1189 From erikj at openjdk.java.net Tue Jun 15 19:50:48 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 15 Jun 2021 19:50:48 GMT Subject: Integrated: 1082: Add ide label and ide-support-dev to JDK repos In-Reply-To: References: Message-ID: On Tue, 15 Jun 2021 19:32:30 GMT, Erik Joelsson wrote: > Add automatic PR label "ide-support" for IDE related files. The rest of the configuration is done elsewhere. This pull request has now been integrated. Changeset: 6ccfbd71 Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/6ccfbd71737b7d898da58111120eab8b7f6409f6 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 1082: Add ide label and ide-support-dev to JDK repos Reviewed-by: kcr, tbell ------------- PR: https://git.openjdk.java.net/skara/pull/1189 From erikj at openjdk.java.net Wed Jun 16 23:50:42 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 16 Jun 2021 23:50:42 GMT Subject: RFR: 997: Email notifications are not sent to alias if binary change is commented in Gitlab Message-ID: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> This fixes an NPE when parsing a review comment from Gitlab on a binary file. Such a comment does not have a line, and I picked the value 0 to signal that. I also updated the email formatting of such comments to skip showing line numbers and quotes from the file. ------------- Commit messages: - SKARA-997 Changes: https://git.openjdk.java.net/skara/pull/1190/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1190&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-997 Stats: 46 lines in 3 files changed: 29 ins; 3 del; 14 mod Patch: https://git.openjdk.java.net/skara/pull/1190.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1190/head:pull/1190 PR: https://git.openjdk.java.net/skara/pull/1190 From erikj at openjdk.java.net Thu Jun 17 00:04:19 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Jun 2021 00:04:19 GMT Subject: RFR: 997: Email notifications are not sent to alias if binary change is commented in Gitlab [v2] In-Reply-To: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> References: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> Message-ID: <_T8PqzIouX4CLvhrQrchIHIX1vZXoY9bPKyzSFeENno=.34038de8-0418-4b62-9cc7-d6de12e71d40@github.com> > This fixes an NPE when parsing a review comment from Gitlab on a binary file. Such a comment does not have a line, and I picked the value 0 to signal that. I also updated the email formatting of such comments to skip showing line numbers and quotes from the file. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Clarified comment ------------- Changes: - all: https://git.openjdk.java.net/skara/pull/1190/files - new: https://git.openjdk.java.net/skara/pull/1190/files/0a041293..6a22c75a Webrevs: - full: https://webrevs.openjdk.java.net/?repo=skara&pr=1190&range=01 - incr: https://webrevs.openjdk.java.net/?repo=skara&pr=1190&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1190.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1190/head:pull/1190 PR: https://git.openjdk.java.net/skara/pull/1190 From kcr at openjdk.java.net Thu Jun 17 11:58:33 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 17 Jun 2021 11:58:33 GMT Subject: RFR: 997: Email notifications are not sent to alias if binary change is commented in Gitlab [v2] In-Reply-To: <_T8PqzIouX4CLvhrQrchIHIX1vZXoY9bPKyzSFeENno=.34038de8-0418-4b62-9cc7-d6de12e71d40@github.com> References: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> <_T8PqzIouX4CLvhrQrchIHIX1vZXoY9bPKyzSFeENno=.34038de8-0418-4b62-9cc7-d6de12e71d40@github.com> Message-ID: On Thu, 17 Jun 2021 00:04:19 GMT, Erik Joelsson wrote: >> This fixes an NPE when parsing a review comment from Gitlab on a binary file. Such a comment does not have a line, and I picked the value 0 to signal that. I also updated the email formatting of such comments to skip showing line numbers and quotes from the file. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Clarified comment Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1190 From erikj at openjdk.java.net Thu Jun 17 13:19:10 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 17 Jun 2021 13:19:10 GMT Subject: Integrated: 997: Email notifications are not sent to alias if binary change is commented in Gitlab In-Reply-To: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> References: <7EncTVXnvR6O8nqL9mXNZq9CdZWoQKhQfSeVnP8tBz8=.e0acb0c4-3556-425b-a924-490650849a61@github.com> Message-ID: <_v80uHfM9bUaG1S3MKYVR1KOmP0ZQTiwXMWam7cPCX8=.603f2e80-f265-4489-b09b-7b40007692f8@github.com> On Wed, 16 Jun 2021 23:46:40 GMT, Erik Joelsson wrote: > This fixes an NPE when parsing a review comment from Gitlab on a binary file. Such a comment does not have a line, and I picked the value 0 to signal that. I also updated the email formatting of such comments to skip showing line numbers and quotes from the file. This pull request has now been integrated. Changeset: c11e604d Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/c11e604decf783ef940a083aa22a5493c577aa79 Stats: 48 lines in 3 files changed: 31 ins; 3 del; 14 mod 997: Email notifications are not sent to alias if binary change is commented in Gitlab Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1190 From shade at redhat.com Mon Jun 21 17:05:45 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 21 Jun 2021 19:05:45 +0200 Subject: Re-opened PR and OCA checks Message-ID: <8875484d-fb6f-34c9-d94d-7817c97476f1@redhat.com> Hi, There is a PR for JCStress, where the contributor does not have good OCA yet. Bots rightfully put "oca" label on the issue. Then the contributor closed the issue, bot removed the label. Then contributor re-opened the issue. The bot did not add the "oca" label back? The bot had not acted for half an hour, maybe it is stuck? See: https://github.com/openjdk/jcstress/pull/85 -- Thanks, -Aleksey From erik.joelsson at oracle.com Mon Jun 21 17:39:53 2021 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 21 Jun 2021 10:39:53 -0700 Subject: Re-opened PR and OCA checks In-Reply-To: <8875484d-fb6f-34c9-d94d-7817c97476f1@redhat.com> References: <8875484d-fb6f-34c9-d94d-7817c97476f1@redhat.com> Message-ID: Hello Aleksey, It may look like the bot removed the "oca" label because the PR was closed, but it was actually a reaction to the OCA signature being registered in our system. /Erik On 2021-06-21 10:05, Aleksey Shipilev wrote: > Hi, > > There is a PR for JCStress, where the contributor does not have good > OCA yet. Bots rightfully put "oca" label on the issue. Then the > contributor closed the issue, bot removed the label. Then contributor > re-opened the issue. The bot did not add the "oca" label back? The bot > had not acted for half an hour, maybe it is stuck? > > See: > ? https://github.com/openjdk/jcstress/pull/85 > From dalibor.topic at oracle.com Mon Jun 21 18:12:42 2021 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Mon, 21 Jun 2021 20:12:42 +0200 Subject: Re-opened PR and OCA checks In-Reply-To: References: <8875484d-fb6f-34c9-d94d-7817c97476f1@redhat.com> Message-ID: Yeah, the OCA in question was just processed two hours ago. Thanks for checking, Aleksey! cheers, dalibor topic On 21.06.2021 19:39, erik.joelsson at oracle.com wrote: > Hello Aleksey, > > It may look like the bot removed the "oca" label because the PR was > closed, but it was actually a reaction to the OCA signature being > registered in our system. > > /Erik > > On 2021-06-21 10:05, Aleksey Shipilev wrote: >> Hi, >> >> There is a PR for JCStress, where the contributor does not have good >> OCA yet. Bots rightfully put "oca" label on the issue. Then the >> contributor closed the issue, bot removed the label. Then contributor >> re-opened the issue. The bot did not add the "oca" label back? The bot >> had not acted for half an hour, maybe it is stuck? >> >> See: >> ? https://github.com/openjdk/jcstress/pull/85 >> -- Dalibor Topic Consulting Product Manager Phone: +494089091214 , Mobile: +491737185961 , Video: dalibor.topic at oracle.com Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRB 246209 Gesch?ftsf?hrer: Ralf Herrmann From shade at redhat.com Tue Jun 22 08:13:56 2021 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 22 Jun 2021 10:13:56 +0200 Subject: Re-opened PR and OCA checks In-Reply-To: References: <8875484d-fb6f-34c9-d94d-7817c97476f1@redhat.com> Message-ID: <2cbb0529-5a31-01f9-6f32-8a7c49fab47f@redhat.com> On 6/21/21 8:12 PM, Dalibor Topic wrote: > Yeah, the OCA in question was just processed two hours ago. Ah, OK, good! -- Thanks, -Aleksey From lgxbslgx at gmail.com Tue Jun 22 08:23:25 2021 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Tue, 22 Jun 2021 16:23:25 +0800 Subject: The pre-integration checks of the project jtreg seem to be wrong In-Reply-To: <16d7f0d8-eb7b-855f-1527-2a5324c13fce@oracle.com> References: <12ed319c-86ed-ed21-ddea-12c6d84f0fc4@oracle.com> <16d7f0d8-eb7b-855f-1527-2a5324c13fce@oracle.com> Message-ID: Hi Erik, Thanks for the confirmation. Got it. It may need Jon or other folks who are familiar with jtreg to revise the config file. Best Regards, -- Guoxiong On Mon, Jun 14, 2021 at 9:01 PM wrote: > On 2021-06-13 01:31, Guoxiong Li wrote: > > Thanks Phil and Jon for your kind reply. > > > > I found the jcheck `conf` files of other projects[1][2] have the checks > > about reviewers: > > > > ``` > > [checks "reviewers"] > > reviewers=1 > > ``` > > > > But the jcheck `conf` file of the jtreg[3] doesn't have the similar item. > > > > Does it affect the bot? > > Yes, that conf file is what the bots are looking at to know how to treat > each repository. The configuration for each repository is managed by the > project owning that repository. In this case it's Jon's call (as the > code-tools lead) whether to require reviews or not. > > /Erik > > > [1] https://github.com/openjdk/skara/blob/master/.jcheck/conf > > [2] https://github.com/openjdk/jmh/blob/master/.jcheck/conf > > [3] https://github.com/openjdk/jtreg/blob/master/.jcheck/conf > > > > Best Regards, > > -- Guoxiong > > > > > > On Sun, Jun 13, 2021 at 2:55 AM Jonathan Gibbons < > > jonathan.gibbons at oracle.com> wrote: > > > >> It's probably a side-effect of the combination of Skara and the jtreg > >> configuration. > >> > >> I'll follow up with Skara folk. > >> > >> -- Jon > >> > From ihse at openjdk.java.net Tue Jun 22 11:58:24 2021 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Tue, 22 Jun 2021 11:58:24 GMT Subject: RFR: 1085: Gitlab PR has bad link to patch file Message-ID: The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work. ------------- Commit messages: - 1085: Gitlab PR has bad link to patch file Changes: https://git.openjdk.java.net/skara/pull/1191/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1191&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1085 Stats: 25 lines in 6 files changed: 24 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/skara/pull/1191.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1191/head:pull/1191 PR: https://git.openjdk.java.net/skara/pull/1191 From erikj at openjdk.java.net Tue Jun 22 13:08:21 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 22 Jun 2021 13:08:21 GMT Subject: RFR: 1085: Gitlab PR has bad link to patch file In-Reply-To: References: Message-ID: On Tue, 22 Jun 2021 11:55:10 GMT, Magnus Ihse Bursie wrote: > The link generated under the "Reviewing" header in a PR description works fine on Github, but on Gitlab, the link has a Github style form which does not work. Looks good! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.java.net/skara/pull/1191 From erikj at openjdk.java.net Wed Jun 23 21:15:07 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Wed, 23 Jun 2021 21:15:07 GMT Subject: RFR: 1092: /backport commit command does not validate non existing repos Message-ID: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> This patch fixes inconsistencies with how Forge.repository(String) behaves for GitHub and GitLab. >From what I can tell, this method is expected to return an Optional.empty() if the repository does not exist, and in the Gitlab case, this is what it does. For Github there is no actual check. In both cases, they call the hosted repository constructor (GitlabRepository and GithubRepository respectively) and expect an exception if it doesn't exist. In the case of Gitlab, the constructor will make a rest call to get information about the repository, while the Github variant does not. It seems this was changed for GitHub a long while back as an optimization, using lazy initialization: https://github.com/openjdk/skara/pull/296 I have rewritten this logic and aligned the behavior of Forge.repository(String) between GitHub and GitLab. Now they both will only return Optional.empty() if the rest call to get repository info returns 404. Any other RuntimeException or Error is just let through, as it should be. There are other ways a hosted repository can be created, where Optional is not used in the return value. In these cases we now have consistent throwing of a RuntimeException with the message "Project/Repository not found" (in the GitLab case directly as it's needed for constructing the object, and in the GitHub case when a method is called that triggers the lazy initialization). The assumption is that in these other code paths, the repository name does not originate from human input, but rather other query results, so a 404 is truly unexpected and should result in an exception. ------------- Commit messages: - Changed exception text - SKARA-1092 Changes: https://git.openjdk.java.net/skara/pull/1192/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1192&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1092 Stats: 34 lines in 4 files changed: 18 ins; 8 del; 8 mod Patch: https://git.openjdk.java.net/skara/pull/1192.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1192/head:pull/1192 PR: https://git.openjdk.java.net/skara/pull/1192 From kcr at openjdk.java.net Thu Jun 24 14:06:52 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 24 Jun 2021 14:06:52 GMT Subject: RFR: 1092: /backport commit command does not validate non existing repos In-Reply-To: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> References: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> Message-ID: On Wed, 23 Jun 2021 21:09:46 GMT, Erik Joelsson wrote: > This patch fixes inconsistencies with how Forge.repository(String) behaves for GitHub and GitLab. > > From what I can tell, this method is expected to return an Optional.empty() if the repository does not exist, and in the Gitlab case, this is what it does. For Github there is no actual check. In both cases, they call the hosted repository constructor (GitlabRepository and GithubRepository respectively) and expect an exception if it doesn't exist. In the case of Gitlab, the constructor will make a rest call to get information about the repository, while the Github variant does not. It seems this was changed for GitHub a long while back as an optimization, using lazy initialization: https://github.com/openjdk/skara/pull/296 > > I have rewritten this logic and aligned the behavior of Forge.repository(String) between GitHub and GitLab. Now they both will only return Optional.empty() if the rest call to get repository info returns 404. Any other RuntimeException or Error is just let through, as it should be. There are other ways a hosted repository can be created, where Optional is not used in the return value. In these cases we now have consistent throwing of a RuntimeException with the message "Project/Repository not found" (in the GitLab case directly as it's needed for constructing the object, and in the GitHub case when a method is called that triggers the lazy initialization). The assumption is that in these other code paths, the repository name does not originate from human input, but rather other query results, so a 404 is truly unexpected and should result in an exception. Looks fine. Do you think it is worth adding additional tests to make sure a 404 correctly returns an empty optional, whereas any other error throws an exception? ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1192 From erikj at openjdk.java.net Thu Jun 24 16:15:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Jun 2021 16:15:25 GMT Subject: RFR: 1092: /backport commit command does not validate non existing repos In-Reply-To: References: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> Message-ID: On Thu, 24 Jun 2021 14:04:25 GMT, Kevin Rushforth wrote: > Do you think it is worth adding additional tests to make sure a 404 correctly returns an empty optional, whereas any other error throws an exception? Skara doesn't currently have any tests that verifies the interaction with other services, like Github or Jira. I don't know where to start writing such tests. Creating a framework for that is certainly bigger than this fix. ------------- PR: https://git.openjdk.java.net/skara/pull/1192 From erikj at openjdk.java.net Thu Jun 24 16:15:25 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Jun 2021 16:15:25 GMT Subject: Integrated: 1092: /backport commit command does not validate non existing repos In-Reply-To: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> References: <-YgtOT2iJSqXfyBybCZW_LHEuqCQwKzjkpL86qrAmeA=.6d076e8c-ca27-4090-8d32-1f33b1a9fd25@github.com> Message-ID: On Wed, 23 Jun 2021 21:09:46 GMT, Erik Joelsson wrote: > This patch fixes inconsistencies with how Forge.repository(String) behaves for GitHub and GitLab. > > From what I can tell, this method is expected to return an Optional.empty() if the repository does not exist, and in the Gitlab case, this is what it does. For Github there is no actual check. In both cases, they call the hosted repository constructor (GitlabRepository and GithubRepository respectively) and expect an exception if it doesn't exist. In the case of Gitlab, the constructor will make a rest call to get information about the repository, while the Github variant does not. It seems this was changed for GitHub a long while back as an optimization, using lazy initialization: https://github.com/openjdk/skara/pull/296 > > I have rewritten this logic and aligned the behavior of Forge.repository(String) between GitHub and GitLab. Now they both will only return Optional.empty() if the rest call to get repository info returns 404. Any other RuntimeException or Error is just let through, as it should be. There are other ways a hosted repository can be created, where Optional is not used in the return value. In these cases we now have consistent throwing of a RuntimeException with the message "Project/Repository not found" (in the GitLab case directly as it's needed for constructing the object, and in the GitHub case when a method is called that triggers the lazy initialization). The assumption is that in these other code paths, the repository name does not originate from human input, but rather other query results, so a 404 is truly unexpected and should result in an exception. This pull request has now been integrated. Changeset: 8801187c Author: Erik Joelsson URL: https://git.openjdk.java.net/skara/commit/8801187c088ed261de4db4084631bd672b0f6857 Stats: 34 lines in 4 files changed: 18 ins; 8 del; 8 mod 1092: /backport commit command does not validate non existing repos Reviewed-by: kcr ------------- PR: https://git.openjdk.java.net/skara/pull/1192 From erikj at openjdk.java.net Thu Jun 24 18:48:20 2021 From: erikj at openjdk.java.net (Erik Joelsson) Date: Thu, 24 Jun 2021 18:48:20 GMT Subject: RFR: 1095: Ignore tags in pr branches when notifying Message-ID: This patch for the Notify bot adds filtering when processing new tags. Only tags that appear in branches other than the PR branches are considered. Changes in PR branches are pending review and should not be included when sending email notifications or updating bugs. See bug for more details. ------------- Commit messages: - SKARA-1095 Changes: https://git.openjdk.java.net/skara/pull/1193/files Webrev: https://webrevs.openjdk.java.net/?repo=skara&pr=1193&range=00 Issue: https://bugs.openjdk.java.net/browse/SKARA-1095 Stats: 123 lines in 2 files changed: 123 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/skara/pull/1193.diff Fetch: git fetch https://git.openjdk.java.net/skara pull/1193/head:pull/1193 PR: https://git.openjdk.java.net/skara/pull/1193 From kcr at openjdk.java.net Fri Jun 25 12:35:30 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 25 Jun 2021 12:35:30 GMT Subject: RFR: 1095: Ignore tags in pr branches when notifying In-Reply-To: References: Message-ID: <2ZyGiSfMuPSpqNPzxEFeq4nW0qXaFdtvYV0X6S9w9_A=.bc5a0d44-b8a0-4875-a582-a5f641896867@github.com> On Thu, 24 Jun 2021 18:44:50 GMT, Erik Joelsson wrote: > This patch for the Notify bot adds filtering when processing new tags. Only tags that appear in branches other than the PR branches are considered. Changes in PR branches are pending review and should not be included when sending email notifications or updating bugs. See bug for more details. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.java.net/skara/pull/1193