From joe.darcy at oracle.com Tue Nov 1 01:50:48 2022 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 31 Oct 2022 18:50:48 -0700 Subject: CFV: New Skara Committer: Zhao Song In-Reply-To: References: Message-ID: <92544f9d-f640-6b90-68aa-298e9daf1afd@oracle.com> Vote: yes On 10/27/2022 2:07 PM, erik.joelsson at oracle.com wrote: > I hereby nominate Zhao Song to Skara Committer. > > Zhao is a member of the infrastructure team at Oracle and has so far > contributed 15 changes to the Skara project [3]. > > Votes are due by Thursday 2022-11-10 14:30 PDT. > > Only current Skara Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [2]. > > Erik Joelsson > > [1] https://openjdk.org/census > [2] https://openjdk.org/projects/#committer-vote > [3] https://github.com/openjdk/skara/commits?author=zhaosongzs > > From zsong at openjdk.org Tue Nov 1 17:18:50 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 17:18:50 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf In-Reply-To: References: Message-ID: On Mon, 31 Oct 2022 22:39:34 GMT, Erik Joelsson wrote: > Instead of explicitly checking for `.jcheck/conf` here through a remote call, I think it would be better to react to if the `Optional` below comes back empty or not. If it's empty and `bot.confOverrideRepository().isEmpty()` then you can print a message. Yesterday I was wondering whether there is any possible that `Optional` is empty due to other errors. Today I read through the code again and confirm that Only `.jcheck/conf` invalid or missing will make `Optional` empty. Thx! ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 1 17:35:43 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 17:35:43 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 17:15:35 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 231: >> >>> 229: //check whether this repo contains .jcheck/conf, if not, let the pr author to notify the repo owner >>> 230: try { >>> 231: pr.repository().fileContents(".jcheck/conf", pr.targetRef()); >> >> Instead of explicitly checking for `.jcheck/conf` here through a remote call, I think it would be better to react to if the `Optional` below comes back empty or not. If it's empty and `bot.confOverrideRepository().isEmpty()` then you can print a message. > >> Instead of explicitly checking for `.jcheck/conf` here through a remote call, I think it would be better to react to if the `Optional` below comes back empty or not. If it's empty and `bot.confOverrideRepository().isEmpty()` then you can print a message. > > Yesterday I was wondering whether there is any possible that `Optional` is empty due to other errors. Today I read through the code again and confirm that Only `.jcheck/conf` invalid or missing will make `Optional` empty. Thx! Maybe it would be even better to throw an exception instead of returning Optional.empty(). We can't recover from it in CheckWorkItem anyway, and with a typed exception we can communicate more exactly what went wrong, and we can catch exactly that exception type and write the message. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 1 17:43:15 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 17:43:15 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 17:32:05 GMT, Erik Joelsson wrote: > Maybe it would be even better to throw an exception instead of returning Optional.empty(). We can't recover from it in CheckWorkItem anyway, and with a typed exception we can communicate more exactly what went wrong, and we can catch exactly that exception type and write the message. I thought about it in the very beginning and I found that if we choose to throw an exception, we will need to surround a lot of code with try catch because the scope of `census` is big. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 1 18:02:05 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 18:02:05 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf In-Reply-To: References: Message-ID: <-eBU_zZljzVFivhLp-3PLXPB6bkEshFLK6HGozQAUQ8=.7f04ead4-972b-4193-85ec-ec67a4d93a6e@github.com> On Tue, 1 Nov 2022 17:39:51 GMT, Zhao Song wrote: >> Maybe it would be even better to throw an exception instead of returning Optional.empty(). We can't recover from it in CheckWorkItem anyway, and with a typed exception we can communicate more exactly what went wrong, and we can catch exactly that exception type and write the message. > >> Maybe it would be even better to throw an exception instead of returning Optional.empty(). We can't recover from it in CheckWorkItem anyway, and with a typed exception we can communicate more exactly what went wrong, and we can catch exactly that exception type and write the message. > > I thought about it in the very beginning and I found that if we choose to throw an exception, we will need to surround a lot of code with try catch because the scope of `census` is big. Note that there are a lot of different `CensusInstance` implementations. They aren't shared between different bot modules. The one in `bots.pr` is only used in two locations, and the other location would probably also like a quick exit on this failure. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 1 18:06:41 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 18:06:41 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf In-Reply-To: <-eBU_zZljzVFivhLp-3PLXPB6bkEshFLK6HGozQAUQ8=.7f04ead4-972b-4193-85ec-ec67a4d93a6e@github.com> References: <-eBU_zZljzVFivhLp-3PLXPB6bkEshFLK6HGozQAUQ8=.7f04ead4-972b-4193-85ec-ec67a4d93a6e@github.com> Message-ID: <6utP9ISNTwDU_yoEafhlGm-b0mOydPxJguqBFVdAxL0=.8f128b3c-7121-4bd2-9c03-7e25b22aa54c@github.com> On Tue, 1 Nov 2022 17:58:41 GMT, Erik Joelsson wrote: >>> Maybe it would be even better to throw an exception instead of returning Optional.empty(). We can't recover from it in CheckWorkItem anyway, and with a typed exception we can communicate more exactly what went wrong, and we can catch exactly that exception type and write the message. >> >> I thought about it in the very beginning and I found that if we choose to throw an exception, we will need to surround a lot of code with try catch because the scope of `census` is big. > > Note that there are a lot of different `CensusInstance` implementations. They aren't shared between different bot modules. The one in `bots.pr` is only used in two locations, and the other location would probably also like a quick exit on this failure. > Yes, I just mean we need to surround a lot of code with try catch in `CheckWorkItem#prRun`. If it is ok, I will change it. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 1 18:45:21 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 18:45:21 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v2] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: SKARA-1217 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/51653fba..3b05cc5f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=00-01 Stats: 52 lines in 3 files changed: 20 ins; 20 del; 12 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 1 18:45:21 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 18:45:21 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v2] In-Reply-To: References: Message-ID: <1YDplFmlWyczjvkEhgd2WRHBgQSV74oEv_nRU5Z5iGs=.d11bfd20-d5ed-420c-8d6b-1f441181cbc6@github.com> On Tue, 1 Nov 2022 18:41:46 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > SKARA-1217 bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 243: > 241: + "Until that is resolved, this pull request cannot be processed. Please notify the repository owner."; > 242: addErrorComment(text, comments); > 243: } I think this is another situation which is that the override configuration is invalid or missing bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 47: > 45: repository, ref, confOverrideRepo, confOverrideName, confOverrideRef); > 46: if (configuration.isEmpty()) { > 47: throw new InvalidJCheckConfException(".jcheck/conf is invalid or missing"); Hi Erik, I don't know if I understood you exactly to throw the exception here. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 1 19:42:46 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 1 Nov 2022 19:42:46 GMT Subject: RFR: 1217: ProblemList errors should not prevent a PR from being rfr Message-ID: In this patch, `ProblemListsIssue` will not prevent a PR from being ready for review(rfr) any more. Also added `testProblemListsIssue` to test this behavior. ------------- Commit messages: - Formatted testProblemListsIssue - Formatted testProblemListsIssue - SKARA-1217 Changes: https://git.openjdk.org/skara/pull/1410/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1410&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1217 Stats: 53 lines in 2 files changed: 51 ins; 1 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1410.diff Fetch: git fetch https://git.openjdk.org/skara pull/1410/head:pull/1410 PR: https://git.openjdk.org/skara/pull/1410 From erikj at openjdk.org Tue Nov 1 19:56:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 19:56:58 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v2] In-Reply-To: References: Message-ID: <6i041PAfh6PPwmQVDPC2FWXOpc2OP2s_hplE6iCGzdY=.21feb057-2781-46bd-b616-2215bf9cf6c4@github.com> On Tue, 1 Nov 2022 18:45:21 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > SKARA-1217 bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 234: > 232: census = CensusInstance.createCensusInstance(hostedRepositoryPool, bot.censusRepo(), bot.censusRef(), scratchPath.resolve("census"), pr, > 233: bot.confOverrideRepository().orElse(null), bot.confOverrideName(), bot.confOverrideRef()).orElseThrow(); > 234: } catch (InvalidJCheckConfException invalidJCheckConfException) { Please just name the caught exception variable `e` unless we need explicit names. bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 17: > 15: import org.openjdk.skara.jcheck.JCheckConfiguration; > 16: > 17: class InvalidJCheckConfException extends RuntimeException { I would like this to be a checked exception, so just extend `Exception`. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 1 19:56:59 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 19:56:59 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v2] In-Reply-To: <1YDplFmlWyczjvkEhgd2WRHBgQSV74oEv_nRU5Z5iGs=.d11bfd20-d5ed-420c-8d6b-1f441181cbc6@github.com> References: <1YDplFmlWyczjvkEhgd2WRHBgQSV74oEv_nRU5Z5iGs=.d11bfd20-d5ed-420c-8d6b-1f441181cbc6@github.com> Message-ID: On Tue, 1 Nov 2022 18:41:45 GMT, Zhao Song wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> SKARA-1217 > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 243: > >> 241: + "Until that is resolved, this pull request cannot be processed. Please notify the repository owner."; >> 242: addErrorComment(text, comments); >> 243: } > > I think this is another situation which is that the override configuration is invalid or missing If we throw two separate exception types as suggested below, then we can provide more detailed error messages, for either a missing or an invalid jcheck conf. In the case of the override jcheck configuration, the file can be configured to have any name. I would suggest: "The external jcheck configuration for this repository could not be resolved. Until that is fixed, this pull request cannot be processed. Please notify a Skara admin." > bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 47: > >> 45: repository, ref, confOverrideRepo, confOverrideName, confOverrideRef); >> 46: if (configuration.isEmpty()) { >> 47: throw new InvalidJCheckConfException(".jcheck/conf is invalid or missing"); > > Hi Erik, I don't know if I understood you exactly to throw the exception here. I think it would fit better in `configuration` as an `.orElseThrow()`. In that case it's only thrown if jcheck is missing, so the exception should be named MissingJCheckConfException. The actual parsing of the configuration seems to only explicitly throw IllegalArgumentException. It's possible that other parse problems would result in other runtime exceptions, such as NPE. I think we should wrap the parse call with try-catch for RuntimeException and throw an `InvalidJCheckConfException` if that happens. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 1 19:58:51 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 1 Nov 2022 19:58:51 GMT Subject: RFR: 1217: ProblemList errors should not prevent a PR from being rfr In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 19:39:09 GMT, Zhao Song wrote: > In this patch, `ProblemListsIssue` will not prevent a PR from being ready for review(rfr) any more. > > Also added `testProblemListsIssue` to test this behavior. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1410 From ihse at openjdk.org Wed Nov 2 15:44:12 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 2 Nov 2022 15:44:12 GMT Subject: RFR: 1217: ProblemList errors should not prevent a PR from being rfr In-Reply-To: References: Message-ID: <44TVmfSB2vGjDqhMRMdn-6wDf7rKN3idco0SufyPMGA=.742ce6d5-d3ed-44e4-842e-2098233ade4d@github.com> On Tue, 1 Nov 2022 19:39:09 GMT, Zhao Song wrote: > In this patch, `ProblemListsIssue` will not prevent a PR from being ready for review(rfr) any more. > > Also added `testProblemListsIssue` to test this behavior. Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1410 From zsong at openjdk.org Wed Nov 2 16:48:11 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 16:48:11 GMT Subject: Integrated: 1587: Adding review comments should not mean approval status change In-Reply-To: References: Message-ID: On Wed, 19 Oct 2022 19:22:42 GMT, Zhao Song wrote: > The issue here is ' if a user leaves additional comments using the "Review changes" dialog, and selects the "Comments", then their approval is considered revoked.' > > I believe this happens because if we use "Review changes" to add a comment, it will add a review with `Review.Verdict.NONE` to our pr. According to our current logic, this new review will cover old reviews, so the approval will be revoked. > > I made changes to `CheckablePullRequest#filterActiveReviews`. Now If latest review is just a comment, the verdict will inherit from the previous review. This pull request has now been integrated. Changeset: ee75ee0a Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/ee75ee0a81c3098576c559b2bc9bd5317042a8a2 Stats: 67 lines in 2 files changed: 65 ins; 0 del; 2 mod 1587: Adding review comments should not mean approval status change Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1399 From zsong at openjdk.org Wed Nov 2 16:49:32 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 16:49:32 GMT Subject: Integrated: 1625: Validate input from /summary command In-Reply-To: References: Message-ID: On Fri, 21 Oct 2022 21:08:55 GMT, Zhao Song wrote: > 1. Added validation to SummaryCommand. > 2. If exceptions are thrown when the bot is evaluating the current status of the pr, the exceptions will be treated as integration blocker. This pull request has now been integrated. Changeset: dedb1571 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/dedb157185c92780f645b985e913f64d5ddbedf4 Stats: 84 lines in 3 files changed: 73 ins; 1 del; 10 mod 1625: Validate input from /summary command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1401 From erikj at openjdk.org Wed Nov 2 16:53:10 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 16:53:10 GMT Subject: RFR: 1450: Jcheck status message can be too big for Gitlab [v2] In-Reply-To: <1KSI4kG7-2pFlTXGZUe6D9-s00Wy6g0icHdSQFdveOA=.57faafe1-5a2e-4f15-9c0e-5c357204dc8a@github.com> References: <1KSI4kG7-2pFlTXGZUe6D9-s00Wy6g0icHdSQFdveOA=.57faafe1-5a2e-4f15-9c0e-5c357204dc8a@github.com> Message-ID: On Thu, 27 Oct 2022 16:19:22 GMT, Zhao Song wrote: >> SKARA-1450 describes the problem that the comment adding to a GitLab merge request can be too big to add and leads to fail. >> >> To fix it, I add the function `limitBodySize()` to `addComment()` and `updateComment()` in `GitLabMergeRequest`, the function will check the size of the comment and the comment will be cropped if it is too big. >> >> I also found that GitHub pull request might have the same problem, so I did the same change to `GitHubPullRequest`. >> >> Currently, I set the comment max size to 20000, and I don't know whether it is fine. I think it could not be too small because the user wants to see more information and it should not be big because if it is too big, the page loading process will be slow when the user tries to open the pr. >> >> [Maximum length for the comment body in GitHub PR](https://github.com/orgs/community/discussions/27190) >> [My test in Playground](https://github.com/openjdk/playground/pull/99) > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > bump comment body size from 20000 to 64000 Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1403 From zsong at openjdk.org Wed Nov 2 16:56:14 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 16:56:14 GMT Subject: Integrated: 1581: Commit command error message misleading In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 20:57:44 GMT, Zhao Song wrote: > This patch updated the warning message when a user is not authorized to use the command `/backport`, `/tag`, `/clean`. This pull request has now been integrated. Changeset: c694b0e6 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/c694b0e6de26fcf1be381b163dd55e6760a3c07c Stats: 15 lines in 2 files changed: 10 ins; 4 del; 1 mod 1581: Commit command error message misleading Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1405 From erikj at openjdk.org Wed Nov 2 16:56:28 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 16:56:28 GMT Subject: RFR: 1582: /integrate defer should be named /integrate delegate [v3] In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 20:48:47 GMT, Zhao Song wrote: >> In this patch, to make the user has better experience, the command `/integrate defer` has been updated to `/integrate delegate` and the command `/integrate undefer` has been updated to `/integrate undelegate`. >> >> `/integrate defer` and `/integrate undefer` are still valid. But warning message will be printed when these two commands are used. >> >> After this patch is merged, the wiki page [/integrate](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) should be updated. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fixed bug in IntegrateTests bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 55: > 53: > 54: private void showHelp(PrintWriter reply) { > 55: reply.println("usage: `/integrate [auto|manual|delegate|undelegate]`"); Looks like you lost a `|`. ------------- PR: https://git.openjdk.org/skara/pull/1404 From zsong at openjdk.org Wed Nov 2 16:56:28 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 16:56:28 GMT Subject: RFR: 1582: /integrate defer should be named /integrate delegate [v3] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 16:51:04 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed bug in IntegrateTests > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 55: > >> 53: >> 54: private void showHelp(PrintWriter reply) { >> 55: reply.println("usage: `/integrate [auto|manual|delegate|undelegate]`"); > > Looks like you lost a `|`. Yes, thanks for reminding. Will fix it. ------------- PR: https://git.openjdk.org/skara/pull/1404 From zsong at openjdk.org Wed Nov 2 16:56:53 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 16:56:53 GMT Subject: Integrated: 1217: ProblemList errors should not prevent a PR from being rfr In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 19:39:09 GMT, Zhao Song wrote: > In this patch, `ProblemListsIssue` will not prevent a PR from being ready for review(rfr) any more. > > Also added `testProblemListsIssue` to test this behavior. This pull request has now been integrated. Changeset: e1ecf710 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/e1ecf7100314fb5120d9020730c1808cf02ed229 Stats: 53 lines in 2 files changed: 51 ins; 1 del; 1 mod 1217: ProblemList errors should not prevent a PR from being rfr Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/skara/pull/1410 From zsong at openjdk.org Wed Nov 2 17:07:58 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 17:07:58 GMT Subject: RFR: 1582: /integrate defer should be named /integrate delegate [v4] In-Reply-To: References: Message-ID: > In this patch, to make the user has better experience, the command `/integrate defer` has been updated to `/integrate delegate` and the command `/integrate undefer` has been updated to `/integrate undelegate`. > > `/integrate defer` and `/integrate undefer` are still valid. But warning message will be printed when these two commands are used. > > After this patch is merged, the wiki page [/integrate](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) should be updated. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Modified help message in IntegrateCommand ------------- Changes: - all: https://git.openjdk.org/skara/pull/1404/files - new: https://git.openjdk.org/skara/pull/1404/files/bc6c231f..a66d4f3a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1404&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1404&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1404.diff Fetch: git fetch https://git.openjdk.org/skara pull/1404/head:pull/1404 PR: https://git.openjdk.org/skara/pull/1404 From erikj at openjdk.org Wed Nov 2 17:15:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 17:15:44 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot Message-ID: The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reversed. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. ------------- Commit messages: - Remove empty line - Added top level comment to TestInfoBot - SKARA-1659 Changes: https://git.openjdk.org/skara/pull/1411/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1411&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1659 Stats: 112 lines in 5 files changed: 54 ins; 26 del; 32 mod Patch: https://git.openjdk.org/skara/pull/1411.diff Fetch: git fetch https://git.openjdk.org/skara pull/1411/head:pull/1411 PR: https://git.openjdk.org/skara/pull/1411 From erikj at openjdk.org Wed Nov 2 17:23:32 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 17:23:32 GMT Subject: RFR: 1582: /integrate defer should be named /integrate delegate [v4] In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:07:58 GMT, Zhao Song wrote: >> In this patch, to make the user has better experience, the command `/integrate defer` has been updated to `/integrate delegate` and the command `/integrate undefer` has been updated to `/integrate undelegate`. >> >> `/integrate defer` and `/integrate undefer` are still valid. But warning message will be printed when these two commands are used. >> >> After this patch is merged, the wiki page [/integrate](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) should be updated. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Modified help message in IntegrateCommand Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1404 From erikj at openjdk.org Wed Nov 2 17:23:50 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 17:23:50 GMT Subject: RFR: 1594: Convert rest of bots polling PRs and Issues to use new pollers Message-ID: The new PullRequestPoller has now been in use in the PullRequestBot for a while, and hopefully most of the kinks have been ironed out. I think it's time to convert the rest of the bots that poll PRs (and the CSRIssueBot that polls Issues) to use the new pollers. The conversion is pretty straight forward. In the case of the CSRBots, they were missing the retry callback, so I added that functionality in line with other bots. The new factory tests needed to be modified slightly, as the PullRequestPoller calls to the Forge/Host object of a repository during initialization, so we need a TestHost instance there instead of `null`. I deliberately left out two bots here, the JEPBot and the TestInfoBot. The TestInfoBot is handled separately already in #1411. For the JEPBot, I think it needs a general overhaul. In the end it should function more or less the same as the CSRBot, but I'm still not sure that the CSRBot is where I want it to be. ------------- Commit messages: - Fix tests - SKARA-1594 Changes: https://git.openjdk.org/skara/pull/1412/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1412&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1594 Stats: 186 lines in 9 files changed: 41 ins; 104 del; 41 mod Patch: https://git.openjdk.org/skara/pull/1412.diff Fetch: git fetch https://git.openjdk.org/skara pull/1412/head:pull/1412 PR: https://git.openjdk.org/skara/pull/1412 From zsong at openjdk.org Wed Nov 2 20:02:54 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 20:02:54 GMT Subject: Integrated: 1450: Jcheck status message can be too big for Gitlab In-Reply-To: References: Message-ID: On Wed, 26 Oct 2022 23:03:56 GMT, Zhao Song wrote: > SKARA-1450 describes the problem that the comment adding to a GitLab merge request can be too big to add and leads to fail. > > To fix it, I add the function `limitBodySize()` to `addComment()` and `updateComment()` in `GitLabMergeRequest`, the function will check the size of the comment and the comment will be cropped if it is too big. > > I also found that GitHub pull request might have the same problem, so I did the same change to `GitHubPullRequest`. > > Currently, I set the comment max size to 20000, and I don't know whether it is fine. I think it could not be too small because the user wants to see more information and it should not be big because if it is too big, the page loading process will be slow when the user tries to open the pr. > > [Maximum length for the comment body in GitHub PR](https://github.com/orgs/community/discussions/27190) > [My test in Playground](https://github.com/openjdk/playground/pull/99) This pull request has now been integrated. Changeset: 804b7e95 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/804b7e95f8e623b43192d87476f38fa4a3c156ee Stats: 67 lines in 4 files changed: 67 ins; 0 del; 0 mod 1450: Jcheck status message can be too big for Gitlab Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1403 From zsong at openjdk.org Wed Nov 2 20:03:11 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 2 Nov 2022 20:03:11 GMT Subject: Integrated: 1582: /integrate defer should be named /integrate delegate In-Reply-To: References: Message-ID: On Thu, 27 Oct 2022 18:19:06 GMT, Zhao Song wrote: > In this patch, to make the user has better experience, the command `/integrate defer` has been updated to `/integrate delegate` and the command `/integrate undefer` has been updated to `/integrate undelegate`. > > `/integrate defer` and `/integrate undefer` are still valid. But warning message will be printed when these two commands are used. > > After this patch is merged, the wiki page [/integrate](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/integrate) should be updated. This pull request has now been integrated. Changeset: 5d9dcc24 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/5d9dcc24a74ed4e960b79ee2aec35d3e3dc8dbab Stats: 67 lines in 2 files changed: 35 ins; 1 del; 31 mod 1582: /integrate defer should be named /integrate delegate Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1404 From erikj at openjdk.org Wed Nov 2 20:45:15 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 20:45:15 GMT Subject: RFR: 1660: Add confname field to slack log config Message-ID: The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. ------------- Commit messages: - SKARA-1660 Changes: https://git.openjdk.org/skara/pull/1413/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1413&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1660 Stats: 41 lines in 3 files changed: 26 ins; 0 del; 15 mod Patch: https://git.openjdk.org/skara/pull/1413.diff Fetch: git fetch https://git.openjdk.org/skara pull/1413/head:pull/1413 PR: https://git.openjdk.org/skara/pull/1413 From erikj at openjdk.org Wed Nov 2 22:48:37 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 2 Nov 2022 22:48:37 GMT Subject: RFR: 1538: Allow regex patterns in fixversions and altfixversions in the notifier Message-ID: This patch adds support for regex patterns when specifying fixVersions and altFixVersions in the IssueNotifier. For fixVersions, the branch name can now be a regex pattern and for the altFixVersions, both the branch name as well as the version strings in the array can all be regex patterns. Having this flexibility will enable us to construct much more static configurations for certain repositories, that don't need manual updating each time we fork or branch a new release. ------------- Commit messages: - SKARA-1538 Changes: https://git.openjdk.org/skara/pull/1414/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1414&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1538 Stats: 153 lines in 6 files changed: 113 ins; 8 del; 32 mod Patch: https://git.openjdk.org/skara/pull/1414.diff Fetch: git fetch https://git.openjdk.org/skara pull/1414/head:pull/1414 PR: https://git.openjdk.org/skara/pull/1414 From jwaters at openjdk.org Thu Nov 3 05:24:05 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 05:24:05 GMT Subject: RFR: Mark integrated Pull Requests as properly merged in GitHub repositories Message-ID: Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around. In the [willful absence of a reply from the GitHub team to allow marked a pull as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, a workaround with minimal impact can be used instead: Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated. Following the principle of waste not, want not, a change that is currently only implemented for GitHub repositories instead resets the pre-integratio n branch to the source ref of the pull request, then merges the request into it's own pre-integration branch before the actual deletion occurs, leaving minimal impact on most of Skara's infrastructure and with virtually no effect on already existing repositories. - [x] Properly handle all dependencies of the pre-integration branch before it's modified irreversibly ------------- Commit messages: - Squash for neatness Changes: https://git.openjdk.org/skara/pull/1409/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=00 Stats: 101 lines in 7 files changed: 51 ins; 19 del; 31 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From lgxbslgx at gmail.com Thu Nov 3 09:05:43 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 3 Nov 2022 17:05:43 +0800 Subject: CFV: New Skara Committer: Zhao Song In-Reply-To: <92544f9d-f640-6b90-68aa-298e9daf1afd@oracle.com> References: <92544f9d-f640-6b90-68aa-298e9daf1afd@oracle.com> Message-ID: Vote: yes -------------- next part -------------- An HTML attachment was scrubbed... URL: From jwaters at openjdk.org Thu Nov 3 12:32:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 12:32:18 GMT Subject: RFR: Mark integrated Pull Requests as properly merged in GitHub repositories In-Reply-To: References: Message-ID: <7kjDEoWVdCm7KzK_y7DBkQHRvB1yCr9SBNV2ZIf6vWM=.03557668-25b2-48e6-a696-4d951bf5220f@github.com> On Tue, 1 Nov 2022 16:55:16 GMT, Julian Waters wrote: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, a workaround with minimal impact can be used instead: Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated. Following the principle of waste not, want not, a change that is currently only implemented for GitHub repositories instead resets the pre-integration branch to the source ref of the pull request, then merges the request into it's own pre-integration branch before the actual deletion occurs, leaving minimal impact on most of Skara's infrastructure and with virtually no effect on already existing repositories. > > - [x] Properly handle all dependencies of the pre-integration branch before it's modified irreversibly > - [ ] Change test code to match modified integration logic (if required) I've only just realized that there are tests that require careful change whenever the integration marking code is modified. The existing integration sequence hasn't been touched whatsoever but there is new logic executed before it that I can't figure out whether the corresponding test code needs to be updated. Will add that as a task for now ------------- PR: https://git.openjdk.org/skara/pull/1409 From erikj at openjdk.org Thu Nov 3 13:37:39 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 3 Nov 2022 13:37:39 GMT Subject: RFR: Mark integrated Pull Requests as properly merged in GitHub repositories In-Reply-To: References: Message-ID: On Tue, 1 Nov 2022 16:55:16 GMT, Julian Waters wrote: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, a workaround with minimal impact can be used instead: Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated. Following the principle of waste not, want not, a change that is currently only implemented for GitHub repositories instead resets the pre-integration branch to the source ref of the pull request, then merges the request into it's own pre-integration branch before the actual deletion occurs, leaving minimal impact on most of Skara's infrastructure and with virtually no effect on already existing repositories (and it also keeps the aesthetically pleasing integrated flag!). > > - [x] Properly handle all dependencies of the pre-integration branch before it's modified irreversibly > - [ ] Change test code to match modified integration logic (if required) First of all, for a change as big as this, a bug is definitely needed. It should really be filed first and explain what and why you intend to change. This is an interesting idea, but I'm not sure its worth the tradeoff of losing the information about which branch a PR was integrated into. We already have multi branch development happening in some repos and more of that is coming. At first glance this also looks brittle. You need to understand that the bots are designed to be interruptible at any point in time, restarted and being able to continue. The integration logic and order is carefully crafted to function this way. As an example, assuming that the second to last target targetRef change is the one we actually integrated into could be false if someone else was changing that around the time of integration. There are a lot of corner cases that would need careful testing before this change could be accepted, and once it went live, I would expect at least some fallout. We are currently blocked from using pr/X branches in GitLab due to [SKARA-1173](https://bugs.openjdk.org/browse/SKARA-1173), so this proposed change would be blocked until that is resolved regardless. ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 3 14:14:50 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 14:14:50 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories [v2] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, a workaround with minimal impact can be used instead: Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated. Following the principle of waste not, want not, a change that is currently only implemented for GitHub repositories instead resets the pre-integration branch to the source ref of the pull request, then merges the request into it's own pre-integration branch before the actual deletion occurs, leaving minimal impact on most of Skara's infrastructure and with virtually no effect on already existing repositories (and it also keeps the aesthetically pleasing integrated flag!). > > - [x] Properly handle all dependencies of the pre-integration branch before it's modified irreversibly > - [ ] Change test code to match modified integration logic (if required) Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert changes to PreIntegrations and try something stupid instead ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/078b4f77..8ca08323 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=00-01 Stats: 17 lines in 2 files changed: 2 ins; 14 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 3 15:13:34 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 15:13:34 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 13:34:11 GMT, Erik Joelsson wrote: > First of all, for a change as big as this, a bug is definitely needed. It should really be filed first and explain what and why you intend to change. > > This is an interesting idea, but I'm not sure its worth the tradeoff of losing the information about which branch a PR was integrated into. We already have multi branch development happening in some repos and more of that is coming. > > At first glance this also looks brittle. You need to understand that the bots are designed to be interruptible at any point in time, restarted and being able to continue. The integration logic and order is carefully crafted to function this way. As an example, assuming that the second to last target targetRef change is the one we actually integrated into could be false if someone else was changing that around the time of integration. There are a lot of corner cases that would need careful testing before this change could be accepted, and once it went live, I would expect at least some fallout. My mistake- I forgot to create the issue and enable the test workflows, both have now been done. I've since reverted the changes to PreIntegrations, which should resolve the problem of concurrent changes to the targetRef in question. The only other solution I can think of though is saving the targetRef before the pr/ branch swap happens, and then immediately resetting it back to the saved instance after the merge in `markIntegratedAndMerged` (and if really required, also printing the branch the Pull Request was integrated into in the "pushed as commit" message). I unfortunately currently have no way of testing if GitHub even allows doing this however, and documentation doesn't really seem to mention anything about this either > We are currently blocked from using pr/X branches in GitLab due to [SKARA-1173](https://bugs.openjdk.org/browse/SKARA-1173), so this proposed change would be blocked until that is resolved regardless. That's a bit of a bummer, though maybe that can be circumvented with a few `instanceof GitHubPullRequest`s? The change is, after all, only actually implemented for GitHub ------------- PR: https://git.openjdk.org/skara/pull/1409 From erikj at openjdk.org Thu Nov 3 17:04:25 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 3 Nov 2022 17:04:25 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 15:09:57 GMT, Julian Waters wrote: > That's a bit of a bummer, though maybe that can be circumvented with a few instanceof GitHubPullRequests? The change is, after all, only actually implemented for GitHub I don't understand what you mean by the change only being implemented for GitHub. We strive to keep Skara feature equivalent on GitHub and GitLab. The pr/X branch feature is optional, so those branches are currently not present in all repositories that the PR bot operates on. This configuration is done in the notifier bot, as that is currently the only bot that needs to know about it, so the PR bot does not know if the feature is active. It would have to check for the presence of such a branch at integration time, and we would have to trust that no other branches with such names ever show up in repos where we haven't activated the pr/X feature. I don't think the proposed strategy of using the pr/X branches to trick the forge into marking a PR as "merged" is viable for us. To me, the tradeoff between extra complications and the potential gain isn't worth it. ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 3 17:19:45 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 17:19:45 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:01:01 GMT, Erik Joelsson wrote: > The pr/X branch feature is optional, so those branches are currently not present in all repositories that the PR bot operates on. My mistake, I misunderstood the original comment, I didn't realize that the PR bot had no way of telling if the feature was active on the main repos ------------- PR: https://git.openjdk.org/skara/pull/1409 From zsong at openjdk.org Thu Nov 3 18:27:03 2022 From: zsong at openjdk.org (Zhao Song) Date: Thu, 3 Nov 2022 18:27:03 GMT Subject: RFR: 1660: Add confname field to slack log config In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 20:40:04 GMT, Erik Joelsson wrote: > The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. > > I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. LGTM ------------- Marked as reviewed by zsong (Author). PR: https://git.openjdk.org/skara/pull/1413 From jwaters at openjdk.org Thu Nov 3 18:56:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 18:56:06 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories [v3] In-Reply-To: References: Message-ID: > WIP Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Whitespace - Remove all reliance on the dependency branches ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/8ca08323..ebdace0b Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=01-02 Stats: 19 lines in 1 file changed: 9 ins; 8 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 3 18:59:00 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 18:59:00 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories [v4] In-Reply-To: References: Message-ID: <9Vn0EZkXCHqfR9GZH_vw01ylrJN2CDx3f6kzOEAh4fM=.40894e15-9ef9-43b0-9abc-c8b3f7e99354@github.com> > WIP Julian Waters has updated the pull request incrementally with one additional commit since the last revision: More Whitespace ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/ebdace0b..484f220d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 3 19:15:40 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 3 Nov 2022 19:15:40 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories [v5] In-Reply-To: References: Message-ID: <8lDt78B6N309eXhPi-LgztRTlU4OsjyCxJ7g3DGbGzI=.9b128fd3-2eab-4c77-a808-5291f4dddda1@github.com> > WIP Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Make code a little neater ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/484f220d..804df720 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Fri Nov 4 13:12:10 2022 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 4 Nov 2022 13:12:10 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in GitHub repositories [v6] In-Reply-To: References: Message-ID: > WIP Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Implement by giving the Pull Request bots their own integration branch feature instead ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/804df720..1e79c875 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=05 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=04-05 Stats: 29 lines in 2 files changed: 19 ins; 1 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From ehelin at openjdk.org Fri Nov 4 13:35:06 2022 From: ehelin at openjdk.org (Erik Helin) Date: Fri, 4 Nov 2022 13:35:06 GMT Subject: RFR: 1660: Add confname field to slack log config In-Reply-To: References: Message-ID: <6w4gY8-aXiFySsgXuWwniuDIX23t98NPeVkQF9GdT9Q=.f2d4ac15-73be-400e-9c6f-a3f4c3bd5102@github.com> On Wed, 2 Nov 2022 20:40:04 GMT, Erik Joelsson wrote: > The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. > > I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. Hey Erik, nice work! Just two questions on the patch: - why keep the field and config value `username`? If modern Slack hooks do not allow a username to be chosen, then shouldn't we remove that property from the config and the corresponding field from `BotSlackHandler`? - I would probably have used the name `prefix` instead of `configname` for the configuration setting, it is an arbitrary prefix that we just happen to set to the name of the configuration ? Thanks, Erik ------------- PR: https://git.openjdk.org/skara/pull/1413 From ehelin at openjdk.org Fri Nov 4 13:42:10 2022 From: ehelin at openjdk.org (Erik Helin) Date: Fri, 4 Nov 2022 13:42:10 GMT Subject: RFR: 1608: Handle shenandoah tags in IssueNotifier In-Reply-To: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> References: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> Message-ID: On Mon, 31 Oct 2022 22:03:19 GMT, Erik Joelsson wrote: > This patch aims to add support for notifying JBS when tags are added in the shenandoah-jdk8u repository. This repository is special because it's a jdk8u 'project' repo that is never going to be merged upstream. Instead it's a downstream repo that produces its own releases. Because of this it has its own fixVersion configured in .jcheck/conf and its own tag format, to keep them apart from the main JDK jdk8u tags. > > The logic for matching fixVersions and tags is already a bit convoluted due to conventions that have been added over time. This repo will now add another matching rule. A typical fixVersion would be `shenandoah8u332` and a corresponding tag `shenandoah8u332-b01`. This is actually a pretty neat pattern to match for as the tag prefix is exactly the fixVersion, which is why I agreed to implement support for this. The complicating factors are that for mainline OpenJDK jdk8u we have fixVersion `openjdk8u332` and tag `jdk8u332-b01` (and for Oracle jdk8u the fixVersion is `8u332` but with the same tag format). This special handling of a 'jdk' prefix for a tag, and ignoring any prefix in the fixVersion is what complicates things. > > So currently we ignore any prefix before the main version number in both a tag and fixVersion when matching them. For shenandoah-jdk8u we want to exactly match this prefix. To handle this, I've added a new configuration option for the notifier: > > "issue": { // existing config element > "tag": { // existing config element > "matchprefix": true // new > } > } > > The default value for this option is `false` to reflect the current behavior. When set true, a fixVersion and tag version must match exactly. Note though that the special handling of the tag prefix 'jdk' will still be at play due to the way OpenJDKTag currently parses a JdkVersion from a tag, and I don't dare changing it. This means that if this option is set, then a fixVersion `8u332` will match tags `jdk8u332-b01` and `8u332-b01`, but a fixVersion `jdk8u332` would not match the tag `jdk8u332-b01`. We don't currently use the 'jdk' prefix in any fixVersions in JBS, so this should be fine. I just want to make it clear. This looks good, I know this is a can (swimming pool?) of worms. A future enhancement might be to break apart `IssueNotifier` into multiple cases for different repos, e.g. `Shenandoah8uIssueNotifier`, `JDKIssueNotifier`, `UpdatesIssueNotifier` just to reduce the "branchyness" of the code. This code lead to some code duplication, but it might also maker it the logic for each special case much clearer. Thanks, Erik ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.org/skara/pull/1406 From erikj at openjdk.org Fri Nov 4 13:54:37 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 4 Nov 2022 13:54:37 GMT Subject: RFR: 1660: Add confname field to slack log config In-Reply-To: <6w4gY8-aXiFySsgXuWwniuDIX23t98NPeVkQF9GdT9Q=.f2d4ac15-73be-400e-9c6f-a3f4c3bd5102@github.com> References: <6w4gY8-aXiFySsgXuWwniuDIX23t98NPeVkQF9GdT9Q=.f2d4ac15-73be-400e-9c6f-a3f4c3bd5102@github.com> Message-ID: On Fri, 4 Nov 2022 13:31:31 GMT, Erik Helin wrote: > Hey Erik, nice work! Just two questions on the patch: > > * why keep the field and config value `username`? If modern Slack hooks do not allow a username to be chosen, then shouldn't we remove that property from the config and the corresponding field from `BotSlackHandler`? I'm not sure if this is a property of all slack webhooks or just the one app we are able to use at the moment. I figured we could leave the code in there for now and just not configure a username. > * I would probably have used the name `prefix` instead of `configname` for the configuration setting, it is an arbitrary prefix that we just happen to set to the name of the configuration ? That is a good idea. I will change it. ------------- PR: https://git.openjdk.org/skara/pull/1413 From erikj at openjdk.org Fri Nov 4 13:58:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 4 Nov 2022 13:58:58 GMT Subject: RFR: 1660: Add confname field to slack log config [v2] In-Reply-To: References: Message-ID: > The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. > > I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Change configname to prefix ------------- Changes: - all: https://git.openjdk.org/skara/pull/1413/files - new: https://git.openjdk.org/skara/pull/1413/files/978e28aa..1da43017 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1413&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1413&range=00-01 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1413.diff Fetch: git fetch https://git.openjdk.org/skara pull/1413/head:pull/1413 PR: https://git.openjdk.org/skara/pull/1413 From ehelin at openjdk.org Fri Nov 4 14:05:17 2022 From: ehelin at openjdk.org (Erik Helin) Date: Fri, 4 Nov 2022 14:05:17 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:12:11 GMT, Erik Joelsson wrote: > The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. > > Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. > > This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. > > I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. > > The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reversed . My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. Looks much better. just a minor suggestion. I would also have renamed `recheckIn` to `retry`, but that is just my personal (a bit more terse) style. Thanks, Erik bots/testinfo/src/main/java/org/openjdk/skara/bots/testinfo/TestInfoBot.java line 63: > 61: .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr, > 62: recheckIn -> poller.retryPullRequest(pr, Instant.now().plus(recheckIn)))) > 63: .toList(); Suggestion: var now = Instant.now(); var prs = poller.updatedPullRequests(); return prs.stream() .filter(pr -> pr.sourceRepository().isPresent()) .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr, delay -> poller.retryPullRequest(pr, now.plus(delay)))) .toList(); ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.org/skara/pull/1411 From erikj at openjdk.org Fri Nov 4 14:28:13 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 4 Nov 2022 14:28:13 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: > The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. > > Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. > > This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. > > I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. > > The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reversed . My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/skara/pull/1411/files - new: https://git.openjdk.org/skara/pull/1411/files/4cc4ab09..8485b360 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1411&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1411&range=00-01 Stats: 12 lines in 2 files changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.org/skara/pull/1411.diff Fetch: git fetch https://git.openjdk.org/skara pull/1411/head:pull/1411 PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Fri Nov 4 16:16:33 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 16:16:33 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v3] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: need import network ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/3b05cc5f..ced5742b Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=01-02 Stats: 326 lines in 6 files changed: 281 ins; 11 del; 34 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Fri Nov 4 16:19:53 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 16:19:53 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v4] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into SKARA-1393 # Conflicts: # bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java - need import network ------------- Changes: https://git.openjdk.org/skara/pull/1407/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=03 Stats: 393 lines in 6 files changed: 347 ins; 12 del; 34 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Fri Nov 4 16:27:07 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 16:27:07 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v4] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 16:19:53 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: > > - Merge branch 'master' into SKARA-1393 > > # Conflicts: > # bots/pr/src/test/java/org/openjdk/skara/bots/pr/CheckTests.java > - need import network bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 82: > 80: conf = Optional.empty(); > 81: } > 82: return conf.map(JCheckConfiguration::parse); First, when we try to read the `.jcheck/conf` from the remote repo, maybe the request will throw `uncheckedRestException`. Only when the status code is `404`, conf will be set to `Optional.empty()`, so that it will be treated as `MissingJcheckConfException` later. bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 102: > 100: throw e; > 101: } > 102: throw new InvalidJCheckConfException(e); Here, if we meet some `uncheckedRestException`, we just throw it, otherwise it will be treated as `InvalidJCheckConfException` as well. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Fri Nov 4 17:02:06 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 17:02:06 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v5] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Used UncheckedRestException ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/adfc87e0..7d429d61 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=03-04 Stats: 26 lines in 6 files changed: 12 ins; 4 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Fri Nov 4 21:35:03 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 21:35:03 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:28:13 GMT, Erik Joelsson wrote: >> The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. >> >> Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. >> >> This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. >> >> I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. >> >> The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reverse d. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments The new `TestHostedRepository#allChecks` is much more intuitive and understandable for me! ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Fri Nov 4 22:08:44 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 22:08:44 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:28:13 GMT, Erik Joelsson wrote: >> The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. >> >> Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. >> >> This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. >> >> I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. >> >> The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reverse d. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Hi Erik, You mentioned > For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. And I am thinking that we will update checks in the end of `TestInfoBotWorkItem#run`, so whether a pr will be considered as 'updated' if the checks are updated. And if so, I think in the next call of `getPeriodicItems`, the bot will also schedule another `WorkItem`. ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Fri Nov 4 22:27:59 2022 From: zsong at openjdk.org (Zhao Song) Date: Fri, 4 Nov 2022 22:27:59 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:28:13 GMT, Erik Joelsson wrote: >> The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. >> >> Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. >> >> This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. >> >> I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. >> >> The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reverse d. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I just made more tests and found the checks will always be updated and I thought it's strange. After that , I found a typo at line149 in `TestInfoBotWorkItem#run` if ((current.status() != check.status()) || (!current.summary().equals(check.summary())) || (!current.title().equals(check.summary()))) { It should not be `!current.title().equals(check.summary()` ------------- PR: https://git.openjdk.org/skara/pull/1411 From jwaters at openjdk.org Sat Nov 5 07:55:21 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 5 Nov 2022 07:55:21 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v7] In-Reply-To: References: Message-ID: > WIP Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Of course I got the import order wrong, classic ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/1e79c875..673e95d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=06 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=05-06 Stats: 47 lines in 2 files changed: 21 ins; 23 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sat Nov 5 15:44:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 5 Nov 2022 15:44:18 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v8] In-Reply-To: References: Message-ID: > WIP Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Implement merging for GitLab ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/673e95d9..d90f9042 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=07 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=06-07 Stats: 11 lines in 1 file changed: 4 ins; 1 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 12:24:14 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 12:24:14 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v9] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Change integration branch format and temporarily disable retryAfterInterrupt tests ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/d90f9042..a5cf28c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=08 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=07-08 Stats: 4 lines in 3 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 12:41:46 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 12:41:46 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v10] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Re-enable retryAfterInterrupt tests, they were not the issue ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/a5cf28c7..eae045d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=09 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=08-09 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 13:38:24 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 13:38:24 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v11] In-Reply-To: References: Message-ID: <75WOs8SHGdSdBd4HG-VmkzfLnXuc146hwNBbaMyJLjE=.665cfa61-d329-42fe-9b58-41acde555c8e@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Branch naming ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/eae045d6..dadc5d87 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=10 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=09-10 Stats: 43 lines in 3 files changed: 27 ins; 10 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 13:41:56 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 13:41:56 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v12] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/dadc5d87..8f2f06ed Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=11 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=10-11 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 14:24:18 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 14:24:18 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v13] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Try resetting ref back to initial branch ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/8f2f06ed..a84bc918 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=12 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=11-12 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 6 15:50:36 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 6 Nov 2022 15:50:36 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v14] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Small changes ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/a84bc918..72191afb Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=13 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=12-13 Stats: 14 lines in 2 files changed: 13 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From ehelin at openjdk.org Mon Nov 7 09:20:43 2022 From: ehelin at openjdk.org (Erik Helin) Date: Mon, 7 Nov 2022 09:20:43 GMT Subject: RFR: 1660: Add confname field to slack log config [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 13:58:58 GMT, Erik Joelsson wrote: >> The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. >> >> I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Change configname to prefix Marked as reviewed by ehelin (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1413 From ehelin at openjdk.org Mon Nov 7 09:20:43 2022 From: ehelin at openjdk.org (Erik Helin) Date: Mon, 7 Nov 2022 09:20:43 GMT Subject: RFR: 1660: Add confname field to slack log config [v2] In-Reply-To: References: <6w4gY8-aXiFySsgXuWwniuDIX23t98NPeVkQF9GdT9Q=.f2d4ac15-73be-400e-9c6f-a3f4c3bd5102@github.com> Message-ID: On Fri, 4 Nov 2022 13:51:17 GMT, Erik Joelsson wrote: > > Hey Erik, nice work! Just two questions on the patch: > > > > * why keep the field and config value `username`? If modern Slack hooks do not allow a username to be chosen, then shouldn't we remove that property from the config and the corresponding field from `BotSlackHandler`? > > I'm not sure if this is a property of all slack webhooks or just the one app we are able to use at the moment. I figured we could leave the code in there for now and just not configure a username. Ok, yeah, lets leave it in for a while. ------------- PR: https://git.openjdk.org/skara/pull/1413 From ehelin at openjdk.org Mon Nov 7 09:26:15 2022 From: ehelin at openjdk.org (Erik Helin) Date: Mon, 7 Nov 2022 09:26:15 GMT Subject: RFR: 1594: Convert rest of bots polling PRs and Issues to use new pollers In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:19:52 GMT, Erik Joelsson wrote: > The new PullRequestPoller has now been in use in the PullRequestBot for a while, and hopefully most of the kinks have been ironed out. I think it's time to convert the rest of the bots that poll PRs (and the CSRIssueBot that polls Issues) to use the new pollers. > > The conversion is pretty straight forward. In the case of the CSRBots, they were missing the retry callback, so I added that functionality in line with other bots. > > The new factory tests needed to be modified slightly, as the PullRequestPoller calls to the Forge/Host object of a repository during initialization, so we need a TestHost instance there instead of `null`. > > I deliberately left out two bots here, the JEPBot and the TestInfoBot. The TestInfoBot is handled separately already in #1411. For the JEPBot, I think it needs a general overhaul. In the end it should function more or less the same as the CSRBot, but I'm still not sure that the CSRBot is where I want it to be. Looks good, the code using `PullRequestPoller` turned out much nicer ? I feel like I'm always comment on naming, feel free to ignore such suggestions, they are just suggestions ? In this case I would have renamed `PullRequestPoller.lastBatchHandled` to `PullRequestPoller.ignore(List prs)` and the bots would typically call `poller.ignore(prs);` ------------- Marked as reviewed by ehelin (Reviewer). PR: https://git.openjdk.org/skara/pull/1412 From zsong at openjdk.org Mon Nov 7 23:23:44 2022 From: zsong at openjdk.org (Zhao Song) Date: Mon, 7 Nov 2022 23:23:44 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck Message-ID: SKARA-1655 describes a problem related with invalid jcheck config in a new change. Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. ------------- Commit messages: - SKARA-1655 Changes: https://git.openjdk.org/skara/pull/1415/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1655 Stats: 363 lines in 9 files changed: 362 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 8 00:19:38 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 00:19:38 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v2] In-Reply-To: References: Message-ID: > SKARA-1655 describes a problem related with invalid jcheck config in a new change. > > Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally > changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. > > In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1415/files - new: https://git.openjdk.org/skara/pull/1415/files/5695e098..55807823 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=00-01 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 8 00:39:49 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 00:39:49 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v3] In-Reply-To: References: Message-ID: <6P63bRdv53_r4_WpxuvfkVZtBPn84aDzbxnkn2lP4l8=.09e84684-0e27-4d6a-a077-bee8d023b697@github.com> > SKARA-1655 describes a problem related with invalid jcheck config in a new change. > > Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally > changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. > > In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update JCheckConfCheckTests ------------- Changes: - all: https://git.openjdk.org/skara/pull/1415/files - new: https://git.openjdk.org/skara/pull/1415/files/55807823..1fbf33a5 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 8 00:47:50 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 00:47:50 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v4] In-Reply-To: References: Message-ID: > SKARA-1655 describes a problem related with invalid jcheck config in a new change. > > Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally > changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. > > In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update test again ------------- Changes: - all: https://git.openjdk.org/skara/pull/1415/files - new: https://git.openjdk.org/skara/pull/1415/files/1fbf33a5..cbf32cb4 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 8 00:53:29 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 00:53:29 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v5] In-Reply-To: References: Message-ID: > SKARA-1655 describes a problem related with invalid jcheck config in a new change. > > Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally > changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. > > In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update JCheckConfCheckTests ------------- Changes: - all: https://git.openjdk.org/skara/pull/1415/files - new: https://git.openjdk.org/skara/pull/1415/files/cbf32cb4..79c073a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=03-04 Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 8 02:33:47 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 02:33:47 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v6] In-Reply-To: References: Message-ID: > SKARA-1655 describes a problem related with invalid jcheck config in a new change. > > Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally > changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. > > In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1415/files - new: https://git.openjdk.org/skara/pull/1415/files/79c073a9..f5831548 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=05 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1415&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1415.diff Fetch: git fetch https://git.openjdk.org/skara pull/1415/head:pull/1415 PR: https://git.openjdk.org/skara/pull/1415 From ihse at openjdk.org Tue Nov 8 08:58:58 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 08:58:58 GMT Subject: RFR: 1594: Convert rest of bots polling PRs and Issues to use new pollers In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:19:52 GMT, Erik Joelsson wrote: > The new PullRequestPoller has now been in use in the PullRequestBot for a while, and hopefully most of the kinks have been ironed out. I think it's time to convert the rest of the bots that poll PRs (and the CSRIssueBot that polls Issues) to use the new pollers. > > The conversion is pretty straight forward. In the case of the CSRBots, they were missing the retry callback, so I added that functionality in line with other bots. > > The new factory tests needed to be modified slightly, as the PullRequestPoller calls to the Forge/Host object of a repository during initialization, so we need a TestHost instance there instead of `null`. > > I deliberately left out two bots here, the JEPBot and the TestInfoBot. The TestInfoBot is handled separately already in #1411. For the JEPBot, I think it needs a general overhaul. In the end it should function more or less the same as the CSRBot, but I'm still not sure that the CSRBot is where I want it to be. Nice to get this in place! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1412 From ihse at openjdk.org Tue Nov 8 09:03:50 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 09:03:50 GMT Subject: RFR: 1660: Add confname field to slack log config [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 13:58:58 GMT, Erik Joelsson wrote: >> The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. >> >> I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Change configname to prefix The patch looks good. but I'm thinking if you should use some delimiter for the prefix, like `[` ... `]`. Or is the plan to make formatting for the prefix to be clearly marked as a prefix in the configuration? (I'm just worried that if this is not done properly it can be hard to distinguish the prefix from the message proper, making it look odd) ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1413 From ihse at openjdk.org Tue Nov 8 09:09:27 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 09:09:27 GMT Subject: RFR: 1608: Handle shenandoah tags in IssueNotifier In-Reply-To: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> References: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> Message-ID: On Mon, 31 Oct 2022 22:03:19 GMT, Erik Joelsson wrote: > This patch aims to add support for notifying JBS when tags are added in the shenandoah-jdk8u repository. This repository is special because it's a jdk8u 'project' repo that is never going to be merged upstream. Instead it's a downstream repo that produces its own releases. Because of this it has its own fixVersion configured in .jcheck/conf and its own tag format, to keep them apart from the main JDK jdk8u tags. > > The logic for matching fixVersions and tags is already a bit convoluted due to conventions that have been added over time. This repo will now add another matching rule. A typical fixVersion would be `shenandoah8u332` and a corresponding tag `shenandoah8u332-b01`. This is actually a pretty neat pattern to match for as the tag prefix is exactly the fixVersion, which is why I agreed to implement support for this. The complicating factors are that for mainline OpenJDK jdk8u we have fixVersion `openjdk8u332` and tag `jdk8u332-b01` (and for Oracle jdk8u the fixVersion is `8u332` but with the same tag format). This special handling of a 'jdk' prefix for a tag, and ignoring any prefix in the fixVersion is what complicates things. > > So currently we ignore any prefix before the main version number in both a tag and fixVersion when matching them. For shenandoah-jdk8u we want to exactly match this prefix. To handle this, I've added a new configuration option for the notifier: > > "issue": { // existing config element > "tag": { // existing config element > "matchprefix": true // new > } > } > > The default value for this option is `false` to reflect the current behavior. When set true, a fixVersion and tag version must match exactly. Note though that the special handling of the tag prefix 'jdk' will still be at play due to the way OpenJDKTag currently parses a JdkVersion from a tag, and I don't dare changing it. This means that if this option is set, then a fixVersion `8u332` will match tags `jdk8u332-b01` and `8u332-b01`, but a fixVersion `jdk8u332` would not match the tag `jdk8u332-b01`. We don't currently use the 'jdk' prefix in any fixVersions in JBS, so this should be fine. I just want to make it clear. Looks good, as far as I can tell. I agree with Erik that here be worms (and dragons). I wish it were possible to get a organization-wide grip on the problem and reorganize the principles behind tags, but I realize how futile such a wish is... ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1406 From ihse at openjdk.org Tue Nov 8 09:22:42 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 09:22:42 GMT Subject: RFR: 1538: Allow regex patterns in fixversions and altfixversions in the notifier In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 22:44:07 GMT, Erik Joelsson wrote: > This patch adds support for regex patterns when specifying fixVersions and altFixVersions in the IssueNotifier. For fixVersions, the branch name can now be a regex pattern and for the altFixVersions, both the branch name as well as the version strings in the array can all be regex patterns. Having this flexibility will enable us to construct much more static configurations for certain repositories, that don't need manual updating each time we fork or branch a new release. Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1414 From ihse at openjdk.org Tue Nov 8 10:25:50 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 10:25:50 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 14:28:13 GMT, Erik Joelsson wrote: >> The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. >> >> Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. >> >> This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. >> >> I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. >> >> The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reverse d. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments Basically looks good to me (with the exception of the `now` issue). bots/testinfo/src/main/java/org/openjdk/skara/bots/testinfo/TestInfoBot.java line 63: > 61: .filter(pr -> pr.sourceRepository().isPresent()) > 62: .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr, > 63: delay -> poller.retryPullRequest(pr, now.plus(delay)))) Maybe I'm getting lost here, but this feels wrong to me. The `now` is computed as the now of the call to `getPeriodicItems()`, but it is used in the lambda for the `retry` operation of `TestInfoBotWorkItem`. But that retry should happen `delay` time after it is evaluated, right? It might not have much practical impact, but it just looks odd to me, like mixing different time streams. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1411 From ihse at openjdk.org Tue Nov 8 10:33:18 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 10:33:18 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 10:22:58 GMT, Magnus Ihse Bursie wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments > > bots/testinfo/src/main/java/org/openjdk/skara/bots/testinfo/TestInfoBot.java line 63: > >> 61: .filter(pr -> pr.sourceRepository().isPresent()) >> 62: .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr, >> 63: delay -> poller.retryPullRequest(pr, now.plus(delay)))) > > Maybe I'm getting lost here, but this feels wrong to me. The `now` is computed as the now of the call to `getPeriodicItems()`, but it is used in the lambda for the `retry` operation of `TestInfoBotWorkItem`. But that retry should happen `delay` time after it is evaluated, right? > > It might not have much practical impact, but it just looks odd to me, like mixing different time streams. To expand a bit: the `now.plus(delay)` will be evaluated in the `run` method of the work item, but then the result will be offset not from the time of `run` but from the time of the call to this method. What would happen if it, for some reason, would take more than 2 minutes between these two events, and we'd get a time in the past. Will it be retried immediately, or will it cause trouble with the poller? And also it feel conceptually wrong; the retry time feels like it should be specified from when the decision is made for the next check. ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Tue Nov 8 21:47:36 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 8 Nov 2022 21:47:36 GMT Subject: RFR: 1658: Minimize race window when updating PR body Message-ID: Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. This is a race between the bot and user and the race window is a little big right now. To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. ------------- Commit messages: - SKARA-1658 Changes: https://git.openjdk.org/skara/pull/1416/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1416&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1658 Stats: 56 lines in 8 files changed: 53 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1416.diff Fetch: git fetch https://git.openjdk.org/skara pull/1416/head:pull/1416 PR: https://git.openjdk.org/skara/pull/1416 From ihse at openjdk.org Tue Nov 8 23:22:23 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 8 Nov 2022 23:22:23 GMT Subject: RFR: 1658: Minimize race window when updating PR body In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 21:43:02 GMT, Zhao Song wrote: > Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. > > This is a race between the bot and user and the race window is a little big right now. > > To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. forge/src/test/java/org/openjdk/skara/forge/github/GitHubRestApiTests.java line 159: > 157: var testPr = testRepo.pullRequest("99"); > 158: > 159: String latestBody = testPr.latestBody(); This looks a bit fragile, but maybe that's a price we have to pay for the manual tests. However, I think you should also add an automatic test, that verifies that an updated body makes the bot skip the update that time around, but not otherwise. I think it will be possible to define such a setup without having to resort to race-prone logic. ------------- PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 00:16:02 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 00:16:02 GMT Subject: RFR: 1658: Minimize race window when updating PR body In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 23:18:56 GMT, Magnus Ihse Bursie wrote: >> Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. >> >> This is a race between the bot and user and the race window is a little big right now. >> >> To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. > > forge/src/test/java/org/openjdk/skara/forge/github/GitHubRestApiTests.java line 159: > >> 157: var testPr = testRepo.pullRequest("99"); >> 158: >> 159: String latestBody = testPr.latestBody(); > > This looks a bit fragile, but maybe that's a price we have to pay for the manual tests. > > However, I think you should also add an automatic test, that verifies that an updated body makes the bot skip the update that time around, but not otherwise. I think it will be possible to define such a setup without having to resort to race-prone logic. Thank you for the review and suggestion! I will try to add an automatic test, but I need to change some logic related with body in TestPullRequest. ------------- PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 00:30:51 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 00:30:51 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v2] In-Reply-To: References: Message-ID: > Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. > > This is a race between the bot and user and the race window is a little big right now. > > To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Added an automatic test for latestBody ------------- Changes: - all: https://git.openjdk.org/skara/pull/1416/files - new: https://git.openjdk.org/skara/pull/1416/files/e1d4a105..d2194a68 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1416&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1416&range=00-01 Stats: 52 lines in 2 files changed: 51 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1416.diff Fetch: git fetch https://git.openjdk.org/skara pull/1416/head:pull/1416 PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 00:33:48 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 00:33:48 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v2] In-Reply-To: References: Message-ID: <6q9JapibCG1u71hbQq4j57vF3kbZbobvl0epggvlDb8=.131334c6-860f-4af4-b135-f7e155349e99@github.com> On Wed, 9 Nov 2022 00:30:51 GMT, Zhao Song wrote: >> Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. >> >> This is a race between the bot and user and the race window is a little big right now. >> >> To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Added an automatic test for latestBody test/src/main/java/org/openjdk/skara/test/TestIssue.java line 94: > 92: @Override > 93: public String body() { > 94: return body; Make `TestIssue#body()` consistent with `GitHubPullRequest#body()` and `GitLabMergeRequest#body()`. It was returning the latest body from the 'remote' instead of the cache. So it is different from `GitHubPullRequest` and `GitLabMergeRequest` ------------- PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 00:46:54 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 00:46:54 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v2] In-Reply-To: <6q9JapibCG1u71hbQq4j57vF3kbZbobvl0epggvlDb8=.131334c6-860f-4af4-b135-f7e155349e99@github.com> References: <6q9JapibCG1u71hbQq4j57vF3kbZbobvl0epggvlDb8=.131334c6-860f-4af4-b135-f7e155349e99@github.com> Message-ID: On Wed, 9 Nov 2022 00:31:31 GMT, Zhao Song wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Added an automatic test for latestBody > > test/src/main/java/org/openjdk/skara/test/TestIssue.java line 94: > >> 92: @Override >> 93: public String body() { >> 94: return body; > > Make `TestIssue#body()` consistent with `GitHubPullRequest#body()` and `GitLabMergeRequest#body()`. > > It was returning the latest body from the 'remote' instead of the cache. So it is different from `GitHubPullRequest` and `GitLabMergeRequest` This change would make some tests fail. We need to update the tests, and I wonder whether it is better to file another bug to make this change and update related tests. ------------- PR: https://git.openjdk.org/skara/pull/1416 From ihse at openjdk.org Wed Nov 9 10:16:17 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 9 Nov 2022 10:16:17 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v2] In-Reply-To: References: <6q9JapibCG1u71hbQq4j57vF3kbZbobvl0epggvlDb8=.131334c6-860f-4af4-b135-f7e155349e99@github.com> Message-ID: On Wed, 9 Nov 2022 00:43:30 GMT, Zhao Song wrote: >> test/src/main/java/org/openjdk/skara/test/TestIssue.java line 94: >> >>> 92: @Override >>> 93: public String body() { >>> 94: return body; >> >> Make `TestIssue#body()` consistent with `GitHubPullRequest#body()` and `GitLabMergeRequest#body()`. >> >> It was returning the latest body from the 'remote' instead of the cache. So it is different from `GitHubPullRequest` and `GitLabMergeRequest` > > This change would make some tests fail. We need to update the tests, and I wonder whether it is better to file another bug to make this change and update related tests. In effect, it sounds like `TestIssue` did not properly mimick the real classes. So fixing this, and fixing the tests so they pass, is probably a good idea. Maybe you should do that separately, yes, and integrate that first. Then you can easily add a proper test to this PR. ------------- PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 16:52:52 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 16:52:52 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v2] In-Reply-To: References: <6q9JapibCG1u71hbQq4j57vF3kbZbobvl0epggvlDb8=.131334c6-860f-4af4-b135-f7e155349e99@github.com> Message-ID: On Wed, 9 Nov 2022 10:12:48 GMT, Magnus Ihse Bursie wrote: > In effect, it sounds like `TestIssue` did not properly mimick the real classes. So fixing this, and fixing the tests so they pass, is probably a good idea. Maybe you should do that separately, yes, and integrate that first. Then you can easily add a proper test to this PR. Got it! Thx! ------------- PR: https://git.openjdk.org/skara/pull/1416 From zsong at openjdk.org Wed Nov 9 19:10:31 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 9 Nov 2022 19:10:31 GMT Subject: RFR: 1670: Make body handling consistent in all Issue implementations Message-ID: When fixing [SKARA-1658](https://bugs.openjdk.org/browse/SKARA-1658), I found the `TestIssue#body` didn't mimic `GitHubPullRequest#body` and` GitLabMergeRequest#body` properly. So this will block SKARA-1658. The `body()` method in `TestIssue` always returns the latest body from the 'remote' instead of the cache. So it behaves different from GitHubPullRequest and GitLabMergeRequest. In this patch, `TestIssue#body` will return the cached body like `GitHubPullRequest#body` and` GitLabMergeRequest#body`. Also updated related tests. ------------- Commit messages: - SKARA-1670 Changes: https://git.openjdk.org/skara/pull/1417/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1417&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1670 Stats: 125 lines in 9 files changed: 0 ins; 0 del; 125 mod Patch: https://git.openjdk.org/skara/pull/1417.diff Fetch: git fetch https://git.openjdk.org/skara pull/1417/head:pull/1417 PR: https://git.openjdk.org/skara/pull/1417 From jwaters at openjdk.org Thu Nov 10 03:08:00 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 03:08:00 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v15] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: @ looks way better than # ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/72191afb..3fcc5137 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=14 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=13-14 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 13:31:44 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 13:31:44 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v16] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Missed an optional.get() call ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/3fcc5137..bac2d40d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=15 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 17:14:22 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 17:14:22 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v17] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Add debugging code ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/bac2d40d..37b6501c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=16 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=15-16 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 17:29:55 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 17:29:55 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v18] In-Reply-To: References: Message-ID: <895D0myWrxOMXAelasFNjBw3oV9hozb96eCnbKzUoJI=.6828f300-ca47-409e-8016-1ec224701d59@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Change debugging ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/37b6501c..94101112 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=17 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=16-17 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 17:48:17 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 17:48:17 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v19] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Resolve attempt..? ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/94101112..26eefcce Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=18 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 18:00:51 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 18:00:51 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v20] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Dumbest idea ever ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/26eefcce..70eb3c3f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=19 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=18-19 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 18:09:36 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 18:09:36 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v21] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: ... ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/70eb3c3f..3317161e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=20 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=19-20 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 18:24:39 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 18:24:39 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v22] In-Reply-To: References: Message-ID: <7ClWf3Y31k6bLYMDSMSVm8_4V6F7ZbaQfJ1JcL_wHYA=.a3b3d198-7ae8-4330-9a12-0b54cd688f56@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Help me ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/3317161e..6bfaf50f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=21 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=20-21 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 18:37:53 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 18:37:53 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v23] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Maybe this will work(?) ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/6bfaf50f..edf40542 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=22 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=21-22 Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 18:52:06 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 18:52:06 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v24] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: ... ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/edf40542..b931538c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=23 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=22-23 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 19:02:08 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 19:02:08 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v25] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert resetting of target ref ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/b931538c..50baa250 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=24 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=23-24 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Nov 10 19:14:21 2022 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 10 Nov 2022 19:14:21 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v26] In-Reply-To: References: Message-ID: <6qVdsA9NV5CI7YXRXxu85dWU3GXN4VtGGB0VHMWcxUs=.c5d9d7fe-1675-468f-9b41-380fe1e63585@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Revert last revert, but without the comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/50baa250..4b4d23cd Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=25 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=24-25 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From zsong at openjdk.org Thu Nov 10 19:24:00 2022 From: zsong at openjdk.org (Zhao Song) Date: Thu, 10 Nov 2022 19:24:00 GMT Subject: RFR: 1673: CSR bot should be able to handle a withdrawn CSR properly Message-ID: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> A user reported that skara bot keeps changing the description in his MR. After investigation, we found a bug related with CSR bot. The user linked a CSR issue with the main issue, and after that, he found CSR unneeded and withdrawn the CSR issue. However, our logic about handling withdrawn CSR issue has some problem. In PullRequestWorkItem#run, the bot would add updateMarker() to the PR body regardless of the state of CSR issue. And if a PR body contains the updateMarker, it will be updated periodically until the body contains a CSR progress. However, since our CSR issue is withdrawn, the CSR label would not be added to the pr and CSR progress would not be added to the PR body. So it will be an endless loop. In summary, the bug would happen in such a case, the user withdraw the csr issue before the csr issue bot first time run. In this patch, before the CSR Issue bot is trying to add the updateMarker, it will check the resolution of the CSR Issue first, if the CSR Issue is already withdrawn, then updateMarker would not be added to the PR body. And PR bot would work normally. ------------- Commit messages: - SKARA-1673 Changes: https://git.openjdk.org/skara/pull/1418/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1418&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1673 Stats: 66 lines in 2 files changed: 65 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1418.diff Fetch: git fetch https://git.openjdk.org/skara pull/1418/head:pull/1418 PR: https://git.openjdk.org/skara/pull/1418 From ihse at openjdk.org Fri Nov 11 11:41:39 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 11 Nov 2022 11:41:39 GMT Subject: RFR: 1674: Skara bot is not closing the bug after merge request is integrated Message-ID: This is a tentative fix for [SKARA-1674](https://bugs.openjdk.org/browse/SKARA-1674). This fix simply reverts [SKARA-1479](https://bugs.openjdk.org/browse/SKARA-1479). It will (most likely) fix the more urgent issue of the bots not being able to close pull requests, at the expense of reintroducing the problem with the Dukebot user assignment that SKARA-1479 tried to fix. Unfortunately Erik is out of office, so I think this is the best we can do at the moment, and then we can file a REDO bug for SKARA-1479, to re-implement it but more robustly. ------------- Commit messages: - 1674: Skara bot is not closing the bug after merge request is integrated Changes: https://git.openjdk.org/skara/pull/1419/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1419&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1674 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1419.diff Fetch: git fetch https://git.openjdk.org/skara pull/1419/head:pull/1419 PR: https://git.openjdk.org/skara/pull/1419 From kcr at openjdk.org Fri Nov 11 14:03:22 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Fri, 11 Nov 2022 14:03:22 GMT Subject: RFR: 1674: Skara bot is not closing the bug after merge request is integrated In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 11:38:16 GMT, Magnus Ihse Bursie wrote: > This is a tentative fix for [SKARA-1674](https://bugs.openjdk.org/browse/SKARA-1674). This fix simply reverts [SKARA-1479](https://bugs.openjdk.org/browse/SKARA-1479). It will (most likely) fix the more urgent issue of the bots not being able to close pull requests, at the expense of reintroducing the problem with the Dukebot user assignment that SKARA-1479 tried to fix. > > Unfortunately Erik is out of office, so I think this is the best we can do at the moment, and then we can file a REDO bug for SKARA-1479, to re-implement it but more robustly. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.org/skara/pull/1419 From ihse at openjdk.org Fri Nov 11 15:00:25 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 11 Nov 2022 15:00:25 GMT Subject: Integrated: 1674: Skara bot is not closing the bug after merge request is integrated In-Reply-To: References: Message-ID: On Fri, 11 Nov 2022 11:38:16 GMT, Magnus Ihse Bursie wrote: > This is a tentative fix for [SKARA-1674](https://bugs.openjdk.org/browse/SKARA-1674). This fix simply reverts [SKARA-1479](https://bugs.openjdk.org/browse/SKARA-1479). It will (most likely) fix the more urgent issue of the bots not being able to close pull requests, at the expense of reintroducing the problem with the Dukebot user assignment that SKARA-1479 tried to fix. > > Unfortunately Erik is out of office, so I think this is the best we can do at the moment, and then we can file a REDO bug for SKARA-1479, to re-implement it but more robustly. This pull request has now been integrated. Changeset: fbbec971 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/skara/commit/fbbec971ef6fb878a67f8ea048f1def2f146497b Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 1674: Skara bot is not closing the bug after merge request is integrated Reviewed-by: kcr ------------- PR: https://git.openjdk.org/skara/pull/1419 From jwaters at openjdk.org Sat Nov 12 15:40:00 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 12 Nov 2022 15:40:00 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v27] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Accidental removal in PreIntegrations - Revert changes to PreIntegrations, they're not needed ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/4b4d23cd..c608c108 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=26 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=25-26 Stats: 50 lines in 2 files changed: 0 ins; 47 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sat Nov 12 15:52:22 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 12 Nov 2022 15:52:22 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v28] In-Reply-To: References: Message-ID: <8u-F3nc0kP1tBE_yZygyYss47IOYVHNph2xrtCW5-8Y=.b6fe0fc6-283c-4164-829a-328deca89347@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and GitLab being unlikely to make a similar change either, we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Minor Style Changes ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/c608c108..8417bd8d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=27 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=26-27 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 13 09:21:11 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 09:21:11 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v29] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Move Pull Request merging into its own method ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/8417bd8d..c38176d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=28 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=27-28 Stats: 32 lines in 3 files changed: 30 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 13 09:23:52 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 09:23:52 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v30] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Unwanted import ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/c38176d5..c9b3386b Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=29 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=28-29 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 13 09:28:32 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 09:28:32 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v31] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/c9b3386b..ab1ac9d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=30 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=29-30 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Sun Nov 13 09:31:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 13 Nov 2022 09:31:07 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v32] In-Reply-To: References: Message-ID: <1e_7yM3U7FpvGOVbO5_pe3XGLSOHTsWk1oydRSjvE_U=.e3b6de9f-235b-4c0d-91c6-405b70b29afd@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Resolve inheritance issues ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/ab1ac9d5..35b18015 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=31 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=30-31 Stats: 17 lines in 2 files changed: 13 ins; 4 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From dholmes at openjdk.org Sun Nov 13 21:37:59 2022 From: dholmes at openjdk.org (David Holmes) Date: Sun, 13 Nov 2022 21:37:59 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories In-Reply-To: References: Message-ID: On Thu, 3 Nov 2022 17:16:13 GMT, Julian Waters wrote: >>> That's a bit of a bummer, though maybe that can be circumvented with a few instanceof GitHubPullRequests? The change is, after all, only actually implemented for GitHub >> >> I don't understand what you mean by the change only being implemented for GitHub. We strive to keep Skara feature equivalent on GitHub and GitLab. >> >> The pr/X branch feature is optional, so those branches are currently not present in all repositories that the PR bot operates on. This configuration is done in the notifier bot, as that is currently the only bot that needs to know about it, so the PR bot does not know if the feature is active. It would have to check for the presence of such a branch at integration time, and we would have to trust that no other branches with such names ever show up in repos where we haven't activated the pr/X feature. >> >> I don't think the proposed strategy of using the pr/X branches to trick the forge into marking a PR as "merged" is viable for us. To me, the tradeoff between extra complications and the potential gain isn't worth it. > >> The pr/X branch feature is optional, so those branches are currently not present in all repositories that the PR bot operates on. > > My mistake, I misunderstood the original comment; I didn't realize that the PR bot had no way of telling if the feature was active on the main repos @TheShermanTanker this PR is generating a lot of noise on the mailing list. It appears this is still a work-in-progress so perhaps it would be better to return to a draft state until you think it is ready. Thanks. ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Mon Nov 14 01:20:07 2022 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 14 Nov 2022 01:20:07 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v32] In-Reply-To: <1e_7yM3U7FpvGOVbO5_pe3XGLSOHTsWk1oydRSjvE_U=.e3b6de9f-235b-4c0d-91c6-405b70b29afd@github.com> References: <1e_7yM3U7FpvGOVbO5_pe3XGLSOHTsWk1oydRSjvE_U=.e3b6de9f-235b-4c0d-91c6-405b70b29afd@github.com> Message-ID: <9iXAPpawegnKncF50bvyVJv3oQoQ0iVlMLXYX8wZbg0=.64fb4d20-6efc-4393-adac-84a41a09e2e0@github.com> On Sun, 13 Nov 2022 09:31:07 GMT, Julian Waters wrote: >> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. >> >> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Resolve inheritance issues Oops, didn't realize I forgot to mark it as a draft, so sorry for the spam - That said I'm pretty much done, I don't really know what else I can do here without any guidance from further reviews ------------- PR: https://git.openjdk.org/skara/pull/1409 From erik.joelsson at oracle.com Tue Nov 15 14:40:26 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 15 Nov 2022 06:40:26 -0800 Subject: Result: New Skara Committer: Zhao Song Message-ID: <20aeb58e-bef3-2c76-a1a2-5396d54bfd38@oracle.com> Voting for Zhao Song [1] is now closed. Yes: 4 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Erik Joelsson [1] https://mail.openjdk.org/pipermail/skara-dev/2022-October/006761.html From erikj at openjdk.org Tue Nov 15 19:21:29 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 19:21:29 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:02:06 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Used UncheckedRestException This is starting to look pretty good. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CensusInstance.java line 58: > 56: } > 57: > 58: static Optional createCensusInstance(HostedRepositoryPool hostedRepositoryPool, No need to return `Optional` here anymore either. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 236: > 234: } catch (MissingJCheckConfException e) { > 235: if (bot.confOverrideRepository().isEmpty()) { > 236: var text = " ?? @" + pr.author().username() + " The `.jcheck/conf` in the target branch of this pull request is missing completely. " Suggestion: var text = " ?? @" + pr.author().username() + " No `.jcheck/conf` found in the target branch of this pull request. " bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 240: > 238: addErrorComment(text, comments); > 239: } else { > 240: var text = " ?? @" + pr.author().username() + " The external jcheck configuration for this repository could not be resolved. " Suggestion: var text = " ?? @" + pr.author().username() + " The external jcheck configuration for this repository could not be found. " The double "resolved" doesn't read well. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 251: > 249: addErrorComment(text, comments); > 250: } else { > 251: var text = " ?? @" + pr.author().username() + " The external jcheck configuration for this repository could not be resolved. " Suggestion: var text = " ?? @" + pr.author().username() + " The external jcheck configuration for this repository is invalid. " bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java line 133: > 131: log.info("No new commit comments found, stopping further processing"); > 132: } else { > 133: Optional census = Optional.empty(); No need to keep this as an `Optional` either. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java line 144: > 142: var comment = String.format(commandReplyMarker, command.id()) + "\n" + > 143: "@" + command.user().username() + > 144: " there is no `.jcheck/conf` present at revision " + Suggestion: " There is no `.jcheck/conf` present at revision " + bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java line 151: > 149: var comment = String.format(commandReplyMarker, command.id()) + "\n" + > 150: "@" + command.user().username() + > 151: " invalid `.jcheck/conf` present at revision " + Suggestion: " Invalid `.jcheck/conf` present at revision " + bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 57: > 55: var census = Census.parse(repoFolder); > 56: var namespace = namespace(census, repository.namespace()); > 57: return Optional.of(new LimitedCensusInstance(census, configuration, namespace)); No need to return `Optional` here anymore as we throw exception when the configuration is missing. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 15 19:29:11 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 19:29:11 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v5] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 17:02:06 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Used UncheckedRestException One more thing. Any time we catch an `InvalidJcheckConfException` and just print a message to the user, we should also log that exception, so that an admin can more easily investigate what went wrong. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 15 19:32:38 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 19:32:38 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v5] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:25:43 GMT, Erik Joelsson wrote: > One more thing. Any time we catch an `InvalidJcheckConfException` and just print a message to the user, we should also log that exception, so that an admin can more easily investigate what went wrong. Got it! Will add some logs. Thx! ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 15 19:35:55 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 19:35:55 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v6] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 02:33:47 GMT, Zhao Song wrote: >> SKARA-1655 describes a problem related with invalid jcheck config in a new change. >> >> Currently, Skara never checks if the jcheck config is changed in a new change. So for example, if we accidentally >> changed the jcheck config in a change and it was bad formatted, the bot will be in a retry loop and stuck. >> >> In this patch, `JCheckConfCheck` is added to JCheck. If this check is configured, jcheck will check whether the jcheck config is still valid in the new change. If it is not, the specific problem will be added to the PR body and this PR will be blocked to be `ready for review`. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update test Does this change depend on #1407 for the test to pass? ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.org/skara/pull/1415 From zsong at openjdk.org Tue Nov 15 19:43:57 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 19:43:57 GMT Subject: RFR: 1655: A PR/commit with an invalid jcheck config should be caught by jcheck [v6] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:32:51 GMT, Erik Joelsson wrote: > Does this change depend on #1407 for the test to pass? No, I think they are separate. But I prefer to integrate this one after SKARA-1393. Thanks for the review! ------------- PR: https://git.openjdk.org/skara/pull/1415 From erikj at openjdk.org Tue Nov 15 19:47:37 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 19:47:37 GMT Subject: RFR: 1670: Make body handling consistent in all Issue implementations In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 19:06:40 GMT, Zhao Song wrote: > When fixing [SKARA-1658](https://bugs.openjdk.org/browse/SKARA-1658), I found the `TestIssue#body` didn't mimic `GitHubPullRequest#body` and` GitLabMergeRequest#body` properly. So this will block SKARA-1658. > > The `body()` method in `TestIssue` always returns the latest body from the 'remote' instead of the cache. So it behaves different from GitHubPullRequest and GitLabMergeRequest. > > In this patch, `TestIssue#body` will return the cached body like `GitHubPullRequest#body` and `GitLabMergeRequest#body`. Also updated related tests. Good that you made this a separate change and good catch. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.org/skara/pull/1417 From erikj at openjdk.org Tue Nov 15 20:53:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 20:53:58 GMT Subject: RFR: 1673: CSR bot should be able to handle a withdrawn CSR properly In-Reply-To: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> References: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> Message-ID: On Thu, 10 Nov 2022 19:20:41 GMT, Zhao Song wrote: > A user reported that skara bot keeps changing the description in his MR. > > After investigation, we found a bug related with CSR bot. > > The user linked a CSR issue with the main issue, and after that, he found CSR unneeded and withdrawn the CSR issue. > > However, our logic about handling withdrawn CSR issue has some problem. > > In PullRequestWorkItem#run, the bot would add updateMarker() to the PR body regardless of the state of CSR issue. And if a PR body contains the updateMarker, it will be updated periodically until the body contains a CSR progress. However, since our CSR issue is withdrawn, the CSR label would not be added to the pr and CSR progress would not be added to the PR body. So it will be an endless loop. > > In summary, the bug would happen in such a case, the user withdraw the csr issue before the csr issue bot first time run. > > In this patch, before the CSR Issue bot is trying to add the updateMarker, it will check the resolution of the CSR Issue first, if the CSR Issue is already withdrawn, then updateMarker would not be added to the PR body. And PR bot would work normally. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1418 From zsong at openjdk.org Tue Nov 15 21:01:03 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 21:01:03 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v6] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with three additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/7d429d61..aa1a9549 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=05 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=04-05 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 15 21:20:44 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 21:20:44 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v7] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/aa1a9549..eb2ba54f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=06 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=05-06 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 15 22:05:25 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:05:25 GMT Subject: RFR: 1594: Convert rest of bots polling PRs and Issues to use new pollers In-Reply-To: References: Message-ID: On Mon, 7 Nov 2022 09:23:28 GMT, Erik Helin wrote: > I feel like I'm always comment on naming, feel free to ignore such suggestions, they are just suggestions ? In this case I would have renamed `PullRequestPoller.lastBatchHandled` to `PullRequestPoller.ignore(List prs)` and the bots would typically call `poller.ignore(prs);` I'm not completely satisfied with the naming of the methods either, but I don't really get the "ignore" suggestion here. The idea with the method is to acknowledge to the poller that what it returned has now been accepted. In most cases, having this two step ack protocol isn't needed, but in some bots, there are further remote calls made in `getPeriodicItems` after `updatedPullRequests` is called, which could potentially fail, and if they do, I want to make sure the next call to `getPeriodicItems` will include those PRs again. I'm sure you figured this out already. In a separate discussion, you also pointed out that the naming of the `retryPullRequest` methods was strange to you. You may have a point there too. There is also an undocumented requirement in the PullRequestPoller, that `retryPullRequest` must not be called before `lastBatchHandled`. This is how I implicitly assumed it was always going to be used, but it does need to be made explicit, at least in documentation. I will look into this. ------------- PR: https://git.openjdk.org/skara/pull/1412 From erikj at openjdk.org Tue Nov 15 22:06:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:06:44 GMT Subject: RFR: 1660: Add confname field to slack log config [v2] In-Reply-To: References: Message-ID: <6q9CadNw-2diaxLuia3FBu3y1upGbO-Jns5eC8-pVSc=.700a0bc9-1d6c-4c5e-9ed1-b30bac5f7b08@github.com> On Tue, 8 Nov 2022 09:00:47 GMT, Magnus Ihse Bursie wrote: > The patch looks good. but I'm thinking if you should use some delimiter for the prefix, like `[` ... `]`. Or is the plan to make formatting for the prefix to be clearly marked as a prefix in the configuration? (I'm just worried that if this is not done properly it can be hard to distinguish the prefix from the message proper, making it look odd) My plan was to have the prefix added completely raw and put any formatting in the config. That makes it more flexible and easier to change as well. ------------- PR: https://git.openjdk.org/skara/pull/1413 From erikj at openjdk.org Tue Nov 15 22:14:38 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:14:38 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:24:27 GMT, Zhao Song wrote: > I just made more tests and found the checks will always be updated and I thought it's strange. > > After that , I found a typo at line149 in `TestInfoBotWorkItem#run` > > ``` > if ((current.status() != check.status()) || > (!current.summary().equals(check.summary())) || > (!current.title().equals(check.summary()))) { > ``` > > It should not be `!current.title().equals(check.summary()` Good catch, fixing that. ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Tue Nov 15 22:20:08 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 22:20:08 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v5] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 19:06:22 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Used UncheckedRestException > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 57: > >> 55: var census = Census.parse(repoFolder); >> 56: var namespace = namespace(census, repository.namespace()); >> 57: return Optional.of(new LimitedCensusInstance(census, configuration, namespace)); > > No need to return `Optional` here anymore as we throw exception when the configuration is missing. Exactly! I will remove it. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 15 22:21:24 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:21:24 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Fri, 4 Nov 2022 22:05:17 GMT, Zhao Song wrote: > Hi Erik, > > You mentioned > > > For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. > > And I am thinking that sometimes we will update checks in the end of `TestInfoBotWorkItem#run`, so whether a pr will be considered as 'updated' if the checks are updated. And if so, I think in the next call of `getPeriodicItems`, the bot will also schedule another `TestInfoBotWorkItem`. > > Maybe it's not a big deal. Once the checks are not updated., it will stop. You are correct, and this is actually a behavior exhibited by some other bots as well. A WorkItem modifying the PR will trigger another round by itself. In certain cases (in other bots) I believe this is intentional, as a WorkItem will return early on first modification and then let the next round do further changes. In this case, it's not really something I wanted, but it also doesn't hurt much. It could even be considered a feature that after a check update, we quickly check again a single time in case checks update quickly, then we fall off to the 2 minute recheck interval. All that said, I should probably add some comment acknowledging this behavior so that it's more obvious to someone reading the code. ------------- PR: https://git.openjdk.org/skara/pull/1411 From erikj at openjdk.org Tue Nov 15 22:25:48 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:25:48 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Tue, 8 Nov 2022 10:29:45 GMT, Magnus Ihse Bursie wrote: >> bots/testinfo/src/main/java/org/openjdk/skara/bots/testinfo/TestInfoBot.java line 63: >> >>> 61: .filter(pr -> pr.sourceRepository().isPresent()) >>> 62: .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr, >>> 63: delay -> poller.retryPullRequest(pr, now.plus(delay)))) >> >> Maybe I'm getting lost here, but this feels wrong to me. The `now` is computed as the now of the call to `getPeriodicItems()`, but it is used in the lambda for the `retry` operation of `TestInfoBotWorkItem`. But that retry should happen `delay` time after it is evaluated, right? >> >> It might not have much practical impact, but it just looks odd to me, like mixing different time streams. > > To expand a bit: the `now.plus(delay)` will be evaluated in the `run` method of the work item, but then the result will be offset not from the time of `run` but from the time of the call to this method. What would happen if it, for some reason, would take more than 2 minutes between these two events, and we'd get a time in the past. Will it be retried immediately, or will it cause trouble with the poller? > > And also it feel conceptually wrong; the retry time feels like it should be specified from when the decision is made for the next check. You are right, that is odd, it really should be X minutes after it was evaluated, not after the `getPeriodicItems` call. When bots are busy, the time difference can easily be much longer than 2 minutes, and in that case, effectively ignoring the delay is not helping in reducing the load. The poller should handle past time fine though, it will basically be equivalent to a retry without a time component. ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Tue Nov 15 22:35:18 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 22:35:18 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v8] In-Reply-To: References: Message-ID: <_RmRU2Alt9oeJjI_kMW5iOIjgU3kP1VNu7mf5MULkng=.278b4906-aac5-4817-9602-877cde782c19@github.com> > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Remove Optional in return value of LimitedCensusInstance#createLimitedCensusInstance ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/eb2ba54f..ac43ad15 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=07 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=06-07 Stats: 15 lines in 6 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Tue Nov 15 22:35:28 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 15 Nov 2022 22:35:28 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v3] In-Reply-To: References: Message-ID: > The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. > > Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. > > This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. > > I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. > > The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reversed . My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Review comments ------------- Changes: - all: https://git.openjdk.org/skara/pull/1411/files - new: https://git.openjdk.org/skara/pull/1411/files/8485b360..4d3c41d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1411&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1411&range=01-02 Stats: 10 lines in 2 files changed: 7 ins; 1 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1411.diff Fetch: git fetch https://git.openjdk.org/skara pull/1411/head:pull/1411 PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Tue Nov 15 22:54:56 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 22:54:56 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v9] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Add some logs when catching MissingJCheckConfException and InvalidJCheckConfException ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/ac43ad15..80e170d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=08 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=07-08 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 15 22:57:38 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 22:57:38 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Updated CommitCommandTests#missingJcheckConf ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/80e170d3..b73b3d14 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=09 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Tue Nov 15 23:00:48 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 23:00:48 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v2] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:17:45 GMT, Erik Joelsson wrote: > > Hi Erik, > > You mentioned > > > For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. > > > > > > And I am thinking that sometimes we will update checks in the end of `TestInfoBotWorkItem#run`, so whether a pr will be considered as 'updated' if the checks are updated. And if so, I think in the next call of `getPeriodicItems`, the bot will also schedule another `TestInfoBotWorkItem`. > > Maybe it's not a big deal. Once the checks are not updated., it will stop. > > You are correct, and this is actually a behavior exhibited by some other bots as well. A WorkItem modifying the PR will trigger another round by itself. In certain cases (in other bots) I believe this is intentional, as a WorkItem will return early on first modification and then let the next round do further changes. In this case, it's not really something I wanted, but it also doesn't hurt much. It could even be considered a feature that after a check update, we quickly check again a single time in case checks update quickly, then we fall off to the 2 minute recheck interval. > > All that said, I should probably add some comment acknowledging this behavior so that it's more obvious to someone reading the code. Make sense to me! ------------- PR: https://git.openjdk.org/skara/pull/1411 From zsong at openjdk.org Tue Nov 15 23:10:10 2022 From: zsong at openjdk.org (Zhao Song) Date: Tue, 15 Nov 2022 23:10:10 GMT Subject: RFR: 1659: Fix polling and retries in testinfo bot [v3] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:35:28 GMT, Erik Joelsson wrote: >> The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. >> >> Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. >> >> This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. >> >> I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. >> >> The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reverse d. My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Review comments I think it's very good now! ------------- Marked as reviewed by zsong (Author). PR: https://git.openjdk.org/skara/pull/1411 From erikj at openjdk.org Wed Nov 16 14:53:09 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 14:53:09 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Tue, 15 Nov 2022 22:57:38 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Updated CommitCommandTests#missingJcheckConf bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 227: > 225: var seedPath = bot.seedStorage().orElse(scratchPath.resolve("seeds")); > 226: var hostedRepositoryPool = new HostedRepositoryPool(seedPath); > 227: CensusInstance census = null; I don't think you need to assign null here as all exception paths will return. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 241: > 239: addErrorComment(text, comments); > 240: } else { > 241: log.info("No .jcheck/conf found in external repo " + bot.confOverrideRepository().get().name() + ": " + e); The file isn't necessarily called `.jcheck/conf`, the name is given in `bot.confOverrideName()`. The log should be at SEVERE level and the throwable should be included. To achieve this, you need to use the `log` method. By making it SEVERE, we will get admin notifications about this. Suggestion: log.log(Level.SEVERE, "Jcheck configuration file " + bot.confOverrideName() + " not found in external repo " + bot.confOverrideRepository().get().name(), e); bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 77: > 75: conf = Optional.of(Arrays.stream(remoteRepo.fileContents(name, ref).split("\n")).toList()); > 76: } catch (NoSuchElementException ignored) { > 77: // NoSuchElementException will only work for tests I'm not sure I understand this part. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 199: > 197: var hostedRepositoryPool = new HostedRepositoryPool(seedPath); > 198: > 199: CensusInstance census = null; I don't think you need to assign null here. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 17:08:28 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 17:08:28 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 14:46:54 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated CommitCommandTests#missingJcheckConf > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 227: > >> 225: var seedPath = bot.seedStorage().orElse(scratchPath.resolve("seeds")); >> 226: var hostedRepositoryPool = new HostedRepositoryPool(seedPath); >> 227: CensusInstance census = null; > > I don't think you need to assign null here as all exception paths will return. Got it, I will change it. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 17:18:07 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 17:18:07 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 14:41:32 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated CommitCommandTests#missingJcheckConf > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 241: > >> 239: addErrorComment(text, comments); >> 240: } else { >> 241: log.info("No .jcheck/conf found in external repo " + bot.confOverrideRepository().get().name() + ": " + e); > > The file isn't necessarily called `.jcheck/conf`, the name is given in `bot.confOverrideName()`. > > The log should be at SEVERE level and the throwable should be included. To achieve this, you need to use the `log` method. By making it SEVERE, we will get admin notifications about this. > > Suggestion: > > log.log(Level.SEVERE, "Jcheck configuration file " + bot.confOverrideName() + " not found in external repo " + bot.confOverrideRepository().get().name(), e); You are right! This one looks better! ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Wed Nov 16 17:21:59 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:21:59 GMT Subject: RFR: 1594: Convert rest of bots polling PRs and Issues to use new pollers [v2] In-Reply-To: References: Message-ID: > The new PullRequestPoller has now been in use in the PullRequestBot for a while, and hopefully most of the kinks have been ironed out. I think it's time to convert the rest of the bots that poll PRs (and the CSRIssueBot that polls Issues) to use the new pollers. > > The conversion is pretty straight forward. In the case of the CSRBots, they were missing the retry callback, so I added that functionality in line with other bots. > > The new factory tests needed to be modified slightly, as the PullRequestPoller calls to the Forge/Host object of a repository during initialization, so we need a TestHost instance there instead of `null`. > > I deliberately left out two bots here, the JEPBot and the TestInfoBot. The TestInfoBot is handled separately already in #1411. For the JEPBot, I think it needs a general overhaul. In the end it should function more or less the same as the CSRBot, but I'm still not sure that the CSRBot is where I want it to be. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Added more comments describing limitations with the poller ------------- Changes: - all: https://git.openjdk.org/skara/pull/1412/files - new: https://git.openjdk.org/skara/pull/1412/files/ead5f3ce..db231a8a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1412&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1412&range=00-01 Stats: 18 lines in 1 file changed: 10 ins; 0 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1412.diff Fetch: git fetch https://git.openjdk.org/skara pull/1412/head:pull/1412 PR: https://git.openjdk.org/skara/pull/1412 From erikj at openjdk.org Wed Nov 16 17:22:00 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:22:00 GMT Subject: Integrated: 1594: Convert rest of bots polling PRs and Issues to use new pollers In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 17:19:52 GMT, Erik Joelsson wrote: > The new PullRequestPoller has now been in use in the PullRequestBot for a while, and hopefully most of the kinks have been ironed out. I think it's time to convert the rest of the bots that poll PRs (and the CSRIssueBot that polls Issues) to use the new pollers. > > The conversion is pretty straight forward. In the case of the CSRBots, they were missing the retry callback, so I added that functionality in line with other bots. > > The new factory tests needed to be modified slightly, as the PullRequestPoller calls to the Forge/Host object of a repository during initialization, so we need a TestHost instance there instead of `null`. > > I deliberately left out two bots here, the JEPBot and the TestInfoBot. The TestInfoBot is handled separately already in #1411. For the JEPBot, I think it needs a general overhaul. In the end it should function more or less the same as the CSRBot, but I'm still not sure that the CSRBot is where I want it to be. This pull request has now been integrated. Changeset: e127ae4e Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/e127ae4e418b5defefb53803e72de075a71a65c8 Stats: 204 lines in 10 files changed: 51 ins; 104 del; 49 mod 1594: Convert rest of bots polling PRs and Issues to use new pollers Reviewed-by: ehelin, ihse ------------- PR: https://git.openjdk.org/skara/pull/1412 From zsong at openjdk.org Wed Nov 16 17:22:45 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 17:22:45 GMT Subject: Integrated: 1670: Make body handling consistent in all Issue implementations In-Reply-To: References: Message-ID: On Wed, 9 Nov 2022 19:06:40 GMT, Zhao Song wrote: > When fixing [SKARA-1658](https://bugs.openjdk.org/browse/SKARA-1658), I found the `TestIssue#body` didn't mimic `GitHubPullRequest#body` and` GitLabMergeRequest#body` properly. So this will block SKARA-1658. > > The `body()` method in `TestIssue` always returns the latest body from the 'remote' instead of the cache. So it behaves different from GitHubPullRequest and GitLabMergeRequest. > > In this patch, `TestIssue#body` will return the cached body like `GitHubPullRequest#body` and `GitLabMergeRequest#body`. Also updated related tests. This pull request has now been integrated. Changeset: 371912f1 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/371912f135016d60b145051bb04769424431df55 Stats: 125 lines in 9 files changed: 0 ins; 0 del; 125 mod 1670: Make body handling consistent in all Issue implementations Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1417 From erikj at openjdk.org Wed Nov 16 17:24:25 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:24:25 GMT Subject: Integrated: 1538: Allow regex patterns in fixversions and altfixversions in the notifier In-Reply-To: References: Message-ID: On Wed, 2 Nov 2022 22:44:07 GMT, Erik Joelsson wrote: > This patch adds support for regex patterns when specifying fixVersions and altFixVersions in the IssueNotifier. For fixVersions, the branch name can now be a regex pattern and for the altFixVersions, both the branch name as well as the version strings in the array can all be regex patterns. Having this flexibility will enable us to construct much more static configurations for certain repositories, that don't need manual updating each time we fork or branch a new release. This pull request has now been integrated. Changeset: 9644bf4d Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/9644bf4dcf5c57f521e609a9fb9c77f073b8ce42 Stats: 153 lines in 6 files changed: 113 ins; 8 del; 32 mod 1538: Allow regex patterns in fixversions and altfixversions in the notifier Reviewed-by: ihse ------------- PR: https://git.openjdk.org/skara/pull/1414 From erikj at openjdk.org Wed Nov 16 17:26:16 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:26:16 GMT Subject: Integrated: 1660: Add confname field to slack log config In-Reply-To: References: Message-ID: <6MAIGA2hbYun-Yf9EIqfCpY5N6dj6pMgdz2pJEY71-A=.fc58774d-c9d1-470c-b1d1-d6c0ce908c20@github.com> On Wed, 2 Nov 2022 20:40:04 GMT, Erik Joelsson wrote: > The Slack log handler currently takes a "username" value as input which if set is sent to Slack as the user name of the message. With modern webhooks, it unfortunately seems that we have lost the feature of overriding the user name of a message. Our current configs put a descriptive string identifying the bot configuration in this field, which we can no longer see. > > I want to add a specific new configuration field to the Slack log handler for the "configname". If set, this will appear first in every Slack message. This pull request has now been integrated. Changeset: 7727f2c5 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/7727f2c5d3856207956809ee92fd6d8dd30cb5b2 Stats: 41 lines in 3 files changed: 26 ins; 0 del; 15 mod 1660: Add confname field to slack log config Reviewed-by: zsong, ehelin, ihse ------------- PR: https://git.openjdk.org/skara/pull/1413 From erikj at openjdk.org Wed Nov 16 17:26:40 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:26:40 GMT Subject: Integrated: 1659: Fix polling and retries in testinfo bot In-Reply-To: References: Message-ID: <7kWZ3bru_0AhHX1tJURfO0JSP-tfslW7TLNW56HoxRc=.dda694b9-b5fc-45d0-b06b-b8f4ed4bb4a0@github.com> On Wed, 2 Nov 2022 17:12:11 GMT, Erik Joelsson wrote: > The testinfo bot monitors "checks" in the source repository of PRs and copies over the results to the PR itself. This makes it easier for PR reviewers to see results of e.g. GitHub actions. > > Since this bot needs to react to things that aren't part of the PR, it needs some kind of periodic polling of PRs where new check updates are likely. This is currently handled by the TestInfoBotWorkItem calling back with an "expiration time" for a retry, depending on the conclusion of the current run. The idea seems to be that a new WorkItem should not be scheduled until after this expiration time. This isn't exactly how it ends up working however. The big issue here is that if no callback is made, the bot will happily schedule another WorkItem without delay in the next call to getPeriodicItems. There is also a race between the execution of getPeriodicItems and the execution of a WorkItem. If the WorkItem isn't calling back with an expiration in time for the next getPeriodicItems, then a new WorkItem will also be scheduled without delay. > > This patch attempts to solve this by using the `PullRequestPoller` for getting updated PRs. For any PR that hasn't been updated, the only way to get scheduled is if a WorkItem is calling back with a "recheckAt" time. The poller has this functionality built in already with the retry with a date feature. This will change the bot to recheck some PRs more often (every time they are touched by a user or another bot), but it will also stop rechecking certain PRs constantly. > > I'm also changing the how and when the `TestInfoBotWorkItem` calls back with a recheckAt. I'm making sure each category has a built in termination condition, to avoid ending up with an endless loop of rechecking every time interval. This is either if a PR is closed, or if checks are still running, for max of 24h since the PR was touched. > > The test fix was a perplexing problem to solve. The old test setup created "checks" on a draft PR instead of a repository, which confused me. The TestInfoBot copies checks from a repository to a PR so that is what we are supposed to test. The reason for this was that `TestHostedRepository` didn't have support for having checks itself, instead the `checks` method just returned all checks from all PRs associated with the TestHost. As far as I can tell, this was just an unnecessary simplification of the test classes that made implementing a test for the `TestInfoBot` more complicated than necessary. To make things even weirder, by having `TestHostedRepository::checks` return all checks from all PRs, depending on which order the "draft" PR and the real PR were processed by TestInfoBot, they would get each others checks copied repeatedly. The old test happened to "work" because the right PR was processed first, but with my new implementation, the processing order happened to be reversed . My fix was to add a checks field on `TestHostedRepository` and put the checks there in the test setups instead. This pull request has now been integrated. Changeset: efd3017a Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/efd3017a7c743c64c483fd428610ba958e409867 Stats: 120 lines in 5 files changed: 61 ins; 26 del; 33 mod 1659: Fix polling and retries in testinfo bot Reviewed-by: ehelin, ihse, zsong ------------- PR: https://git.openjdk.org/skara/pull/1411 From erikj at openjdk.org Wed Nov 16 17:26:46 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 17:26:46 GMT Subject: Integrated: 1608: Handle shenandoah tags in IssueNotifier In-Reply-To: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> References: <8XWuyJQINokTIBpgoC6u0Ps_I0Mfim0O7fcjA-Uceds=.a8c99937-16d3-47da-86a5-05c1d6ac9d9d@github.com> Message-ID: On Mon, 31 Oct 2022 22:03:19 GMT, Erik Joelsson wrote: > This patch aims to add support for notifying JBS when tags are added in the shenandoah-jdk8u repository. This repository is special because it's a jdk8u 'project' repo that is never going to be merged upstream. Instead it's a downstream repo that produces its own releases. Because of this it has its own fixVersion configured in .jcheck/conf and its own tag format, to keep them apart from the main JDK jdk8u tags. > > The logic for matching fixVersions and tags is already a bit convoluted due to conventions that have been added over time. This repo will now add another matching rule. A typical fixVersion would be `shenandoah8u332` and a corresponding tag `shenandoah8u332-b01`. This is actually a pretty neat pattern to match for as the tag prefix is exactly the fixVersion, which is why I agreed to implement support for this. The complicating factors are that for mainline OpenJDK jdk8u we have fixVersion `openjdk8u332` and tag `jdk8u332-b01` (and for Oracle jdk8u the fixVersion is `8u332` but with the same tag format). This special handling of a 'jdk' prefix for a tag, and ignoring any prefix in the fixVersion is what complicates things. > > So currently we ignore any prefix before the main version number in both a tag and fixVersion when matching them. For shenandoah-jdk8u we want to exactly match this prefix. To handle this, I've added a new configuration option for the notifier: > > "issue": { // existing config element > "tag": { // existing config element > "matchprefix": true // new > } > } > > The default value for this option is `false` to reflect the current behavior. When set true, a fixVersion and tag version must match exactly. Note though that the special handling of the tag prefix 'jdk' will still be at play due to the way OpenJDKTag currently parses a JdkVersion from a tag, and I don't dare changing it. This means that if this option is set, then a fixVersion `8u332` will match tags `jdk8u332-b01` and `8u332-b01`, but a fixVersion `jdk8u332` would not match the tag `jdk8u332-b01`. We don't currently use the 'jdk' prefix in any fixVersions in JBS, so this should be fine. I just want to make it clear. This pull request has now been integrated. Changeset: 803be3fa Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/803be3fa1301ec01bbd2548fe204b3379596c677 Stats: 149 lines in 6 files changed: 134 ins; 0 del; 15 mod 1608: Handle shenandoah tags in IssueNotifier Reviewed-by: ehelin, ihse ------------- PR: https://git.openjdk.org/skara/pull/1406 From zsong at openjdk.org Wed Nov 16 17:32:06 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 17:32:06 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v11] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: changed log in CheckWorkItem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/b73b3d14..ff742e5d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=10 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=09-10 Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 17:32:07 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 17:32:07 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 14:49:46 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated CommitCommandTests#missingJcheckConf > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 77: > >> 75: conf = Optional.of(Arrays.stream(remoteRepo.fileContents(name, ref).split("\n")).toList()); >> 76: } catch (NoSuchElementException ignored) { >> 77: // NoSuchElementException will only work for tests > > I'm not sure I understand this part. In real circumstance, if jcheck configuration file is missing, we will get `UncheckedRestException` with status code 404 from GitHub or GitLab. However, if the jcheck configuration file is missing in local environment, we won't get `UncheckedRestException` , instead, we will only get `NoSuchElementException`. If we don't catch this exception here, the test will not be able to continue. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 18:00:48 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 18:00:48 GMT Subject: RFR: 1658: Minimize race window when updating PR body [v3] In-Reply-To: References: Message-ID: > Currently, when the pr bot tries to update the PR body, users are also likely to update the PR body at the same time. Therefore, users' updates are likely to be overwritten by bot. > > This is a race between the bot and user and the race window is a little big right now. > > To reduce the race window, in this patch, when PR bot is trying to update PR body, it will check whether the PR body has been modified by user. And if the PR bot has been modified, PR bot would not overwrite it. Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into SKARA-1658 - Added an automatic test for latestBody - SKARA-1658 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1416/files - new: https://git.openjdk.org/skara/pull/1416/files/d2194a68..8536fe98 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1416&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1416&range=01-02 Stats: 796 lines in 34 files changed: 385 ins; 142 del; 269 mod Patch: https://git.openjdk.org/skara/pull/1416.diff Fetch: git fetch https://git.openjdk.org/skara pull/1416/head:pull/1416 PR: https://git.openjdk.org/skara/pull/1416 From erikj at openjdk.org Wed Nov 16 18:13:24 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 18:13:24 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 17:25:51 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LimitedCensusInstance.java line 77: >> >>> 75: conf = Optional.of(Arrays.stream(remoteRepo.fileContents(name, ref).split("\n")).toList()); >>> 76: } catch (NoSuchElementException ignored) { >>> 77: // NoSuchElementException will only work for tests >> >> I'm not sure I understand this part. > > In real circumstance, if jcheck configuration file is missing, we will get `UncheckedRestException` with status code 404 from GitHub or GitLab. However, if the jcheck configuration file is missing in local environment, we won't get `UncheckedRestException` , instead, we will only get `NoSuchElementException`. If we don't catch this exception here, the test will not be able to continue. Can we change `TestHostedRepository` to behave more like other remote repo implementations in this regard? It could throw UncheckedRestException with 404 if the file doesn't exist. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 19:10:20 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 19:10:20 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v12] In-Reply-To: References: Message-ID: > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Make TestHostedRepository#fileContents behave more like remote repos ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/ff742e5d..9bd5e7f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=11 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=10-11 Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 19:10:21 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 19:10:21 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v10] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 18:09:48 GMT, Erik Joelsson wrote: >> In real circumstance, if jcheck configuration file is missing, we will get `UncheckedRestException` with status code 404 from GitHub or GitLab. However, if the jcheck configuration file is missing in local environment, we won't get `UncheckedRestException` , instead, we will only get `NoSuchElementException`. If we don't catch this exception here, the test will not be able to continue. > > Can we change `TestHostedRepository` to behave more like other remote repo implementations in this regard? It could throw UncheckedRestException with 404 if the file doesn't exist. Yes, it's a good idea! ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 19:38:05 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 19:38:05 GMT Subject: RFR: 1673: CSR bot should be able to handle a withdrawn CSR properly [v2] In-Reply-To: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> References: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> Message-ID: > A user reported that skara bot keeps changing the description in his MR. > > After investigation, we found a bug related with CSR bot. > > The user linked a CSR issue with the main issue, and after that, he found CSR unneeded and withdrawn the CSR issue. > > However, our logic about handling withdrawn CSR issue has some problem. > > In PullRequestWorkItem#run, the bot would add updateMarker() to the PR body regardless of the state of CSR issue. And if a PR body contains the updateMarker, it will be updated periodically until the body contains a CSR progress. However, since our CSR issue is withdrawn, the CSR label would not be added to the pr and CSR progress would not be added to the PR body. So it will be an endless loop. > > In summary, the bug would happen in such a case, the user withdraw the csr issue before the csr issue bot first time run. > > In this patch, before the CSR Issue bot is trying to add the updateMarker, it will check the resolution of the CSR Issue first, if the CSR Issue is already withdrawn, then updateMarker would not be added to the PR body. And PR bot would work normally. Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits: - Merge branch 'master' into SKARA-1673 # Conflicts: # bots/csr/src/main/java/org/openjdk/skara/bots/csr/PullRequestWorkItem.java - SKARA-1673 ------------- Changes: https://git.openjdk.org/skara/pull/1418/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1418&range=01 Stats: 66 lines in 2 files changed: 65 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1418.diff Fetch: git fetch https://git.openjdk.org/skara pull/1418/head:pull/1418 PR: https://git.openjdk.org/skara/pull/1418 From zsong at openjdk.org Wed Nov 16 20:17:11 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 20:17:11 GMT Subject: Integrated: 1673: CSR bot should be able to handle a withdrawn CSR properly In-Reply-To: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> References: <2QRj0HQZFxLK1UycXCN-9prk4EUJO-ZQ6oEuSXaIVcU=.900f8843-a19a-4cdc-8c29-4fe5814d4b5f@github.com> Message-ID: On Thu, 10 Nov 2022 19:20:41 GMT, Zhao Song wrote: > A user reported that skara bot keeps changing the description in his MR. > > After investigation, we found a bug related with CSR bot. > > The user linked a CSR issue with the main issue, and after that, he found CSR unneeded and withdrawn the CSR issue. > > However, our logic about handling withdrawn CSR issue has some problem. > > In PullRequestWorkItem#run, the bot would add updateMarker() to the PR body regardless of the state of CSR issue. And if a PR body contains the updateMarker, it will be updated periodically until the body contains a CSR progress. However, since our CSR issue is withdrawn, the CSR label would not be added to the pr and CSR progress would not be added to the PR body. So it will be an endless loop. > > In summary, the bug would happen in such a case, the user withdraw the csr issue before the csr issue bot first time run. > > In this patch, before the CSR Issue bot is trying to add the updateMarker, it will check the resolution of the CSR Issue first, if the CSR Issue is already withdrawn, then updateMarker would not be added to the PR body. And PR bot would work normally. This pull request has now been integrated. Changeset: fc863a29 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/fc863a29a7b21f04d9e133c0f7d75a47e24f2940 Stats: 66 lines in 2 files changed: 65 ins; 0 del; 1 mod 1673: CSR bot should be able to handle a withdrawn CSR properly Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1418 From erikj at openjdk.org Wed Nov 16 20:25:41 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 20:25:41 GMT Subject: RFR: 1678: Missed calling lastBatchHandled in TestInfoBot Message-ID: After spending the extra time documenting the need for calling "lastBatchHandled" on the PullRequestPoller, I still managed to forget in the TestInfoBot. ------------- Commit messages: - SKARA-1678 Changes: https://git.openjdk.org/skara/pull/1420/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1420&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1678 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1420.diff Fetch: git fetch https://git.openjdk.org/skara pull/1420/head:pull/1420 PR: https://git.openjdk.org/skara/pull/1420 From erikj at openjdk.org Wed Nov 16 20:48:37 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 20:48:37 GMT Subject: RFR: 1679: Make username and prefix optional config options for slack log handler Message-ID: In [SKARA-1660](https://bugs.openjdk.org/browse/SKARA-1660) I added the new "prefix" config option for the slack log handler. This will be used instead of the username field. The problem is that neither field was made optional in the config parser, so now we have to configure both, regardless of if we want them or not. The actual handler logic treats them as optional, but the config parser throws NPE. This patch adds null checks to avoid the NPEs. ------------- Commit messages: - Fix null check - SKARA-1679 Changes: https://git.openjdk.org/skara/pull/1421/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1421&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1679 Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1421.diff Fetch: git fetch https://git.openjdk.org/skara pull/1421/head:pull/1421 PR: https://git.openjdk.org/skara/pull/1421 From zsong at openjdk.org Wed Nov 16 20:52:39 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 20:52:39 GMT Subject: RFR: 1678: Missed calling lastBatchHandled in TestInfoBot In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:21:39 GMT, Erik Joelsson wrote: > After spending the extra time documenting the need for calling "lastBatchHandled" on the PullRequestPoller, I still managed to forget in the TestInfoBot. LGTM, just a small glitch about the comment of `PullRequestPoller#lastBatchedHandled`, you said 'After calling getUpdatedPullRequests()', but the actual method name is `UpdatedPullRequests()`. ------------- PR: https://git.openjdk.org/skara/pull/1420 From erikj at openjdk.org Wed Nov 16 21:02:17 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 21:02:17 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v12] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 19:10:20 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Make TestHostedRepository#fileContents behave more like remote repos bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 236: > 234: } catch (MissingJCheckConfException e) { > 235: if (bot.confOverrideRepository().isEmpty()) { > 236: log.info("No .jcheck/conf found in repo " + bot.repo().name() + ": " + e); I think we want SEVERE log messages with the exception included for all the cases here. ------------- PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Wed Nov 16 21:06:15 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 21:06:15 GMT Subject: RFR: 1678: Missed calling lastBatchHandled in TestInfoBot [v2] In-Reply-To: References: Message-ID: > After spending the extra time documenting the need for calling "lastBatchHandled" on the PullRequestPoller, I still managed to forget in the TestInfoBot. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fixed comments ------------- Changes: - all: https://git.openjdk.org/skara/pull/1420/files - new: https://git.openjdk.org/skara/pull/1420/files/d50880b3..dc736bd4 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1420&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1420&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1420.diff Fetch: git fetch https://git.openjdk.org/skara pull/1420/head:pull/1420 PR: https://git.openjdk.org/skara/pull/1420 From zsong at openjdk.org Wed Nov 16 21:13:25 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 21:13:25 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v12] In-Reply-To: References: Message-ID: <6eFQb8sGMg84Ye2PuNV1DXbvp5xs7_sKixc9DdoZgD8=.d8af3dfa-38ef-42c8-8f81-39c4fc6f2e45@github.com> On Wed, 16 Nov 2022 20:59:08 GMT, Erik Joelsson wrote: > I think we want SEVERE log messages with the exception included for all the cases here. I thought if the jcheck configuration file is not overridden, we just need to tell the user to contact the repo owner and only the repo owner could fix this problem, admin could not. For the case that jcheck configuration file is overridden, we need to notify the admin because admin could fix this problem. But it is also reasonable to notify admin in the first case, maybe the admin could contact the repo owner too. ------------- PR: https://git.openjdk.org/skara/pull/1407 From kcr at openjdk.org Wed Nov 16 21:14:59 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 21:14:59 GMT Subject: RFR: 1679: Make username and prefix optional config options for slack log handler In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:43:35 GMT, Erik Joelsson wrote: > In [SKARA-1660](https://bugs.openjdk.org/browse/SKARA-1660) I added the new "prefix" config option for the slack log handler. This will be used instead of the username field. The problem is that neither field was made optional in the config parser, so now we have to configure both, regardless of if we want them or not. The actual handler logic treats them as optional, but the config parser throws NPE. > > This patch adds null checks to avoid the NPEs. Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1421 From kcr at openjdk.org Wed Nov 16 21:17:02 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Wed, 16 Nov 2022 21:17:02 GMT Subject: RFR: 1678: Missed calling lastBatchHandled in TestInfoBot [v2] In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 21:06:15 GMT, Erik Joelsson wrote: >> After spending the extra time documenting the need for calling "lastBatchHandled" on the PullRequestPoller, I still managed to forget in the TestInfoBot. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comments Marked as reviewed by kcr (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1420 From erikj at openjdk.org Wed Nov 16 21:17:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 21:17:02 GMT Subject: Integrated: 1678: Missed calling lastBatchHandled in TestInfoBot In-Reply-To: References: Message-ID: On Wed, 16 Nov 2022 20:21:39 GMT, Erik Joelsson wrote: > After spending the extra time documenting the need for calling "lastBatchHandled" on the PullRequestPoller, I still managed to forget in the TestInfoBot. This pull request has now been integrated. Changeset: 2c880305 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/2c880305d594cb71b2fbc509531fcb5e906547d8 Stats: 7 lines in 3 files changed: 2 ins; 0 del; 5 mod 1678: Missed calling lastBatchHandled in TestInfoBot Reviewed-by: kcr ------------- PR: https://git.openjdk.org/skara/pull/1420 From erikj at openjdk.org Wed Nov 16 21:17:39 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 21:17:39 GMT Subject: Integrated: 1679: Make username and prefix optional config options for slack log handler In-Reply-To: References: Message-ID: <9wGN3exgyWIUhvn7NHensRuuyiUyoERQOykQrN8kNSc=.28337c5e-2abd-439b-8fb7-317f55288a03@github.com> On Wed, 16 Nov 2022 20:43:35 GMT, Erik Joelsson wrote: > In [SKARA-1660](https://bugs.openjdk.org/browse/SKARA-1660) I added the new "prefix" config option for the slack log handler. This will be used instead of the username field. The problem is that neither field was made optional in the config parser, so now we have to configure both, regardless of if we want them or not. The actual handler logic treats them as optional, but the config parser throws NPE. > > This patch adds null checks to avoid the NPEs. This pull request has now been integrated. Changeset: 7e0a1581 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/7e0a15810a8679a4d8fe7e9f9959dfe3a7d949be Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 mod 1679: Make username and prefix optional config options for slack log handler Reviewed-by: kcr ------------- PR: https://git.openjdk.org/skara/pull/1421 From erikj at openjdk.org Wed Nov 16 21:40:34 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 21:40:34 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v12] In-Reply-To: <6eFQb8sGMg84Ye2PuNV1DXbvp5xs7_sKixc9DdoZgD8=.d8af3dfa-38ef-42c8-8f81-39c4fc6f2e45@github.com> References: <6eFQb8sGMg84Ye2PuNV1DXbvp5xs7_sKixc9DdoZgD8=.d8af3dfa-38ef-42c8-8f81-39c4fc6f2e45@github.com> Message-ID: On Wed, 16 Nov 2022 21:09:56 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 236: >> >>> 234: } catch (MissingJCheckConfException e) { >>> 235: if (bot.confOverrideRepository().isEmpty()) { >>> 236: log.info("No .jcheck/conf found in repo " + bot.repo().name() + ": " + e); >> >> I think we want SEVERE log messages with the exception included for all the cases here. > >> I think we want SEVERE log messages with the exception included for all the cases here. > > I thought if the jcheck configuration file is not overridden, we just need to tell the user to contact the repo owner and only the repo owner could fix this problem, admin could not. > > For the case that jcheck configuration file is overridden, we need to notify the admin because admin could fix this problem. > > But it is also reasonable to notify admin in the first case, maybe the admin could contact the repo owner too. Your reasoning is valid, but I think it's better that we get notified as admins too. We need to help repo owners with getting things right, also logging the exception gives us access to the stack trace which can help diagnose further. ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 21:52:20 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 21:52:20 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v12] In-Reply-To: References: <6eFQb8sGMg84Ye2PuNV1DXbvp5xs7_sKixc9DdoZgD8=.d8af3dfa-38ef-42c8-8f81-39c4fc6f2e45@github.com> Message-ID: On Wed, 16 Nov 2022 21:37:22 GMT, Erik Joelsson wrote: > Your reasoning is valid, but I think it's better that we get notified as admins too. We need to help repo owners with getting things right, also logging the exception gives us access to the stack trace which can help diagnose further. Yes, I will change the log! ------------- PR: https://git.openjdk.org/skara/pull/1407 From zsong at openjdk.org Wed Nov 16 22:17:12 2022 From: zsong at openjdk.org (Zhao Song) Date: Wed, 16 Nov 2022 22:17:12 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v13] In-Reply-To: References: Message-ID: <5neQ5uyB7-yd4jKSbyAgb95WfOuK3-2fHw1XMAUi4Ns=.b63546c1-6b1e-417e-bd32-96fec8967bc9@github.com> > SKARA-1393 describes a problem related with `.jcheck/conf` missing. > > In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update log ------------- Changes: - all: https://git.openjdk.org/skara/pull/1407/files - new: https://git.openjdk.org/skara/pull/1407/files/9bd5e7f2..27d93f2f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=12 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1407&range=11-12 Stats: 37 lines in 2 files changed: 23 ins; 0 del; 14 mod Patch: https://git.openjdk.org/skara/pull/1407.diff Fetch: git fetch https://git.openjdk.org/skara pull/1407/head:pull/1407 PR: https://git.openjdk.org/skara/pull/1407 From erikj at openjdk.org Wed Nov 16 22:33:36 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 16 Nov 2022 22:33:36 GMT Subject: RFR: 1393: PR bot fails on missing .jcheck/conf [v13] In-Reply-To: <5neQ5uyB7-yd4jKSbyAgb95WfOuK3-2fHw1XMAUi4Ns=.b63546c1-6b1e-417e-bd32-96fec8967bc9@github.com> References: <5neQ5uyB7-yd4jKSbyAgb95WfOuK3-2fHw1XMAUi4Ns=.b63546c1-6b1e-417e-bd32-96fec8967bc9@github.com> Message-ID: On Wed, 16 Nov 2022 22:17:12 GMT, Zhao Song wrote: >> SKARA-1393 describes a problem related with `.jcheck/conf` missing. >> >> In this patch, when the problem happens, the author of this pull request will get instructions about how to solve this problem. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update log Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1407 From duke at openjdk.org Thu Nov 17 05:31:58 2022 From: duke at openjdk.org (duke) Date: Thu, 17 Nov 2022 05:31:58 GMT Subject: Withdrawn: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects In-Reply-To: References: Message-ID: On Wed, 31 Aug 2022 10:46:32 GMT, Guoxiong Li wrote: > Hi all, > > This patch implements the feature we had discussed at the mail list and the issue SKARA-1199 [1], included mainly the proposal I submitted [2] and the suggestions and ideas other developers provided. > > The dev flow has been stated at my previous proposal [2]. Here, I mainly state the code implementation which are changed and newly added in this patch. > > ### The change in PullRequestBot > - The config about approval and update change is added to the `PullRequestBot`. See below for the concrete config format. Please see the classes `PullRequestBotFactory`, `PullRequestBotBuilder` and `PullRequestBot` for the code. > > > "repositories" : { > "repo-name" : { > // other fileds, ignored > "approval" : [ > { > "branch" : "branch-pattern", > "request-label" : "label-name1", > "approval-label" : "label-name2", > "disapproval-label" : "label-name3", > "maintainers" : ["user1", "user2"] > }, > // other branch pattern and its information > ] > }, > // other repo and its information > } > > > - A suggestion comment would be added to the update change pull request. Please see the method `CheckRun#addUpdateChangeSuggestionComment`. > - Labels of the pull request and the issues would be updated according to the main issue state. Please see the method `CheckRun#updateLabelsForUpdatesChange` > - Two commands `approval` and `request-approval` are added. Please see the classes `ApprovalCommand` and `RequestApprovalCommand`. The field `CommandExtractor#commandPattern` is also adjusted to identify the bar `-` in `request-approval`. > - Some methods in class `CheckRun` are moved to class `PullRequestWorkItem` to let them reused in `PullRequestCommandWorkItem` and `CheckWorkItem`. > - The `PullRequestWorkItem workItem` parameter is added to the method `CommandHandler#handle` so that the commands can use the work item and use the newly added and moved methods. And the `handle` method of the `CSRCommand` and `JEPCommand` need to adjust the parameter, too. > - The field `CheckWorkItem#metadataComments` need to be adjusted to identify the tag `