From gli at openjdk.org Thu Sep 1 05:34:06 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 1 Sep 2022 05:34:06 GMT Subject: RFR: 1568: Dependency PR Resolution Detection Does Not Check Means of Resolution Message-ID: Hi all, Currently, the closed but not integrated PR causes the dependent PRs to be retargeted. It is not right. This patch fixes it and changes the test case. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1568 Changes: https://git.openjdk.org/skara/pull/1365/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1365&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1568 Stats: 33 lines in 2 files changed: 15 ins; 1 del; 17 mod Patch: https://git.openjdk.org/skara/pull/1365.diff Fetch: git fetch https://git.openjdk.org/skara pull/1365/head:pull/1365 PR: https://git.openjdk.org/skara/pull/1365 From gli at openjdk.org Thu Sep 1 07:33:57 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 1 Sep 2022 07:33:57 GMT Subject: RFR: 1569: The method 'IssueWorkItem#run' may get the wrong pull request Message-ID: Hi all, This patch gets all the pull requests form the issue and filters the open pull requests to avoid getting the wrong pull request. But I can't provide a test case to steadily reproduce the bug. Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1569 Changes: https://git.openjdk.org/skara/pull/1366/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1366&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1569 Stats: 5 lines in 1 file changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1366.diff Fetch: git fetch https://git.openjdk.org/skara pull/1366/head:pull/1366 PR: https://git.openjdk.org/skara/pull/1366 From gli at openjdk.org Thu Sep 1 08:29:48 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 1 Sep 2022 08:29:48 GMT Subject: RFR: 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: > Although two pollers are extracted from the csr module to re-used. But the csr and jep module are not changed because it would improved the complexity of this patch. The csr and jep module can be adjusted in the follow-up patches. And the issue SKARA-1554 [3] about the jep module has been created. Filed https://bugs.openjdk.org/browse/SKARA-1576 to follow up. > The API of the HostedRepository is not changed. But I add some TOOD comments to the class HostedRepository and the method UpdatedPullRequestPoller#getUpdatedPullRequests to improve the API of the HostedRepository in the follow-up patch. Filed https://bugs.openjdk.org/browse/SKARA-1575 to follow up. ------------- PR: https://git.openjdk.org/skara/pull/1364 From gli at openjdk.org Thu Sep 1 13:00:34 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 1 Sep 2022 13:00:34 GMT Subject: RFR: 1575: Adjust the pull request APIs in HostedRepository Message-ID: Hi all, This patch mainly has the following changes in `HostedRepository` and its sub-classes. And the usages of the changed methods are also changed. 1. Change the name of the `pullRequests(ZonedDateTime updatedAfter)` to `pullRequestsAfter` so that it is consistent as the `openPullRequestsAfter`. 2. Add the new api `openPullRequests` to get all the open pull requests. 3. Change the implementation of the method `pullRequests()` to get all the pull requests (included open and closed) Thanks for taking the time to review. Best Regards, -- Guoxiong ------------- Commit messages: - SKARA-1575 Changes: https://git.openjdk.org/skara/pull/1367/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1367&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1575 Stats: 99 lines in 22 files changed: 39 ins; 0 del; 60 mod Patch: https://git.openjdk.org/skara/pull/1367.diff Fetch: git fetch https://git.openjdk.org/skara pull/1367/head:pull/1367 PR: https://git.openjdk.org/skara/pull/1367 From erikj at openjdk.org Thu Sep 1 18:18:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 18:18:44 GMT Subject: RFR: 1578: Skara can't parse shenandoah jdk8u versions like 'shenandoah8u332' Message-ID: When configuring the notify bot for SKARA-1574, I discovered that Skara fails to parse the fixversion of the shenandoah-jdk8u repo. This patch fixes that. It seems to me that there is little point in keeping a complete list of valid prefixes in the Skara source code, so instead of adding another explicit string like 'openjdk' or 'openjfx', I made the regexp accept any string of lower case letters as prefix for XuY type version strings. ------------- Commit messages: - Fix comment - Fix comment - SKARA-1578 Changes: https://git.openjdk.org/skara/pull/1368/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1368&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1578 Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1368.diff Fetch: git fetch https://git.openjdk.org/skara pull/1368/head:pull/1368 PR: https://git.openjdk.org/skara/pull/1368 From tbell at openjdk.org Thu Sep 1 19:11:52 2022 From: tbell at openjdk.org (Tim Bell) Date: Thu, 1 Sep 2022 19:11:52 GMT Subject: RFR: 1578: Skara can't parse shenandoah jdk8u versions like 'shenandoah8u332' In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:13:57 GMT, Erik Joelsson wrote: > When configuring the notify bot for SKARA-1574, I discovered that Skara fails to parse the fixversion of the shenandoah-jdk8u repo. This patch fixes that. > > It seems to me that there is little point in keeping a complete list of valid prefixes in the Skara source code, so instead of adding another explicit string like 'openjdk' or 'openjfx', I made the regexp accept any string of lower case letters as prefix for XuY type version strings. Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). Marked as reviewed by tbell (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1368 From erikj at openjdk.org Thu Sep 1 20:28:59 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 20:28:59 GMT Subject: Integrated: 1578: Skara can't parse shenandoah jdk8u versions like 'shenandoah8u332' In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 18:13:57 GMT, Erik Joelsson wrote: > When configuring the notify bot for SKARA-1574, I discovered that Skara fails to parse the fixversion of the shenandoah-jdk8u repo. This patch fixes that. > > It seems to me that there is little point in keeping a complete list of valid prefixes in the Skara source code, so instead of adding another explicit string like 'openjdk' or 'openjfx', I made the regexp accept any string of lower case letters as prefix for XuY type version strings. This pull request has now been integrated. Changeset: 8337aff1 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/8337aff1b9f22a1f0c8ac9ecae8564c643f2871b Stats: 5 lines in 2 files changed: 2 ins; 0 del; 3 mod 1578: Skara can't parse shenandoah jdk8u versions like 'shenandoah8u332' Reviewed-by: tbell ------------- PR: https://git.openjdk.org/skara/pull/1368 From erikj at openjdk.org Thu Sep 1 22:29:25 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 Sep 2022 22:29:25 GMT Subject: RFR: 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 `"; > 69: private static final String APPROVAL_PROGRESS = "Change must be properly approved by the maintainers"; I would suggest a different wording: "All issues must be approved by a maintainer", possibly with the word 'approved' being a link to https://openjdk.org/projects/jdk-updates/approval.html. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 197: > 195: var issue = issueOpt.flatMap(value -> issueProject() != null ? issueProject().issue(value.shortId()) : Optional.empty()); > 196: if (issue.isPresent()) { > 197: if (issue.get().labelNames().contains(workItem.approvalLabelName())) { We need to check all the issues to make this call. That should only be done once for the CheckRun, and that result needs to be used both for updating the label as well as the progress. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 204: > 202: } > 203: } else { > 204: // The PR doesn't contain a right issue. Suggestion: // The PR doesn't have an issue. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 959: > 957: var existing = findComment(comments, updateChangeSuggestionMarker); > 958: if (existing.isPresent()) { > 959: // Only add the comment once per PR Maybe consider updating it if it's different from the existing one. If we were to change the message in the future, it would be nice if active PRs were updated. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 982: > 980: after applying it. The risk of this backport is low because the change is little and the \ > 981: issue fixed by this change also exists in other update repositories. > 982: ``` This is too detailed. The process is officially documented here: https://openjdk.org/projects/jdk-updates/approval.html. We should just link to that and add the additional information about PR commands that can support the process. Maintaining a copy of the process description in the Skara source code is not something I want to do. Something like: This pull request requires [maintainer approval](https://openjdk.org/projects/jdk-updates/approval.html). bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 986: > 984: If you don't have permission to add a comment in JBS. Please use the command `request-approval` \ > 985: to provide the related content, then the bot can help you add a comment by using the content \ > 986: you provided. Below is an example for you: Suggestion: As a convenience, or if you don't have permission to post comments in JBS, \ you may use the command `/request-approval` to supply the fix request comment \ and automatically set the correct request label. usage: `/request-approval ` bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 993: > 991: after applying it. The risk of this backport is low because the change is little and the \ > 992: issue fixed by this change also exists in other update repositories. > 993: ``` I don't think we should post an example here. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 999: > 997: And you don't need to add the fix request label manually to the issue like before, \ > 998: now the bot can help you add the label automatically when this pull request is ready \ > 999: for maintainers to approve. Suggestion: Please note that approval discussions should take place in the issue and not in the pull request. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1195: > 1193: .filter(entry -> !entry.getKey().equals(APPROVAL_PROGRESS)) > 1194: .allMatch(Map.Entry::getValue) && > 1195: integrationBlockers.isEmpty(); Could we share the common parts of these logic expressions? ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 2 13:54:37 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Sep 2022 13:54:37 GMT Subject: RFR: 1568: Dependency PR Resolution Detection Does Not Check Means of Resolution In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 05:29:35 GMT, Guoxiong Li wrote: > Hi all, > > Currently, the closed but not integrated PR causes the dependent PRs to be retargeted. It is not right. This patch fixes it and changes the test case. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong I don't think this really solves the issue. The pr branch for the closed PR is still deleted, so the dependent PR will still get retargeted, but without any notification to the user. I think we need to post a different message in the dependent PRs, explaining that the PR this PR depends on was closed without being integrated. Reading the current message, the word 'dependent' isn't used correctly. ------------- PR: https://git.openjdk.org/skara/pull/1365 From erikj at openjdk.org Fri Sep 2 13:59:32 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Sep 2022 13:59:32 GMT Subject: RFR: 1569: The method 'IssueWorkItem#run' may get the wrong pull request In-Reply-To: References: Message-ID: On Thu, 1 Sep 2022 07:30:00 GMT, Guoxiong Li wrote: > Hi all, > > This patch gets all the pull requests form the issue and filters the open pull requests to avoid getting the wrong pull request. But I can't provide a test case to steadily reproduce the bug. > > Thanks for taking the time to review. > > Best Regards, > -- Guoxiong Good catch! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.org/skara/pull/1366 From gli at openjdk.org Fri Sep 2 14:30:07 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 2 Sep 2022 14:30:07 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v2] In-Reply-To: References: Message-ID: > 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 `"; >> 69: private static final String APPROVAL_PROGRESS = "Change must be properly approved by the maintainers"; > > I would suggest a different wording: "All issues must be approved by a maintainer", possibly with the word 'approved' being a link to https://openjdk.org/projects/jdk-updates/approval.html. Fixed. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 2 22:12:42 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Sep 2022 22:12:42 GMT Subject: RFR: 1565: Only poll for updated MRs from GitLab Message-ID: This is another rather big patch, but again, with some explanation, it shouldn't be too scary. The most important part is the new `PullRequestPoller` class. This class implements a polling mechanism for PullRequests that tries to only return new or updated pull requests to a bot and guaranteeing that none are missed. The goal is to minimize unnecessary evaluations that currently take place, especially when polling Gitlab. I have added quite a few tests to verify (almost) all the functionality of the poller. For a more detailed explanation of all the challenges this poller faces, see the bug description. In order to reduce impact, I'm only making one existing bot use the new poller, the CSRPullRequestBot. I picked this one as it should have pretty low impact overall if something goes wrong. I will followup with further conversions of other bots. I'm also touching the `CSRIssueBot` to introduce the same kind of error handling with retry that the new `PullRequestPoller` implements. I hadn't realized before that this error handling was missing in the CSRBots, and to be able to implement it properly for the `CSRPullRequestBot`, I had to also add the support for the issue polling `CSRIssueBot`. There are features of the poller that aren't in use yet. I tried to look through all future users to make sure I could cover all existing usecases from the start. Most of the rest of the changes are just adding `equals` and `hashCode` to a bunch of classes that we now need to compare (to know if a PR has been updated or not). This includes the `GitHubPullrequest`, `GitLabMergeRequest` and all the JSON types. For test code this also includes the `TestPullRequest` and `TestIssue` and their related data classes. In order to test this properly, I needed to implement a way to for the `TestHostedRepository` to return copies of `TestPullRequest` instances from queries. This better simulates how new instances are always created when `PullRequest`s are queried from a remote `Forge`. The existing bot tests don't need it, but without this, it's not possible to verify the behavior of the poller. I tried a lot of different ways of implementing clone/copy (Object.clone(), copy constructor and specialized copy methods), but what I have here is what I think worked best in the end, with the least impact on existing code. ------------- Commit messages: - SKARA-1565 Changes: https://git.openjdk.org/skara/pull/1369/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1369&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1565 Stats: 1167 lines in 25 files changed: 1102 ins; 36 del; 29 mod Patch: https://git.openjdk.org/skara/pull/1369.diff Fetch: git fetch https://git.openjdk.org/skara pull/1369/head:pull/1369 PR: https://git.openjdk.org/skara/pull/1369 From erikj at openjdk.org Fri Sep 2 22:32:52 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 Sep 2022 22:32:52 GMT Subject: RFR: DRAFT: 1565: Only poll for updated MRs from GitLab In-Reply-To: References: Message-ID: On Fri, 2 Sep 2022 22:08:08 GMT, Erik Joelsson wrote: > This is another rather big patch, but again, with some explanation, it shouldn't be too scary. The most important part is the new `PullRequestPoller` class. This class implements a polling mechanism for PullRequests that tries to only return new or updated pull requests to a bot and guaranteeing that none are missed. The goal is to minimize unnecessary evaluations that currently take place, especially when polling Gitlab. I have added quite a few tests to verify (almost) all the functionality of the poller. For a more detailed explanation of all the challenges this poller faces, see the bug description. > > In order to reduce impact, I'm only making one existing bot use the new poller, the CSRPullRequestBot. I picked this one as it should have pretty low impact overall if something goes wrong. I will followup with further conversions of other bots. I'm also touching the `CSRIssueBot` to introduce the same kind of error handling with retry that the new `PullRequestPoller` implements. I hadn't realized before that this error handling was missing in the CSRBots, and to be able to implement it properly for the `CSRPullRequestBot`, I had to also add the support for the issue polling `CSRIssueBot`. > > There are features of the poller that aren't in use yet. I tried to look through all future users to make sure I could cover all existing usecases from the start. > > Most of the rest of the changes are just adding `equals` and `hashCode` to a bunch of classes that we now need to compare (to know if a PR has been updated or not). This includes the `GitHubPullrequest`, `GitLabMergeRequest` and all the JSON types. For test code this also includes the `TestPullRequest` and `TestIssue` and their related data classes. > > In order to test this properly, I needed to implement a way to for the `TestHostedRepository` to return copies of `TestPullRequest` instances from queries. This better simulates how new instances are always created when `PullRequest`s are queried from a remote `Forge`. The existing bot tests don't need it, but without this, it's not possible to verify the behavior of the poller. I tried a lot of different ways of implementing clone/copy (Object.clone(), copy constructor and specialized copy methods), but what I have here is what I think worked best in the end, with the least impact on existing code. Please disregard this for now. I discovered a testing issue with any bot using the poller that I need to address properly first. ------------- PR: https://git.openjdk.org/skara/pull/1369 From gli at openjdk.org Sat Sep 3 08:16:32 2022 From: gli at openjdk.org (Guoxiong Li) Date: Sat, 3 Sep 2022 08:16:32 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v4] In-Reply-To: References: Message-ID: <9J2vgoI01uR9UDWXLuywnmK3sRROKJ4DbqwxowVIMXU=.ee341682-767c-417c-b6ac-9cd2b8747616@github.com> > 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 ` change to `approve` ------------- PR: https://git.openjdk.org/skara/pull/1364 From lgxbslgx at gmail.com Thu Sep 22 13:32:33 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Thu, 22 Sep 2022 21:32:33 +0800 Subject: The bot doesn't add commit comment to the JMH issues In-Reply-To: <0be16c18-cdae-3607-d0ae-915d0ac9779c@oracle.com> References: <0be16c18-cdae-3607-d0ae-915d0ac9779c@oracle.com> Message-ID: Actually I can't confirm whether it is necessary. So I post this email to discuss with you. If Aleksey Shipilev, the maintainer of the JMH, confirm we need to do that, I will file the SKARA admin task for this. CC'ing Aleksey Shipilev. On Wed, Sep 21, 2022 at 8:29 PM wrote: > Please file a SKARA admin task for this. > > /Erik > On 9/21/22 00:46, Guoxiong Li wrote: > > Hi all, > > Recently, I submitted a commit to the JMH [1][2] and > found there is no commit comment (like below) in the issue [2]. > > ``` > Changeset: > Author: > Date: > URL: > ``` > > It often works well because a commit link has been added > when the bot handles the pull request integrated event. > > But many pull requests [5] in JMH haven't been integrated by using the > command `/integrate`. The authors which have the commit permission > merge the pull request by using the GitHub UI. It is because there are > only few reviewers to review the code, the authors sometimes need to > merge the pull request by themselves manually without formal review. > > In this situation, the problem occurs. Because the command `/integrate` > has not been used, the pull request integrated event is not triggered. > Then the commit link is not added and the status of the issue > is not marked as `Resolved` or `Fixed`. So the authors need to add the > comment or link about the commit to the issue and mark the issue > as `Resolved` manually. Please see [3][4] for an example. > > Considering such manual merging will happen in the future, I suggest > changing the configuration of the SKARA bot of the JMH project so that > the commit comment can be added and the issue can be solved automatically. > The related configuration may be `pronly` in the class > `IssueNotifierFactory`. > If I don't make a mistake, to meet my suggestion, the `pronly` should be > `false`. > > What do you think about it? Any ideas are appreciated. > > [1] https://github.com/openjdk/jmh/pull/78 > [2] https://bugs.openjdk.org/browse/CODETOOLS-7903319 > [3] https://github.com/openjdk/jmh/pull/75 > [4] https://bugs.openjdk.org/browse/CODETOOLS-7903234 > [5] https://github.com/openjdk/jmh/pulls?q=is%3Apr+is%3Aclosed+is%3Amerged > > Best Regards, > -- Guoxiong > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gli at openjdk.org Thu Sep 22 13:42:51 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 22 Sep 2022 13:42:51 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v7] In-Reply-To: References: Message-ID: > 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 ` change to `approve` I changed the command name `approval` to `approve` just now. ------------- PR: https://git.openjdk.org/skara/pull/1364 From gli at openjdk.org Thu Sep 22 13:42:55 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 22 Sep 2022 13:42:55 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v7] In-Reply-To: References: Message-ID: <3nK-FMuOsF8sa8wxRNWuGHIXeGmQO1LSV0k4XNpFT_c=.bec99ce7-cb37-476c-b0b7-3be76bc5d690@github.com> On Wed, 21 Sep 2022 10:21:10 GMT, Magnus Ihse Bursie wrote: >> The pull request would be automatically closed by the bot if the maintainer had rejected the pull request before. And at second thought, the maintainer approves the pull request, we need to open it to confirm the CheckWorkItem can be re-run in this pull request. >> >> But now I find a bug about opening/closing the pull request automatically. When the maintainer has rejected the pull request, the pull request was closed by the bot. But if the author of the pull request re-open the pull request by using the `open` command (the author may want to change the pull request), the bot will re-close the pull request again because the disapproval label still exists. This bug seems not easy to solve now, so I suggest that the bot doesn't set the pull request state automatically. What is your opinion. > > Let the user close the PR themselves. I removed the code about changing the PR status. Now the bot doesn't open or close the PR automatically. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Thu Sep 22 16:48:00 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 16:48:00 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 13:39:19 GMT, Guoxiong Li wrote: >> I agree the command name `approve` is better. Do the related class names and method names need to be adjusted? Or only need to revise the command name and its help info? >> >> >> Map.entry("approval", new ApprovalCommand()) --> change to `approve` > > I changed the command name `approval` to `approve` just now. I think the name of the command class should match the command, so please change to `ApproveCommand` ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Thu Sep 22 16:48:00 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 16:48:00 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 09:07:11 GMT, Guoxiong Li wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/ApprovalCommand.java line 129: >> >>> 127: }); >>> 128: } >>> 129: if (pr.labelNames().contains("approval")) { >> >> Also, the label should probably be `approved`, since we use adjectives (like `ready`) for labels. > > I read the [labels](https://github.com/openjdk/jdk/labels) of the JDK project. Almost all of them are nouns and only few labels are adjectives. And the `approved` may be misunderstood as `the pull request has been approved`. So I use the label `approval`. I agree, the `approval` label is meant to signal that this PR is waiting on/needs approval. ------------- PR: https://git.openjdk.org/skara/pull/1364 From gli at openjdk.org Thu Sep 22 16:52:22 2022 From: gli at openjdk.org (Guoxiong Li) Date: Thu, 22 Sep 2022 16:52:22 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:45:39 GMT, Erik Joelsson wrote: >> I changed the command name `approval` to `approve` just now. > > I think the name of the command class should match the command, so please change to `ApproveCommand` This name has been changed. So as its test class. Please see the newest code. If there are other names that need to be adjusted, please help to point out. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Thu Sep 22 16:59:22 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 16:59:22 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: <7qyFY7avQA2Z9wnJJHXU6kJPNpRqS5UrcoqR3XUVzDU=.0637fca3-3e04-46a6-a4f7-bfb0345bbe1a@github.com> On Thu, 22 Sep 2022 16:48:54 GMT, Guoxiong Li wrote: >> I think the name of the command class should match the command, so please change to `ApproveCommand` > > This name has been changed. So as its test class. Please see the newest code. > If there are other names that need to be adjusted, please help to point out. Oh, I see that now. I'm often confused by github PRs on how to get them to really refresh. ------------- PR: https://git.openjdk.org/skara/pull/1364 From shade at redhat.com Thu Sep 22 18:55:59 2022 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 22 Sep 2022 20:55:59 +0200 Subject: The bot doesn't add commit comment to the JMH issues In-Reply-To: References: <0be16c18-cdae-3607-d0ae-915d0ac9779c@oracle.com> Message-ID: On 9/22/22 15:32, Guoxiong Li wrote: > Actually I can't confirm?whether it is necessary. So I post this email to discuss with you. > If Aleksey Shipilev, the maintainer of the JMH, confirm we need to do that, > I will file the SKARA admin task for this. Yes, it would be nice we could handle this better. One solution is allowing bots to close the issue automatically after a manual merge. But, stepping back a bit, the root cause for these projects is that when the repo owner (me in case of JMH) needs to /integrate "directly", it is not possible to do so, because bots require reviews, and GitHub does not accept self-reviews. Allowing zero reviews is a no-go, because it allows committer to integrate without review. If it was possible to have the "whitelist" of users who can integrate directly, then people like me can just add themselves to it and use the regular /integrate. Maybe there is such an option already, and I just missed it. -- Thanks, -Aleksey From erikj at openjdk.org Thu Sep 22 21:29:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 21:29:02 GMT Subject: RFR: 1606: PullRequestPoller always processes the last updated MR for GitLab Message-ID: The new PullRequestPoller from [SKARA-1565](https://bugs.openjdk.org/browse/SKARA-1565) is inefficient in combination with GitLab. In the most common case, when no MRs have been updated, you would expect it to only do one GET query and be done. Instead, that initial query will always return the last updated MR, and then continue to fetch all the metadata for it, which adds up to a lot of time. This is made even worse by having to fetch comments and reviews for every MR to be able to compare them for potential updates. In GitLab, both comments and reviews are stored in the same set of "notes" for a merge request. Since we are only fetching them for comparing between different snapshots, we can make this faster by just fetching all notes once (which will also increase accuracy as there are other kinds of notes too, which we probably should check for updates too). The repeated refetching of the last updated MR is basically the same problem as the IssuePoller is already solving. The resolution for timestamp based queries is limited (1s on GitLab) and the query is inclusive. In contrast, the current implementation for GitLabRepository treats the timestamp as exclusive. This patch does the following: 1. Change all timestamp based pull request and issue queries (including for test implementations) to be inclusive, for consistency. 2. Implement the same kind of "positive" padding to the updatedAfter parameter in PullRequestPoller as is already present in IssuePoller. I'm also modifying tests to actually verify this behavior by exposing some of the internal data of the poller to the test. 3. Add `PullRequest::comparisonSnapshot` which returns an `Object` that represents all data that needs to be considered when evaluating if a snapshot is equal to another. In GitLabMergeRequest, this is cached lazily to avoid repeated remote calls. While working on this, I've realized that IssuePoller and PullRequestPoller are basically doing the exact same thing now, with pretty small variations. Ideally we should combine these into a common super class, but I'm leaving that for a separate change to make the current changes easier to follow. I'm going to run this change in "staging" for a bit to see how it behaves. ------------- Commit messages: - SKARA-1606 Changes: https://git.openjdk.org/skara/pull/1380/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1606 Stats: 320 lines in 17 files changed: 140 ins; 131 del; 49 mod Patch: https://git.openjdk.org/skara/pull/1380.diff Fetch: git fetch https://git.openjdk.org/skara pull/1380/head:pull/1380 PR: https://git.openjdk.org/skara/pull/1380 From erikj at openjdk.org Thu Sep 22 22:11:41 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 22:11:41 GMT Subject: RFR: 1606: PullRequestPoller always processes the last updated MR for GitLab [v2] In-Reply-To: References: Message-ID: > The new PullRequestPoller from [SKARA-1565](https://bugs.openjdk.org/browse/SKARA-1565) is inefficient in combination with GitLab. In the most common case, when no MRs have been updated, you would expect it to only do one GET query and be done. Instead, that initial query will always return the last updated MR, and then continue to fetch all the metadata for it, which adds up to a lot of time. > > This is made even worse by having to fetch comments and reviews for every MR to be able to compare them for potential updates. In GitLab, both comments and reviews are stored in the same set of "notes" for a merge request. Since we are only fetching them for comparing between different snapshots, we can make this faster by just fetching all notes once (which will also increase accuracy as there are other kinds of notes too, which we probably should check for updates too). > > The repeated refetching of the last updated MR is basically the same problem as the IssuePoller is already solving. The resolution for timestamp based queries is limited (1s on GitLab) and the query is inclusive. In contrast, the current implementation for GitLabRepository treats the timestamp as exclusive. > > This patch does the following: > > 1. Change all timestamp based pull request and issue queries (including for test implementations) to be inclusive, for consistency. > 2. Implement the same kind of "positive" padding to the updatedAfter parameter in PullRequestPoller as is already present in IssuePoller. I'm also modifying tests to actually verify this behavior by exposing some of the internal data of the poller to the test. > 3. Add `PullRequest::comparisonSnapshot` which returns an `Object` that represents all data that needs to be considered when evaluating if a snapshot is equal to another. In GitLabMergeRequest, this is cached lazily to avoid repeated remote calls. > > While working on this, I've realized that IssuePoller and PullRequestPoller are basically doing the exact same thing now, with pretty small variations. Ideally we should combine these into a common super class, but I'm leaving that for a separate change to make the current changes easier to follow. > > I'm going to run this change in "staging" for a bit to see how it behaves. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Not quite done yet ------------- Changes: - all: https://git.openjdk.org/skara/pull/1380/files - new: https://git.openjdk.org/skara/pull/1380/files/b0ae6597..fd0f0049 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=00-01 Stats: 69 lines in 3 files changed: 48 ins; 13 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1380.diff Fetch: git fetch https://git.openjdk.org/skara pull/1380/head:pull/1380 PR: https://git.openjdk.org/skara/pull/1380 From erik.joelsson at oracle.com Thu Sep 22 22:19:45 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 22 Sep 2022 15:19:45 -0700 Subject: [External] : Re: The bot doesn't add commit comment to the JMH issues In-Reply-To: References: <0be16c18-cdae-3607-d0ae-915d0ac9779c@oracle.com> Message-ID: On 9/22/22 11:55, Aleksey Shipilev wrote: > On 9/22/22 15:32, Guoxiong Li wrote: >> Actually I can't confirm?whether it is necessary. So I post this >> email to discuss with you. >> If Aleksey Shipilev, the maintainer of the JMH, confirm we need to do >> that, >> I will file the SKARA admin task for this. > > Yes, it would be nice we could handle this better. > > One solution is allowing bots to close the issue automatically after a > manual merge. > > But, stepping back a bit, the root cause for these projects is that > when the repo owner (me in case of JMH) needs to /integrate > "directly", it is not possible to do so, because bots require reviews, > and GitHub does not accept self-reviews. > > Allowing zero reviews is a no-go, because it allows committer to > integrate without review. If it was possible to have the "whitelist" > of users who can integrate directly, then people like me can just add > themselves to it and use the regular /integrate. Maybe there is such > an option already, and I just missed it. > As long as the commit message follows the standard, Skara can react to commits, just like it does in other repos. We just need to change the configuration. In mainline JDK (and most other repos), it's not the integration of a PR that triggers Skara to notify JBS, but the appearance of a new commit in a branch. /Erik From erikj at openjdk.org Thu Sep 22 22:29:39 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 22:29:39 GMT Subject: RFR: 1606: PullRequestPoller always processes the last updated MR for GitLab [v3] In-Reply-To: References: Message-ID: > The new PullRequestPoller from [SKARA-1565](https://bugs.openjdk.org/browse/SKARA-1565) is inefficient in combination with GitLab. In the most common case, when no MRs have been updated, you would expect it to only do one GET query and be done. Instead, that initial query will always return the last updated MR, and then continue to fetch all the metadata for it, which adds up to a lot of time. > > This is made even worse by having to fetch comments and reviews for every MR to be able to compare them for potential updates. In GitLab, both comments and reviews are stored in the same set of "notes" for a merge request. Since we are only fetching them for comparing between different snapshots, we can make this faster by just fetching all notes once (which will also increase accuracy as there are other kinds of notes too, which we probably should check for updates too). > > The repeated refetching of the last updated MR is basically the same problem as the IssuePoller is already solving. The resolution for timestamp based queries is limited (1s on GitLab) and the query is inclusive. In contrast, the current implementation for GitLabRepository treats the timestamp as exclusive. > > This patch does the following: > > 1. Change all timestamp based pull request and issue queries (including for test implementations) to be inclusive, for consistency. > 2. Implement the same kind of "positive" padding to the updatedAfter parameter in PullRequestPoller as is already present in IssuePoller. I'm also modifying tests to actually verify this behavior by exposing some of the internal data of the poller to the test. > 3. Add `PullRequest::comparisonSnapshot` which returns an `Object` that represents all data that needs to be considered when evaluating if a snapshot is equal to another. In GitLabMergeRequest, this is cached lazily to avoid repeated remote calls. > > While working on this, I've realized that IssuePoller and PullRequestPoller are basically doing the exact same thing now, with pretty small variations. Ideally we should combine these into a common super class, but I'm leaving that for a separate change to make the current changes easier to follow. > > I'm going to run this change in "staging" for a bit to see how it behaves. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Cleanup ------------- Changes: - all: https://git.openjdk.org/skara/pull/1380/files - new: https://git.openjdk.org/skara/pull/1380/files/fd0f0049..fff96d69 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1380.diff Fetch: git fetch https://git.openjdk.org/skara pull/1380/head:pull/1380 PR: https://git.openjdk.org/skara/pull/1380 From duke at openjdk.org Thu Sep 22 23:39:04 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:04 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion Message-ID: Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. Right now, when executed successfully, the location of index.html will be printed. Also, added a --quiet flag if the current silent behavior is required. ------------- Commit messages: - print webrev location after 'git webrev' execute successfullu Changes: https://git.openjdk.org/skara/pull/1379/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1379&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-327 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1379.diff Fetch: git fetch https://git.openjdk.org/skara pull/1379/head:pull/1379 PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Thu Sep 22 23:39:04 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:04 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:04:44 GMT, Zhao Song wrote: > Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. > > Right now, when executed successfully, the location of index.html will be printed. > > Also, added a --quiet flag if the current silent behavior is required. https://api.github.com/users/zhaosongzs/orgs My orgs shows right currently. But it's still not work. So I think the change of my Username of GitHub in OIM is required. ------------- PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Thu Sep 22 23:39:22 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:22 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository Message-ID: Optimized the logic in MirrorBot. When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. ------------- Commit messages: - In MirrorBot, just falling back on recloning when existing scratch directory has problem - optimized MirrorBot Changes: https://git.openjdk.org/skara/pull/1374/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1374&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1512 Stats: 55 lines in 2 files changed: 52 ins; 1 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1374.diff Fetch: git fetch https://git.openjdk.org/skara pull/1374/head:pull/1374 PR: https://git.openjdk.org/skara/pull/1374 From erikj at openjdk.org Thu Sep 22 23:39:24 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 23:39:24 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 21:14:07 GMT, Zhao Song wrote: > Optimized the logic in MirrorBot. > > When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. bots/mirror/src/main/java/org/openjdk/skara/bots/mirror/MirrorBot.java line 102: > 100: } else { > 101: log.info("Found existing scratch directory for " + to.name()); > 102: repo = Repository.get(dir).orElseThrow(() -> { Instead of introducing a temporary directory, I would recommend just falling back on recloning if `Repository::get` fails. Something like this: repo = Repository.get(dir).orElseGet(() -> { try { Files.walk(dir) .map(Path::toFile) .sorted(Comparator.reverseOrder()) .forEach(File::delete); } catch (IOException e) { throw new UncheckedIOException(e); } Repository.mirror(from.url(), dir); ); ------------- PR: https://git.openjdk.org/skara/pull/1374 From duke at openjdk.org Thu Sep 22 23:39:25 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:25 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository In-Reply-To: References: Message-ID: On Wed, 14 Sep 2022 21:01:30 GMT, Erik Joelsson wrote: >> Optimized the logic in MirrorBot. >> >> When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. > > bots/mirror/src/main/java/org/openjdk/skara/bots/mirror/MirrorBot.java line 102: > >> 100: } else { >> 101: log.info("Found existing scratch directory for " + to.name()); >> 102: repo = Repository.get(dir).orElseThrow(() -> { > > Instead of introducing a temporary directory, I would recommend just falling back on recloning if `Repository::get` fails. Something like this: > > repo = Repository.get(dir).orElseGet(() -> { > try { > Files.walk(dir) > .map(Path::toFile) > .sorted(Comparator.reverseOrder()) > .forEach(File::delete); > } catch (IOException e) { > throw new UncheckedIOException(e); > } > Repository.mirror(from.url(), dir); > ); Yes, it's much better! Thank you! ------------- PR: https://git.openjdk.org/skara/pull/1374 From duke at openjdk.org Thu Sep 22 23:39:37 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:37 GMT Subject: RFR: 1222: Git patch parser fails on Status T Message-ID: Make parser know Status T ------------- Commit messages: - fix a bug - make parser can handle Status T - make parser know Status T Changes: https://git.openjdk.org/skara/pull/1373/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1373&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1222 Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1373.diff Fetch: git fetch https://git.openjdk.org/skara pull/1373/head:pull/1373 PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Thu Sep 22 23:39:37 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:37 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T vcs/src/main/java/org/openjdk/skara/vcs/tools/PatchHeader.java line 108: > 106: } else if (status.isFileTypeChanged()) { > 107: sourcePath = Path.of(parts[1]); > 108: targetPath = sourcePath; I am not very sure whether this is right or not. I could not create a Status T raw line by myself ------------- PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Thu Sep 22 23:39:43 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:39:43 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter Message-ID: remove parameter 'comments' in CheckRun#findComment ------------- Commit messages: - refactor code related with activeReviews in CheckRun - remove parameter 'comments' in CheckRun#findComment Changes: https://git.openjdk.org/skara/pull/1375/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1375&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1562 Stats: 25 lines in 1 file changed: 0 ins; 0 del; 25 mod Patch: https://git.openjdk.org/skara/pull/1375.diff Fetch: git fetch https://git.openjdk.org/skara pull/1375/head:pull/1375 PR: https://git.openjdk.org/skara/pull/1375 From erikj at openjdk.org Thu Sep 22 23:39:44 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 Sep 2022 23:39:44 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 18:35:24 GMT, Zhao Song wrote: > remove parameter 'comments' in CheckRun#findComment Looks like activeReviews could be eliminated the same way. Also please note that you need to describe your change in the PR body. The bot doesn't accept an empty body as you can see from the error message here. ------------- PR: https://git.openjdk.org/skara/pull/1375 From duke at openjdk.org Thu Sep 22 23:53:15 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 22 Sep 2022 23:53:15 GMT Subject: RFR: 1235: git sync --branches doesn't work as expected Message-ID: Make git sync --branches works as expected. The argument after git sync --branches will not be ignored right now. ------------- Commit messages: - fix the bug on 'git sync --branches' Changes: https://git.openjdk.org/skara/pull/1381/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1381&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1235 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1381.diff Fetch: git fetch https://git.openjdk.org/skara pull/1381/head:pull/1381 PR: https://git.openjdk.org/skara/pull/1381 From gli at openjdk.org Fri Sep 23 00:46:11 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 23 Sep 2022 00:46:11 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T Please enable the GHA in your fork [1] and run it munually [2]. So as other PRs. Note: You don't need to run the GHA munually in the future, but GitHub can't help you run the GHA of your previous PRs. [1] https://wiki.openjdk.org/display/SKARA/Testing [2] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow ------------- PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Fri Sep 23 00:53:06 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 00:53:06 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T > Sure, I will run the tests tomorrow. Thanks for your guidance! > Please enable the GHA in your fork [1] and run it munually [2]. So as other PRs. Note: You don't need to run the GHA munually in the future, but GitHub can't help you run the GHA of your previous PRs. > > [1] https://wiki.openjdk.org/display/SKARA/Testing [2] https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow ------------- PR: https://git.openjdk.org/skara/pull/1373 From lgxbslgx at gmail.com Fri Sep 23 01:40:05 2022 From: lgxbslgx at gmail.com (Guoxiong Li) Date: Fri, 23 Sep 2022 09:40:05 +0800 Subject: The bot doesn't add commit comment to the JMH issues In-Reply-To: References: <0be16c18-cdae-3607-d0ae-915d0ac9779c@oracle.com> Message-ID: Filed https://bugs.openjdk.org/browse/SKARA-1607 to follow up -------------- next part -------------- An HTML attachment was scrubbed... URL: From ihse at openjdk.org Fri Sep 23 06:32:38 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 06:32:38 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: <5EuX8Epl385cuK1z7ZjHMtzLXbf5m6OSVJcw0D1qNBc=.9ebbe225-0572-4c86-b4db-597d92671671@github.com> On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T You can also just push an empty dummy commit after enabling GHA to trigger a run; that might be easier. ------------- PR: https://git.openjdk.org/skara/pull/1373 From ihse at openjdk.org Fri Sep 23 11:56:59 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 11:56:59 GMT Subject: RFR: 1235: git sync --branches doesn't work as expected In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 23:49:12 GMT, Zhao Song wrote: > Make git sync --branches works as expected. > > The argument after git sync --branches will not be ignored right now. Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1381 From ihse at openjdk.org Fri Sep 23 11:58:20 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 11:58:20 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:04:44 GMT, Zhao Song wrote: > Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. > > Right now, when executed successfully, the location of index.html will be printed. > > Also, added a --quiet flag if the current silent behavior is required. Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1379 From ihse at openjdk.org Fri Sep 23 12:52:32 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 12:52:32 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:43:18 GMT, Erik Joelsson wrote: >> I read the [labels](https://github.com/openjdk/jdk/labels) of the JDK project. Almost all of them are nouns and only few labels are adjectives. And the `approved` may be misunderstood as `the pull request has been approved`. So I use the label `approval`. > > I agree, the `approval` label is meant to signal that this PR is waiting on/needs approval. Ah, I see. Maybe `needs-approval` then? ------------- PR: https://git.openjdk.org/skara/pull/1364 From ihse at openjdk.org Fri Sep 23 13:01:32 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 13:01:32 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 12:50:07 GMT, Magnus Ihse Bursie wrote: >> I agree, the `approval` label is meant to signal that this PR is waiting on/needs approval. > > Ah, I see. Maybe `needs-approval` then? Or maybe I need to understand the entire labeling workflow better... Is this label supposed to signal "this PR is of a kind that needs approval" and all PRs of that kind (i.e., it is a backport made to an update repo) will have that label during their entire life span? Or is it supposed to act like a release blocker (as `ready` but inverted), so when approval is given, then the label is dropped? I have a hard time figuring out how this PR label relates to the "important" labels in JBS. I think I naively assumed that the PR label should reflect the state of the JBS labels, so you could understand from looking at the PR (and not having to go to JBS) to understand if it was in a state where it needed an approval request in JBS, a JBS approval request had been asked, or an approval had been given or denied in JBS. Since that was my mental model, having just a single `approval` label made no sense at all to me. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 23 13:48:25 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 13:48:25 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 12:58:10 GMT, Magnus Ihse Bursie wrote: >> Ah, I see. Maybe `needs-approval` then? > > Or maybe I need to understand the entire labeling workflow better... > > Is this label supposed to signal "this PR is of a kind that needs approval" and all PRs of that kind (i.e., it is a backport made to an update repo) will have that label during their entire life span? Or is it supposed to act like a release blocker (as `ready` but inverted), so when approval is given, then the label is dropped? > > I have a hard time figuring out how this PR label relates to the "important" labels in JBS. I think I naively assumed that the PR label should reflect the state of the JBS labels, so you could understand from looking at the PR (and not having to go to JBS) to understand if it was in a state where it needed an approval request in JBS, a JBS approval request had been asked, or an approval had been given or denied in JBS. > > Since that was my mental model, having just a single `approval` label made no sense at all to me. My Interpretation of this label is that it gets added when the PR is entering the request for approval stage and gets removed once approval has been given. That doesn't exactly correspond to any of the JBS labels. The approval process starts when a PR is otherwise ready for integration. This label would then automatically show up to remind the committer that approval is needed. It is then the responsibility of the committer to apply for approval in JBS (either directly or through the new `/request-approval` command). The maintainer then approves (in JBS or with the `/approve` command), and once that is done, the PR is truly ready for integration and the `approval` label is removed. Alternative definitions would be: 1. Add it to all PRs that need approval for the whole lifecycle. Not really helpful as this is a per repo/branch configuration option. This would also kind of encourage people to try to start the approval process ahead of time. 2. Mimic the JBS label jdkXu-fix-request. That would make it more useful for maintainers looking for PRs to approve, but would not help remind committers that they need to work on the process. Also I don't think Skara should just copy labels from JBS to PRs. Similar labels today are `csr` and `jep`. They are added once it's known to Skara that they are needed, either by explicit command or automatic discovery. The `csr` label is removed when that requirement is fulfilled. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 23 13:54:13 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 13:54:13 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 21:14:07 GMT, Zhao Song wrote: > Optimized the logic in MirrorBot. > > When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. bots/mirror/src/main/java/org/openjdk/skara/bots/mirror/MirrorBot.java line 92: > 90: log.info("Found existing scratch directory for " + to.name()); > 91: repo = Repository.get(dir).orElseGet(() -> { > 92: log.info("The existing scratch directory has problem. Now recloning " + from.name()); Suggestion: log.info("The existing scratch directory is not a valid repository. Recloning " + from.name()); bots/mirror/src/test/java/org/openjdk/skara/bots/mirror/MirrorBotTests.java line 485: > 483: URLEncoder.encode(toHostedRepo.webUrl().toString(), StandardCharsets.UTF_8); > 484: var dir_temporary = storage.resolve(sanitizedUrl); > 485: Files.createDirectories(dir_temporary); Please stick with the existing style of camelCase for identifiers. ------------- PR: https://git.openjdk.org/skara/pull/1374 From erikj at openjdk.org Fri Sep 23 14:12:38 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:12:38 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 18:35:24 GMT, Zhao Song wrote: > remove parameter 'comments' in CheckRun#findComment bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1074: > 1072: // Calculate and update the status message if needed > 1073: var statusMessage = getStatusMessage(visitor, additionalErrors, > 1074: additionalProgresses, integrationBlockers, isCleanBackport); Could you fixup the linebreak here. ------------- PR: https://git.openjdk.org/skara/pull/1375 From erikj at openjdk.org Fri Sep 23 14:17:02 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:17:02 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: <03LVNHvivRuyv2X8cYKlVm435mUESg93_SGWIhY42aQ=.2f43e73b-ec82-42be-8969-7e88fb61d18d@github.com> On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1373 From erikj at openjdk.org Fri Sep 23 14:19:39 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:19:39 GMT Subject: RFR: 1235: git sync --branches doesn't work as expected In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 23:49:12 GMT, Zhao Song wrote: > Make git sync --branches works as expected. > > The argument after git sync --branches will not be ignored right now. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1381 From ihse at openjdk.org Fri Sep 23 14:23:51 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 14:23:51 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T Looks good to me. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1373 From ihse at openjdk.org Fri Sep 23 14:27:24 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 14:27:24 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:45:18 GMT, Erik Joelsson wrote: >> Or maybe I need to understand the entire labeling workflow better... >> >> Is this label supposed to signal "this PR is of a kind that needs approval" and all PRs of that kind (i.e., it is a backport made to an update repo) will have that label during their entire life span? Or is it supposed to act like a release blocker (as `ready` but inverted), so when approval is given, then the label is dropped? >> >> I have a hard time figuring out how this PR label relates to the "important" labels in JBS. I think I naively assumed that the PR label should reflect the state of the JBS labels, so you could understand from looking at the PR (and not having to go to JBS) to understand if it was in a state where it needed an approval request in JBS, a JBS approval request had been asked, or an approval had been given or denied in JBS. >> >> Since that was my mental model, having just a single `approval` label made no sense at all to me. > > My Interpretation of this label is that it gets added when the PR is entering the request for approval stage and gets removed once approval has been given. That doesn't exactly correspond to any of the JBS labels. The approval process starts when a PR is otherwise ready for integration. This label would then automatically show up to remind the committer that approval is needed. It is then the responsibility of the committer to apply for approval in JBS (either directly or through the new `/request-approval` command). The maintainer then approves (in JBS or with the `/approve` command), and once that is done, the PR is truly ready for integration and the `approval` label is removed. > > Alternative definitions would be: > > 1. Add it to all PRs that need approval for the whole lifecycle. Not really helpful as this is a per repo/branch configuration option. This would also kind of encourage people to try to start the approval process ahead of time. > 2. Mimic the JBS label jdkXu-fix-request. That would make it more useful for maintainers looking for PRs to approve, but would not help remind committers that they need to work on the process. Also I don't think Skara should just copy labels from JBS to PRs. > > Similar labels today are `csr` and `jep`. They are added once it's known to Skara that they are needed, either by explicit command or automatic discovery. The `csr` label is removed when that requirement is fulfilled. Ok, fine, if the label is `csr` and not `csr-needed`, then it makes sense to have this as `approval`, not `approval-needed`. ------------- PR: https://git.openjdk.org/skara/pull/1364 From ihse at openjdk.org Fri Sep 23 14:27:24 2022 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 Sep 2022 14:27:24 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 14:22:46 GMT, Magnus Ihse Bursie wrote: >> My Interpretation of this label is that it gets added when the PR is entering the request for approval stage and gets removed once approval has been given. That doesn't exactly correspond to any of the JBS labels. The approval process starts when a PR is otherwise ready for integration. This label would then automatically show up to remind the committer that approval is needed. It is then the responsibility of the committer to apply for approval in JBS (either directly or through the new `/request-approval` command). The maintainer then approves (in JBS or with the `/approve` command), and once that is done, the PR is truly ready for integration and the `approval` label is removed. >> >> Alternative definitions would be: >> >> 1. Add it to all PRs that need approval for the whole lifecycle. Not really helpful as this is a per repo/branch configuration option. This would also kind of encourage people to try to start the approval process ahead of time. >> 2. Mimic the JBS label jdkXu-fix-request. That would make it more useful for maintainers looking for PRs to approve, but would not help remind committers that they need to work on the process. Also I don't think Skara should just copy labels from JBS to PRs. >> >> Similar labels today are `csr` and `jep`. They are added once it's known to Skara that they are needed, either by explicit command or automatic discovery. The `csr` label is removed when that requirement is fulfilled. > > Ok, fine, if the label is `csr` and not `csr-needed`, then it makes sense to have this as `approval`, not `approval-needed`. How does `approval` interplay with `ready`? Can a PR be both `ready` and `approval` at the same time? Or does it go from `rfr` to `approval` to `ready`? Or something else entirely? ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 23 14:38:27 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:38:27 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 16:04:44 GMT, Zhao Song wrote: > Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. > > Right now, when executed successfully, the location of index.html will be printed. > > Also, added a --quiet flag if the current silent behavior is required. cli/src/main/java/org/openjdk/skara/cli/GitWebrev.java line 463: > 461: if (!quiet) { > 462: System.out.println("Webrev executed successfully, details are in the link below:"); > 463: System.out.println("file://" + new File(output.resolve("index.html").toUri()).getAbsoluteFile()); That looks like a weird way to generate a URL. Why not just: Suggestion: System.out.println(output.resolve("index.html").toUri()); ------------- PR: https://git.openjdk.org/skara/pull/1379 From erikj at openjdk.org Fri Sep 23 14:42:04 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:42:04 GMT Subject: RFR: 1199: Enforce maintainer approval in JBS before allowing to integrate backports into updates projects [v6] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 14:23:57 GMT, Magnus Ihse Bursie wrote: >> Ok, fine, if the label is `csr` and not `csr-needed`, then it makes sense to have this as `approval`, not `approval-needed`. > > How does `approval` interplay with `ready`? Can a PR be both `ready` and `approval` at the same time? Or does it go from `rfr` to `approval` to `ready`? Or something else entirely? The `ready` label should mean that it's now possible to `/integrate`, so that means `rfr` -> `approval` -> `ready` in this case. ------------- PR: https://git.openjdk.org/skara/pull/1364 From erikj at openjdk.org Fri Sep 23 14:50:03 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 14:50:03 GMT Subject: RFR: 1606: PullRequestPoller always processes the last updated MR for GitLab [v3] In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 22:29:39 GMT, Erik Joelsson wrote: >> The new PullRequestPoller from [SKARA-1565](https://bugs.openjdk.org/browse/SKARA-1565) is inefficient in combination with GitLab. In the most common case, when no MRs have been updated, you would expect it to only do one GET query and be done. Instead, that initial query will always return the last updated MR, and then continue to fetch all the metadata for it, which adds up to a lot of time. >> >> This is made even worse by having to fetch comments and reviews for every MR to be able to compare them for potential updates. In GitLab, both comments and reviews are stored in the same set of "notes" for a merge request. Since we are only fetching them for comparing between different snapshots, we can make this faster by just fetching all notes once (which will also increase accuracy as there are other kinds of notes too, which we probably should check for updates too). >> >> The repeated refetching of the last updated MR is basically the same problem as the IssuePoller is already solving. The resolution for timestamp based queries is limited (1s on GitLab) and the query is inclusive. In contrast, the current implementation for GitLabRepository treats the timestamp as exclusive. >> >> This patch does the following: >> >> 1. Change all timestamp based pull request and issue queries (including for test implementations) to be inclusive, for consistency. >> 2. Implement the same kind of "positive" padding to the updatedAfter parameter in PullRequestPoller as is already present in IssuePoller. I'm also modifying tests to actually verify this behavior by exposing some of the internal data of the poller to the test. >> 3. Add `PullRequest::comparisonSnapshot` which returns an `Object` that represents all data that needs to be considered when evaluating if a snapshot is equal to another. In GitLabMergeRequest, this is cached lazily to avoid repeated remote calls. >> >> While working on this, I've realized that IssuePoller and PullRequestPoller are basically doing the exact same thing now, with pretty small variations. Ideally we should combine these into a common super class, but I'm leaving that for a separate change to make the current changes easier to follow. >> >> I'm going to run this change in "staging" for a bit to see how it behaves. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup Looking at logs, this is now working as intended. ------------- PR: https://git.openjdk.org/skara/pull/1380 From duke at openjdk.org Fri Sep 23 16:40:22 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:40:22 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion [v2] In-Reply-To: References: Message-ID: > Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. > > Right now, when executed successfully, the location of index.html will be printed. > > Also, added a --quiet flag if the current silent behavior is required. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: optimize the way to generate a URL ------------- Changes: - all: https://git.openjdk.org/skara/pull/1379/files - new: https://git.openjdk.org/skara/pull/1379/files/d487b78b..598d889e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1379&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1379&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1379.diff Fetch: git fetch https://git.openjdk.org/skara pull/1379/head:pull/1379 PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Fri Sep 23 16:40:23 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:40:23 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 14:35:04 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> optimize the way to generate a URL > > cli/src/main/java/org/openjdk/skara/cli/GitWebrev.java line 463: > >> 461: if (!quiet) { >> 462: System.out.println("Webrev executed successfully, details are in the link below:"); >> 463: System.out.println("file://" + new File(output.resolve("index.html").toUri()).getAbsoluteFile()); > > That looks like a weird way to generate a URL. Why not just: > Suggestion: > > System.out.println(output.resolve("index.html").toUri()); Yeah, will do the change ------------- PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Fri Sep 23 16:51:30 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:51:30 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 14:10:03 GMT, Erik Joelsson wrote: >> remove parameter 'comments' in CheckRun#findComment. >> >> remove parameter 'activeReviews' in many method interface. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1074: > >> 1072: // Calculate and update the status message if needed >> 1073: var statusMessage = getStatusMessage(visitor, additionalErrors, >> 1074: additionalProgresses, integrationBlockers, isCleanBackport); > > Could you fixup the linebreak here. Sure, thanks for your advice! ------------- PR: https://git.openjdk.org/skara/pull/1375 From duke at openjdk.org Fri Sep 23 16:51:46 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:51:46 GMT Subject: RFR: 1222: Git patch parser fails on Status T [v2] In-Reply-To: References: Message-ID: > Make parser know Status T Zhao Song has updated the pull request incrementally with one additional commit since the last revision: dummy commit ------------- Changes: - all: https://git.openjdk.org/skara/pull/1373/files - new: https://git.openjdk.org/skara/pull/1373/files/e9500b37..6e0f924a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1373&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1373&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1373.diff Fetch: git fetch https://git.openjdk.org/skara pull/1373/head:pull/1373 PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Fri Sep 23 16:51:48 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:51:48 GMT Subject: RFR: 1222: Git patch parser fails on Status T In-Reply-To: <5EuX8Epl385cuK1z7ZjHMtzLXbf5m6OSVJcw0D1qNBc=.9ebbe225-0572-4c86-b4db-597d92671671@github.com> References: <5EuX8Epl385cuK1z7ZjHMtzLXbf5m6OSVJcw0D1qNBc=.9ebbe225-0572-4c86-b4db-597d92671671@github.com> Message-ID: <39eY8kraKNHPeIQ_L2DK7hbIfYxdRACaEgxVQJgfm1Q=.87206eba-e9e0-4e96-a318-5386ce1bb9b0@github.com> On Fri, 23 Sep 2022 06:29:29 GMT, Magnus Ihse Bursie wrote: > You can also just push an empty dummy commit after enabling GHA to trigger a run; that might be easier. Yes, it's easy for me, thanks for your advice! ------------- PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Fri Sep 23 16:52:04 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:52:04 GMT Subject: RFR: 1235: git sync --branches doesn't work as expected [v2] In-Reply-To: References: Message-ID: > Make git sync --branches works as expected. > > The argument after git sync --branches will not be ignored right now. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: dummy commit ------------- Changes: - all: https://git.openjdk.org/skara/pull/1381/files - new: https://git.openjdk.org/skara/pull/1381/files/eccff671..0ef0bfa9 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1381&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1381&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1381.diff Fetch: git fetch https://git.openjdk.org/skara pull/1381/head:pull/1381 PR: https://git.openjdk.org/skara/pull/1381 From duke at openjdk.org Fri Sep 23 16:57:20 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:57:20 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter [v2] In-Reply-To: References: Message-ID: > remove parameter 'comments' in CheckRun#findComment. > > remove parameter 'activeReviews' in many method interface. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix a linebreak ------------- Changes: - all: https://git.openjdk.org/skara/pull/1375/files - new: https://git.openjdk.org/skara/pull/1375/files/43060dd5..b5a2f2a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1375&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1375&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1375.diff Fetch: git fetch https://git.openjdk.org/skara pull/1375/head:pull/1375 PR: https://git.openjdk.org/skara/pull/1375 From duke at openjdk.org Fri Sep 23 16:58:04 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 16:58:04 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 13:48:35 GMT, Erik Joelsson wrote: >> Optimized the logic in MirrorBot. >> >> When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. > > bots/mirror/src/main/java/org/openjdk/skara/bots/mirror/MirrorBot.java line 92: > >> 90: log.info("Found existing scratch directory for " + to.name()); >> 91: repo = Repository.get(dir).orElseGet(() -> { >> 92: log.info("The existing scratch directory has problem. Now recloning " + from.name()); > > Suggestion: > > log.info("The existing scratch directory is not a valid repository. Recloning " + from.name()); Got it! Will change it. > bots/mirror/src/test/java/org/openjdk/skara/bots/mirror/MirrorBotTests.java line 485: > >> 483: URLEncoder.encode(toHostedRepo.webUrl().toString(), StandardCharsets.UTF_8); >> 484: var dir_temporary = storage.resolve(sanitizedUrl); >> 485: Files.createDirectories(dir_temporary); > > Please stick with the existing style of camelCase for identifiers. Sure. ------------- PR: https://git.openjdk.org/skara/pull/1374 From duke at openjdk.org Fri Sep 23 17:02:15 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 17:02:15 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository [v2] In-Reply-To: References: Message-ID: > Optimized the logic in MirrorBot. > > When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Fixed some syntax errors ------------- Changes: - all: https://git.openjdk.org/skara/pull/1374/files - new: https://git.openjdk.org/skara/pull/1374/files/49b4d0ef..0e5be748 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1374&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1374&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1374.diff Fetch: git fetch https://git.openjdk.org/skara pull/1374/head:pull/1374 PR: https://git.openjdk.org/skara/pull/1374 From duke at openjdk.org Fri Sep 23 17:23:37 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 17:23:37 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" Message-ID: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Jira Issues will be resolved as "Fixed" regardless of the current state. ------------- Commit messages: - Jira Issues should be resolved as Fixed Changes: https://git.openjdk.org/skara/pull/1382/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1364 Stats: 25 lines in 1 file changed: 4 ins; 0 del; 21 mod Patch: https://git.openjdk.org/skara/pull/1382.diff Fetch: git fetch https://git.openjdk.org/skara pull/1382/head:pull/1382 PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 17:53:12 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 17:53:12 GMT Subject: RFR: 1584: Require re-review of a PR if the target branch changes Message-ID: This change improves reviewer handling when the target branch of a PR is changed. Currently this only invalidates a review on GitHub, but not on GitLab. With this change the behavior is made uniform. In addition to this, the following new behavior is added. 1. When the target branch of a PR is changed, any existing reviews in the Reviewers list will be flagged as "Re-review required (review applies to pull request targeting )" to make what happened clearer. 2. If the target branch of a PR is changed back to a previously targeted branch, any reviews made against that branch may now become valid again (if all other requirements are met). Note that changes to and from pr/X branches are ignored, just like before. PullRequest::reviews is no longer specifying the order of reviews returned. This order was actually not consistent between implementations and I would rather we use explicit sorts when needed instead of assuming an order. I'm not really happy with the placement of the new static method `calculateReviewTargetRefs`, but I couldn't really find a better location, and I really wanted to share this between different `PullRequest` implementations. I think the correct solution would be to introduce an `AbstractPullRequest` common super class, but I didn't want to do this for a single method. I have verified this with the new and modified tests, as well as by running against the playground repo(s). ------------- Commit messages: - SKARA-1584 Changes: https://git.openjdk.org/skara/pull/1383/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1383&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1584 Stats: 321 lines in 13 files changed: 270 ins; 13 del; 38 mod Patch: https://git.openjdk.org/skara/pull/1383.diff Fetch: git fetch https://git.openjdk.org/skara pull/1383/head:pull/1383 PR: https://git.openjdk.org/skara/pull/1383 From erikj at openjdk.org Fri Sep 23 18:00:06 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:00:06 GMT Subject: RFR: 1222: Git patch parser fails on Status T [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 16:51:46 GMT, Zhao Song wrote: >> Make parser know Status T > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > dummy commit Marked as reviewed by erikj (Lead). Tests are passing so you can post `/integrate` now. ------------- PR: https://git.openjdk.org/skara/pull/1373 From erikj at openjdk.org Fri Sep 23 18:01:06 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:01:06 GMT Subject: RFR: 1235: git sync --branches doesn't work as expected [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 16:52:04 GMT, Zhao Song wrote: >> Make git sync --branches works as expected. >> >> The argument after git sync --branches will not be ignored right now. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > dummy commit Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1381 From erikj at openjdk.org Fri Sep 23 18:02:11 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:02:11 GMT Subject: RFR: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter [v2] In-Reply-To: References: Message-ID: <2AUZ9mTuG1mlBX71LbSpO4EWmfKp8VR4apQonaEdVE0=.1609a9e0-b1c4-46c2-8128-0e3e9a9e9b73@github.com> On Fri, 23 Sep 2022 16:57:20 GMT, Zhao Song wrote: >> remove parameter 'comments' in CheckRun#findComment. >> >> remove parameter 'activeReviews' in many method interface. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fix a linebreak Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1375 From erikj at openjdk.org Fri Sep 23 18:02:39 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:02:39 GMT Subject: RFR: 1512: MirrorBot may get stuck failing to clone repository [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 17:02:15 GMT, Zhao Song wrote: >> Optimized the logic in MirrorBot. >> >> When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Fixed some syntax errors Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1374 From erikj at openjdk.org Fri Sep 23 18:08:06 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:08:06 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" In-Reply-To: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 17:18:56 GMT, Zhao Song wrote: > Jira Issues will be resolved as "Fixed" regardless of the current state. Since last we talked, I have been thinking about this some more. I think we actually do need to check the `resolution` of the issue before re-opening and resolving it. If it's already "resolved" "fixed" then we shouldn't touch the state. The reason for this is to try to keep the bots idempotent as much as possible. If we need to rerun the notifier on commits, then if nothing needs to happen, nothing should happen. The challenge here is that Skara doesn't currently know how to read the resolution, so we would need to implement support for that. ------------- PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 18:14:59 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 18:14:59 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 18:04:52 GMT, Erik Joelsson wrote: > Since last we talked, I have been thinking about this some more. I think we actually do need to check the `resolution` of the issue before re-opening and resolving it. If it's already "resolved" "fixed" then we shouldn't touch the state. > > The reason for this is to try to keep the bots idempotent as much as possible. If we need to rerun the notifier on commits, then if nothing needs to happen, nothing should happen. > > The challenge here is that Skara doesn't currently know how to read the resolution, so we would need to implement support for that. I just checked the source for `JiraIssue` and there is already a method `isFixed` which you can use. It should do exactly what we want here. ------------- PR: https://git.openjdk.org/skara/pull/1382 From duke at openjdk.org Fri Sep 23 18:14:59 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 18:14:59 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 18:10:39 GMT, Erik Joelsson wrote: > > Since last we talked, I have been thinking about this some more. I think we actually do need to check the `resolution` of the issue before re-opening and resolving it. If it's already "resolved" "fixed" then we shouldn't touch the state. > > The reason for this is to try to keep the bots idempotent as much as possible. If we need to rerun the notifier on commits, then if nothing needs to happen, nothing should happen. > > The challenge here is that Skara doesn't currently know how to read the resolution, so we would need to implement support for that. > > I just checked the source for `JiraIssue` and there is already a method `isFixed` which you can use. It should do exactly what we want here. Got it! I will use it. ------------- PR: https://git.openjdk.org/skara/pull/1382 From duke at openjdk.org Fri Sep 23 18:28:14 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 18:28:14 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v2] In-Reply-To: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: > Jira Issues will be resolved as "Fixed" regardless of the current state. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Check the resolution of JiraIssue before setting the state to Resolved ------------- Changes: - all: https://git.openjdk.org/skara/pull/1382/files - new: https://git.openjdk.org/skara/pull/1382/files/4fa4aaa9..8c82437c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=00-01 Stats: 29 lines in 1 file changed: 10 ins; 2 del; 17 mod Patch: https://git.openjdk.org/skara/pull/1382.diff Fetch: git fetch https://git.openjdk.org/skara pull/1382/head:pull/1382 PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 19:00:57 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 19:00:57 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v2] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 18:28:14 GMT, Zhao Song wrote: >> Jira Issues will be resolved as "Fixed" regardless of the current state. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Check the resolution of JiraIssue before setting the state to Resolved bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 198: > 196: log.info("Resolving issue which status is not open, the status is " + issue.state()); > 197: } else { > 198: log.info("Resolving issue " + issue.id()); No need for conditional here, we can use the same log message regardless of current state. Also, updating assignees should also be done (as long as it's currently empty). Suggestion: log.info("Resolving issue " + issue.id() + " from state " + issue.state()); bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 210: > 208: issue.setState(Issue.State.RESOLVED); > 209: } else { > 210: log.info("The issue has been already resolved"); Suggestion: log.info("The issue was already 'fixed'"); Same below. ------------- PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 19:20:11 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 19:20:11 GMT Subject: RFR: 1606: PullRequestPoller always processes the last updated MR for GitLab [v4] In-Reply-To: References: Message-ID: > The new PullRequestPoller from [SKARA-1565](https://bugs.openjdk.org/browse/SKARA-1565) is inefficient in combination with GitLab. In the most common case, when no MRs have been updated, you would expect it to only do one GET query and be done. Instead, that initial query will always return the last updated MR, and then continue to fetch all the metadata for it, which adds up to a lot of time. > > This is made even worse by having to fetch comments and reviews for every MR to be able to compare them for potential updates. In GitLab, both comments and reviews are stored in the same set of "notes" for a merge request. Since we are only fetching them for comparing between different snapshots, we can make this faster by just fetching all notes once (which will also increase accuracy as there are other kinds of notes too, which we probably should check for updates too). > > The repeated refetching of the last updated MR is basically the same problem as the IssuePoller is already solving. The resolution for timestamp based queries is limited (1s on GitLab) and the query is inclusive. In contrast, the current implementation for GitLabRepository treats the timestamp as exclusive. > > This patch does the following: > > 1. Change all timestamp based pull request and issue queries (including for test implementations) to be inclusive, for consistency. > 2. Implement the same kind of "positive" padding to the updatedAfter parameter in PullRequestPoller as is already present in IssuePoller. I'm also modifying tests to actually verify this behavior by exposing some of the internal data of the poller to the test. > 3. Add `PullRequest::comparisonSnapshot` which returns an `Object` that represents all data that needs to be considered when evaluating if a snapshot is equal to another. In GitLabMergeRequest, this is cached lazily to avoid repeated remote calls. > > While working on this, I've realized that IssuePoller and PullRequestPoller are basically doing the exact same thing now, with pretty small variations. Ideally we should combine these into a common super class, but I'm leaving that for a separate change to make the current changes easier to follow. > > I'm going to run this change in "staging" for a bit to see how it behaves. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Applying the same fixes to IssuePoller ------------- Changes: - all: https://git.openjdk.org/skara/pull/1380/files - new: https://git.openjdk.org/skara/pull/1380/files/fff96d69..b9092aee Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1380&range=02-03 Stats: 51 lines in 3 files changed: 32 ins; 11 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1380.diff Fetch: git fetch https://git.openjdk.org/skara pull/1380/head:pull/1380 PR: https://git.openjdk.org/skara/pull/1380 From duke at openjdk.org Fri Sep 23 19:26:15 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 19:26:15 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v2] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 18:28:14 GMT, Zhao Song wrote: >> Jira Issues will be resolved as "Fixed" regardless of the current state. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Check the resolution of JiraIssue before setting the state to Resolved bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 320: > 318: issue.addComment(commitNotification); > 319: } > 320: if (issue.state() != Issue.State.OPEN) { Hi @erikj79 , I am wondering whether we need condition here. Do we only update the assignee when the issue is open? ------------- PR: https://git.openjdk.org/skara/pull/1382 From duke at openjdk.org Fri Sep 23 19:26:15 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 19:26:15 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v2] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: <6doD5byRJG_oUBMieYQ5TKarF20s9pqeGsLkWNd57Sg=.ae5193cb-de15-4d9f-8ddd-516ab9a8115a@github.com> On Fri, 23 Sep 2022 19:20:19 GMT, Zhao Song wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> Check the resolution of JiraIssue before setting the state to Resolved > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 320: > >> 318: issue.addComment(commitNotification); >> 319: } >> 320: if (issue.state() != Issue.State.OPEN) { > > Hi @erikj79 , I am wondering whether we need condition here. Do we only update the assignee when the issue is open? If it it not, I think I should update one assertion in IssueNotifierTests#testAltFixVersionsMatch ------------- PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 19:43:58 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 19:43:58 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v2] In-Reply-To: <6doD5byRJG_oUBMieYQ5TKarF20s9pqeGsLkWNd57Sg=.ae5193cb-de15-4d9f-8ddd-516ab9a8115a@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> <6doD5byRJG_oUBMieYQ5TKarF20s9pqeGsLkWNd57Sg=.ae5193cb-de15-4d9f-8ddd-516ab9a8115a@github.com> Message-ID: On Fri, 23 Sep 2022 19:22:23 GMT, Zhao Song wrote: >> bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 320: >> >>> 318: issue.addComment(commitNotification); >>> 319: } >>> 320: if (issue.state() != Issue.State.OPEN) { >> >> Hi @erikj79 , I am wondering whether we need condition here. Do we only update the assignee when the issue is open? > > If it it not, I think I should update one assertion in IssueNotifierTests#testAltFixVersionsMatch oh, forgot to say, same thing here as in the other method. We don't need this conditional. ------------- PR: https://git.openjdk.org/skara/pull/1382 From duke at openjdk.org Fri Sep 23 19:47:52 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 19:47:52 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v3] In-Reply-To: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: > Jira Issues will be resolved as "Fixed" regardless of the current state. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: remove some conditions ------------- Changes: - all: https://git.openjdk.org/skara/pull/1382/files - new: https://git.openjdk.org/skara/pull/1382/files/8c82437c..dba67f8d Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=01-02 Stats: 29 lines in 2 files changed: 1 ins; 8 del; 20 mod Patch: https://git.openjdk.org/skara/pull/1382.diff Fetch: git fetch https://git.openjdk.org/skara pull/1382/head:pull/1382 PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Fri Sep 23 19:54:33 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 19:54:33 GMT Subject: RFR: 327: git webrev: Print the location of the generated webrev upon successful completion [v2] In-Reply-To: References: Message-ID: On Fri, 23 Sep 2022 16:40:22 GMT, Zhao Song wrote: >> Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. >> >> Right now, when executed successfully, the location of index.html will be printed. >> >> Also, added a --quiet flag if the current silent behavior is required. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > optimize the way to generate a URL Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Fri Sep 23 19:54:34 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 19:54:34 GMT Subject: Integrated: 1222: Git patch parser fails on Status T In-Reply-To: References: Message-ID: <72lHZyiPFU2Ip1ipBna-z25dGPn4wNzC4zF8fQzXjXA=.1a769805-4b6b-4fce-8c5d-29274039c749@github.com> On Tue, 13 Sep 2022 16:44:55 GMT, Zhao Song wrote: > Make parser know Status T This pull request has now been integrated. Changeset: 39cb319b Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/39cb319b753893812993bddc0c1064b5b8c5801a Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod 1222: Git patch parser fails on Status T Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/skara/pull/1373 From duke at openjdk.org Fri Sep 23 19:59:36 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 19:59:36 GMT Subject: Integrated: 1562: The method 'CheckRun#findComment' don't need the comment list as parameter In-Reply-To: References: Message-ID: On Thu, 15 Sep 2022 18:35:24 GMT, Zhao Song wrote: > remove parameter 'comments' in CheckRun#findComment. > > remove parameter 'activeReviews' in many method interface. This pull request has now been integrated. Changeset: 78cab784 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/78cab78418e8282ea7b08eb5e41395a481898d59 Stats: 26 lines in 1 file changed: 0 ins; 1 del; 25 mod 1562: The method 'CheckRun#findComment' don't need the comment list as parameter Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1375 From erikj at openjdk.org Fri Sep 23 20:00:24 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 20:00:24 GMT Subject: RFR: 1584: Require re-review of a PR if the target branch changes [v2] In-Reply-To: References: Message-ID: > This change improves reviewer handling when the target branch of a PR is changed. Currently this only invalidates a review on GitHub, but not on GitLab. With this change the behavior is made uniform. In addition to this, the following new behavior is added. > > 1. When the target branch of a PR is changed, any existing reviews in the Reviewers list will be flagged as "Re-review required (review applies to pull request targeting )" to make what happened clearer. > 2. If the target branch of a PR is changed back to a previously targeted branch, any reviews made against that branch may now become valid again (if all other requirements are met). > > Note that changes to and from pr/X branches are ignored, just like before. > > PullRequest::reviews is no longer specifying the order of reviews returned. This order was actually not consistent between implementations and I would rather we use explicit sorts when needed instead of assuming an order. > > I'm not really happy with the placement of the new static method `calculateReviewTargetRefs`, but I couldn't really find a better location, and I really wanted to share this between different `PullRequest` implementations. I think the correct solution would be to introduce an `AbstractPullRequest` common super class, but I didn't want to do this for a single method. > > I have verified this with the new and modified tests, as well as by running against the playground repo(s). Erik Joelsson 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-1584-rereview-targetref - SKARA-1584 ------------- Changes: https://git.openjdk.org/skara/pull/1383/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1383&range=01 Stats: 299 lines in 13 files changed: 246 ins; 13 del; 40 mod Patch: https://git.openjdk.org/skara/pull/1383.diff Fetch: git fetch https://git.openjdk.org/skara pull/1383/head:pull/1383 PR: https://git.openjdk.org/skara/pull/1383 From duke at openjdk.org Fri Sep 23 20:01:57 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 20:01:57 GMT Subject: Integrated: 1235: git sync --branches doesn't work as expected In-Reply-To: References: Message-ID: On Thu, 22 Sep 2022 23:49:12 GMT, Zhao Song wrote: > Make git sync --branches works as expected. > > The argument after git sync --branches will not be ignored right now. This pull request has now been integrated. Changeset: 0a4aa299 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/0a4aa299f3d5702f32e850d944694f15015ef086 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1235: git sync --branches doesn't work as expected Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/skara/pull/1381 From duke at openjdk.org Fri Sep 23 20:02:45 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 20:02:45 GMT Subject: Integrated: 327: git webrev: Print the location of the generated webrev upon successful completion In-Reply-To: References: Message-ID: <-bBNovYe3-xs3f4ou7pJSRMwnMwvz07cAnBh6SYrmGE=.2deaba1a-30bb-4e8f-a152-d41ef23f56ca@github.com> On Thu, 22 Sep 2022 16:04:44 GMT, Zhao Song wrote: > Originally, git webrev command would return nothing when executed successfully. It is not a good experience for user. > > Right now, when executed successfully, the location of index.html will be printed. > > Also, added a --quiet flag if the current silent behavior is required. This pull request has now been integrated. Changeset: 773ec06c Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/773ec06c2a813f03d4341cf4ae36f9c5ae12fd70 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 327: git webrev: Print the location of the generated webrev upon successful completion Reviewed-by: ihse, erikj ------------- PR: https://git.openjdk.org/skara/pull/1379 From duke at openjdk.org Fri Sep 23 20:03:06 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 20:03:06 GMT Subject: Integrated: 1512: MirrorBot may get stuck failing to clone repository In-Reply-To: References: Message-ID: <4-e1DuFidA_HEw5yPsWEmOylRss_weSXbc_Ir3fSKaE=.cf2160fa-4877-4826-95ab-c3608c3d268a@github.com> On Tue, 13 Sep 2022 21:14:07 GMT, Zhao Song wrote: > Optimized the logic in MirrorBot. > > When MirrorBot tries to create a directory, the directory will have a 'temporary' suffix, then it will attempts cloning. It the cloning succeed, the suffix will be removed. If the clone fails or the bot happens to die, the directory will retain the suffix. On the next time, if we try to rerun the bot, the bot will detect the temporary directory and will delete the temporary directory first, therefore, the bot will not get stuck. This pull request has now been integrated. Changeset: 7cf47ca0 Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/7cf47ca037f9157195d330d746ffd7164edffea2 Stats: 55 lines in 2 files changed: 52 ins; 1 del; 2 mod 1512: MirrorBot may get stuck failing to clone repository Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1374 From erikj at openjdk.org Fri Sep 23 20:04:53 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 20:04:53 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v3] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 19:47:52 GMT, Zhao Song wrote: >> Jira Issues will be resolved as "Fixed" regardless of the current state. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > remove some conditions bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 195: > 193: // If prOnly is false, this is instead done when processing commits > 194: if (prOnly && resolve) { > 195: log.info("Resolving issue " + issue.id() + " from state " + issue.state()); We should keep the log message and the issue.setState call together. I think moving lines 203-207 up here would be best to keep the flow as similar to before as we can. Same applies in the other method. ------------- PR: https://git.openjdk.org/skara/pull/1382 From vladimir.kempik at gmail.com Fri Sep 23 20:11:12 2022 From: vladimir.kempik at gmail.com (Vladimir Kempik) Date: Fri, 23 Sep 2022 23:11:12 +0300 Subject: Skara github bot and testing Message-ID: <30068EE0-2790-46E0-875C-26ADCD41C96D@gmail.com> Hello I just found useful some possible addition to github bot. Currently openjdk?s GitHub CI tests only specific sets of tests ( right now only tier1). It would be nice to have it also test any testcase which was modified by the commit. This would be useful for clean backports to make sure the jdk with the patch passes updated/new test (without making local build) Not really sure if it?s for Skara or CI. Regards, Vladimir From duke at openjdk.org Fri Sep 23 20:20:51 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 20:20:51 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v3] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 20:00:48 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> remove some conditions > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 195: > >> 193: // If prOnly is false, this is instead done when processing commits >> 194: if (prOnly && resolve) { >> 195: log.info("Resolving issue " + issue.id() + " from state " + issue.state()); > > We should keep the log message and the issue.setState call together. I think moving lines 203-207 up here would be best to keep the flow as similar to before as we can. Same applies in the other method. Sure ------------- PR: https://git.openjdk.org/skara/pull/1382 From duke at openjdk.org Fri Sep 23 20:23:05 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 23 Sep 2022 20:23:05 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v4] In-Reply-To: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: > Jira Issues will be resolved as "Fixed" regardless of the current state. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Adjusted the format ------------- Changes: - all: https://git.openjdk.org/skara/pull/1382/files - new: https://git.openjdk.org/skara/pull/1382/files/dba67f8d..84874a61 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1382&range=02-03 Stats: 21 lines in 1 file changed: 10 ins; 11 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1382.diff Fetch: git fetch https://git.openjdk.org/skara pull/1382/head:pull/1382 PR: https://git.openjdk.org/skara/pull/1382 From erik.joelsson at oracle.com Fri Sep 23 20:35:03 2022 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 23 Sep 2022 13:35:03 -0700 Subject: Skara github bot and testing In-Reply-To: <30068EE0-2790-46E0-875C-26ADCD41C96D@gmail.com> References: <30068EE0-2790-46E0-875C-26ADCD41C96D@gmail.com> Message-ID: Hello, On 9/23/22 13:11, Vladimir Kempik wrote: > Hello > I just found useful some possible addition to github bot. > Currently openjdk?s GitHub CI tests only specific sets of tests ( right now only tier1). > It would be nice to have it also test any testcase which was modified by the commit. > This would be useful for clean backports to make sure the jdk with the patch passes updated/new test (without making local build) > Not really sure if it?s for Skara or CI. This is a question the people maintaining the github actions definition in the JDK repo. I think you will find most of them on build-dev. /Erik From erikj at openjdk.org Fri Sep 23 20:35:57 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 Sep 2022 20:35:57 GMT Subject: RFR: 1364: Jira Issues should be resolved as "Fixed" [v4] In-Reply-To: References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: On Fri, 23 Sep 2022 20:23:05 GMT, Zhao Song wrote: >> Jira Issues will be resolved as "Fixed" regardless of the current state. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Adjusted the format Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Mon Sep 26 18:35:47 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Sep 2022 18:35:47 GMT Subject: RFR: 1612: Temp workaround GitLab returning 500 when modifying labels Message-ID: We are currently experiencing an issue where GitLab returns 500 when we add or remove labels to a merge request. The label change still happens though, so to keep things running, I'm going to implement a temporary workaround to ignore the 500 result on these particular REST calls. ------------- Commit messages: - SKARA-1612 Changes: https://git.openjdk.org/skara/pull/1384/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1384&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1612 Stats: 20 lines in 1 file changed: 16 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1384.diff Fetch: git fetch https://git.openjdk.org/skara pull/1384/head:pull/1384 PR: https://git.openjdk.org/skara/pull/1384 From kcr at openjdk.org Mon Sep 26 18:58:26 2022 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 26 Sep 2022 18:58:26 GMT Subject: RFR: 1612: Temp workaround GitLab returning 500 when modifying labels In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 18:31:07 GMT, Erik Joelsson wrote: > We are currently experiencing an issue where GitLab returns 500 when we add or remove labels to a merge request. The label change still happens though, so to keep things running, I'm going to implement a temporary workaround to ignore the 500 result on these particular REST calls. Looks good. ------------- Marked as reviewed by kcr (Reviewer). PR: https://git.openjdk.org/skara/pull/1384 From duke at openjdk.org Mon Sep 26 21:40:31 2022 From: duke at openjdk.org (Zhao Song) Date: Mon, 26 Sep 2022 21:40:31 GMT Subject: Integrated: 1364: Jira Issues should be resolved as "Fixed" In-Reply-To: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> References: <47L5jyMsx9uLgFtXs-RygtD855B_CvCzr7Jtk_P0_Jg=.8555bb46-e344-4710-96ee-50f9f007cb40@github.com> Message-ID: <3HpD_y5Ol51rZpXI988B9LIl7sP5YiTXiToaSbP1rSc=.61670525-ce8e-4ea1-943a-4e754e7f004a@github.com> On Fri, 23 Sep 2022 17:18:56 GMT, Zhao Song wrote: > Jira Issues will be resolved as "Fixed" regardless of the current state. This pull request has now been integrated. Changeset: a6860bcb Author: Zhao Song Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/a6860bcba94d93a2be7429ad7a8766755a925581 Stats: 26 lines in 2 files changed: 4 ins; 0 del; 22 mod 1364: Jira Issues should be resolved as "Fixed" Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1382 From erikj at openjdk.org Mon Sep 26 21:41:17 2022 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 26 Sep 2022 21:41:17 GMT Subject: Integrated: 1612: Temp workaround GitLab returning 500 when modifying labels In-Reply-To: References: Message-ID: On Mon, 26 Sep 2022 18:31:07 GMT, Erik Joelsson wrote: > We are currently experiencing an issue where GitLab returns 500 when we add or remove labels to a merge request. The label change still happens though, so to keep things running, I'm going to implement a temporary workaround to ignore the 500 result on these particular REST calls. This pull request has now been integrated. Changeset: b061577e Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/b061577e3ed45b464e73b865d8b73528b9166e07 Stats: 20 lines in 1 file changed: 16 ins; 0 del; 4 mod 1612: Temp workaround GitLab returning 500 when modifying labels Reviewed-by: kcr ------------- PR: https://git.openjdk.org/skara/pull/1384 From bylokhov at amazon.com Wed Sep 28 22:28:31 2022 From: bylokhov at amazon.com (Sergey Bylokhov) Date: Wed, 28 Sep 2022 15:28:31 -0700 Subject: Automatic replacement of 8-pool by the specific version Message-ID: <28e98448-3119-3ddf-9a1f-6f131d51076d@amazon.com> Hello, I few years ago the "Fix Version" equal to 8-pool is automatically updated by the hgupdater to the specific version. For example https://bugs.openjdk.org/browse/JDK-8266348 where "8-pool" was replaced by the "8u311". But looks like now it stopped working: https://bugs.openjdk.org/browse/JDK-8293461, note that a new backport was created for "openjdk8u362". Is it intentional change or it is a bug somewhere? -- Best regards, Sergey. From duke at openjdk.org Thu Sep 29 18:42:06 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 29 Sep 2022 18:42:06 GMT Subject: RFR: 1452: Can never notify on first commit Message-ID: I changed the logic when there is no notify history. Originally, on the first commit of a new repo, the bot would find no notify history, so it will make the first commit as an initial state and it will not make any notification. Now, on the first commit of a new repo, the bot would find no notify history too, but it will make the initial git hash as the initial state of the repo, so it will treat the first commit as an 'update' operation and will make notifications. ------------- Commit messages: - Will nofity on first commit Changes: https://git.openjdk.org/skara/pull/1385/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1385&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1452 Stats: 190 lines in 4 files changed: 126 ins; 5 del; 59 mod Patch: https://git.openjdk.org/skara/pull/1385.diff Fetch: git fetch https://git.openjdk.org/skara pull/1385/head:pull/1385 PR: https://git.openjdk.org/skara/pull/1385 From duke at openjdk.org Thu Sep 29 22:02:22 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 29 Sep 2022 22:02:22 GMT Subject: RFR: 1452: Can never notify on first commit [v2] In-Reply-To: References: Message-ID: > I changed the logic when there is no notify history. > > Originally, on the first commit of a new repo, the bot would find no notify history, so it will make the first commit as an initial state and it will not make any notification. > > Now, on the first commit of a new repo, the bot would find no notify history too, but it will make the initial git hash as the initial state of the repo, so it will treat the first commit as an 'update' operation and will make notifications. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix some bugs in MailingListNotifierTests ------------- Changes: - all: https://git.openjdk.org/skara/pull/1385/files - new: https://git.openjdk.org/skara/pull/1385/files/9c637fc3..f5397b99 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1385&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1385&range=00-01 Stats: 127 lines in 1 file changed: 9 ins; 93 del; 25 mod Patch: https://git.openjdk.org/skara/pull/1385.diff Fetch: git fetch https://git.openjdk.org/skara pull/1385/head:pull/1385 PR: https://git.openjdk.org/skara/pull/1385 From duke at openjdk.org Thu Sep 29 23:19:23 2022 From: duke at openjdk.org (Zhao Song) Date: Thu, 29 Sep 2022 23:19:23 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed Message-ID: Do not update comment if the comment already exists. ------------- Commit messages: - do not update comment if the comment already exists Changes: https://git.openjdk.org/skara/pull/1386/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1386&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1563 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1386.diff Fetch: git fetch https://git.openjdk.org/skara pull/1386/head:pull/1386 PR: https://git.openjdk.org/skara/pull/1386 From gli at openjdk.org Fri Sep 30 11:13:23 2022 From: gli at openjdk.org (Guoxiong Li) Date: Fri, 30 Sep 2022 11:13:23 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed In-Reply-To: References: Message-ID: On Thu, 29 Sep 2022 23:14:49 GMT, Zhao Song wrote: > Do not update comment if the comment already exists. Please note: the update action not only occurs when the pull request toggle between `ready` and `not ready`. The comment will change when the methods `getMergeReadyComment` and `getMergeNoLongerReadyComment` are revised. And the method `getMergeReadyComment` may return different results when it is invoked multi-times. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 935: > 933: } else { > 934: log.info("Updating merge ready comment"); > 935: pr.updateComment(existing.get().id(), message); This update action needs to be adjusted too. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 944: > 942: } else { > 943: log.info("No longer ready comment already exists, no need to update the comment"); > 944: } The logs should reflect that the existing comment is not equal to the new comment. Because we may change the content of the `no longer ready comment` or the `merge ready comment` in the future. Then the `pr.updateComment` is invoked, but it is not because of `Updating merge ready comment as no longer ready`. ------------- Changes requested by gli (Committer). PR: https://git.openjdk.org/skara/pull/1386 From duke at openjdk.org Fri Sep 30 15:53:51 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 15:53:51 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed In-Reply-To: References: Message-ID: <7gJTN57wnFbJD6UjDCwC9v72_j2Op3Nn5Gnox2vwp7A=.92c2981b-1ec9-47ed-abc1-1ec18ac31536@github.com> On Fri, 30 Sep 2022 10:50:25 GMT, Guoxiong Li wrote: > This update action needs to be adjusted too. Yes, It's my bad, did not read the logic of if condition carefully. Thanks for your correction! I will fix it. ------------- PR: https://git.openjdk.org/skara/pull/1386 From duke at openjdk.org Fri Sep 30 15:58:23 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 15:58:23 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 11:01:42 GMT, Guoxiong Li wrote: > The logs should reflect that the existing comment is not equal to the new comment. Because we may change the content of the `no longer ready comment` or the `merge ready comment` in the future. Then the `pr.updateComment` is invoked, but it is not because of `Updating merge ready comment as no longer ready`. Got it! Thanks! ------------- PR: https://git.openjdk.org/skara/pull/1386 From duke at openjdk.org Fri Sep 30 16:12:09 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 16:12:09 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed [v2] In-Reply-To: References: Message-ID: > Do not update comment if the comment already exists. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Adjusted anonther update method in CheckRun#updateMergeReadyComment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1386/files - new: https://git.openjdk.org/skara/pull/1386/files/f17c80da..6a4c1f28 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1386&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1386&range=00-01 Stats: 10 lines in 1 file changed: 4 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1386.diff Fetch: git fetch https://git.openjdk.org/skara pull/1386/head:pull/1386 PR: https://git.openjdk.org/skara/pull/1386 From duke at openjdk.org Fri Sep 30 19:05:29 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 19:05:29 GMT Subject: RFR: 1563: The method 'CheckRun#updateMergeReadyComment' shouldn't update the comment if the comment has not changed [v3] In-Reply-To: References: Message-ID: > Do not update comment if the comment already exists. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: dummy commit to see whether the macOS test fail is occasional ------------- Changes: - all: https://git.openjdk.org/skara/pull/1386/files - new: https://git.openjdk.org/skara/pull/1386/files/6a4c1f28..3021e803 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1386&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1386&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1386.diff Fetch: git fetch https://git.openjdk.org/skara pull/1386/head:pull/1386 PR: https://git.openjdk.org/skara/pull/1386 From duke at openjdk.org Fri Sep 30 20:26:05 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 20:26:05 GMT Subject: RFR: 1603: Make labels handling consistent in all Issue implementations Message-ID: Make TestIssue and JiraIssue update the cache when updating labels. ------------- Commit messages: - Make TestIssue and JiraIssue update the cache when updating labels Changes: https://git.openjdk.org/skara/pull/1387/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1387&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1603 Stats: 23 lines in 2 files changed: 17 ins; 0 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1387.diff Fetch: git fetch https://git.openjdk.org/skara pull/1387/head:pull/1387 PR: https://git.openjdk.org/skara/pull/1387 From duke at openjdk.org Fri Sep 30 20:26:24 2022 From: duke at openjdk.org (Zhao Song) Date: Fri, 30 Sep 2022 20:26:24 GMT Subject: RFR: 1603: Make labels handling consistent in all Issue implementations In-Reply-To: References: Message-ID: On Fri, 30 Sep 2022 20:18:42 GMT, Zhao Song wrote: > Make TestIssue and JiraIssue update the cache when updating labels. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 306: > 304: .map(s -> new Label(s.asString())) > 305: .collect(Collectors.toList()); > 306: } I tried to just update the labels but I could not make it. So I update the json first and then update the labels. ------------- PR: https://git.openjdk.org/skara/pull/1387