From zsong at openjdk.org  Wed Feb  1 21:02:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 1 Feb 2023 21:02:23 GMT
Subject: RFR: 1797: Add support for /backport pull request command
Message-ID: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>

This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)

Usage of /backport in pull request:

Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)

1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

-------------

Commit messages:
 - fix test
 - SKARA-1797

Changes: https://git.openjdk.org/skara/pull/1466/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1797
  Stats: 299 lines in 5 files changed: 284 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From erikj at openjdk.org  Wed Feb  1 22:34:12 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Feb 2023 22:34:12 GMT
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>

On Wed, 1 Feb 2023 20:38:53 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

I had forgotten about the support for /backport command on closed PRs, good that you found that. I'm also happily surprised at how easy it was to add processing of the label in the `IntegrateCommand`. It looks like that will work robustly as commands are always processed in order. I added some comments and suggestions.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 47:

> 45: 
> 46:     private void showHelpInPR(PrintWriter reply) {
> 47:         reply.println("Usage: `/backport <repository> [<branch>]` `/backport disable <repository> [<branch>]`");

Suggestion:

        reply.println("Usage: `/backport [disable] <repository> [<branch>]`");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 66:

> 64: 
> 65:     @Override
> 66:     public void handle(PullRequestBot bot, PullRequest pr, CensusInstance censusInstance, Path scratchPath, CommandInvocation command, List<Comment> allComments, PrintWriter reply, List<String> labelsToAdd, List<String> labelsToRemove) {

Please break up this line.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 73:

> 71: 
> 72:         if (pr.isClosed() && !pr.labelNames().contains("integrated")) {
> 73:             reply.println("`/backport` command can not be used in closed but not integrated PR");

Suggestion:

            reply.println("`/backport` command can not be used in a closed but not integrated pull request");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 99:

> 97:                 reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was successfully disabled.");
> 98:             } else {
> 99:                 reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was not enabled, so you can not disable it.");

Suggestion:

                reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was already disabled.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 133:

> 131:                 reply.println("The target branch `" + targetBranchName + "` does not exist");
> 132:                 return;
> 133:             }

This looks like it has been copied from the other method. Would be better to break it out into methods and reused.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 140:

> 138:                 labelsToAdd.add(backportLabel);
> 139:                 reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was successfully enabled.");
> 140:                 reply.println("Please note that instructions for creating backports will be provided once this PR is integrated.");

Suggestion:

                reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was successfully enabled and will be performed once this pull request has been integrated.");
                reply.println(" Further instructions will be provided at that time.");

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 208:

> 206:             var botComment = allComments.stream()
> 207:                     .filter(comment -> comment.author().equals(bot.repo().forge().currentUser()))
> 208:                     .filter(comment -> comment.body().contains("Backport for repo `" + repoName + "` on branch `" + targetBranchName + "` was successfully enabled."))

Instead of parsing the human readable message, I would recommend encoding a more structured data entry in an html comment. That will be easier to parse and less sensitive to future changes of this code. There should be several similar examples of that throughout the bots.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 246:

> 244:                 addPrePushComment(pr, amendedHash, rebaseMessage.toString());
> 245:                 localRepo.push(amendedHash, pr.repository().url(), pr.targetRef());
> 246:                 processBackportLabel(pr, allComments);

I think this call should be moved to the top of `markIntegratedAndClosed`. Otherwise, if the bot is interrupted just after line 245, then the next attempt at running `IntegrateCommand` will jump straight into `markIntegratedAndClosed` and skip the backport processing.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 340:

> 338:                 var text = "Creating backport for repo " + repoName + " on branch " + branchName
> 339:                         + "\n<!--\n /backport " + repoName + " " + branchName + "\n-->" + "\n"
> 340:                         + PullRequestCommandWorkItem.VALID_BOT_COMMAND_MARKER;

In `CheckWorkItem`, when adding `/integrate` based on an earlier `/integrate auto`, we don't hide the command. I think we should be consistent and not hide it here either.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Wed Feb  1 22:43:45 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 1 Feb 2023 22:43:45 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v2]
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <_R9Qy_Q_RW3i7q6YAiM07JxXm9ekaTKrbLFC6uj2NVM=.1041eaf7-e3dc-4bad-a114-2004cf885399@github.com>

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

Zhao Song has updated the pull request incrementally with four additional commits since the last revision:

 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1466/files
  - new: https://git.openjdk.org/skara/pull/1466/files/4af54f93..8e6feb06

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Wed Feb  1 22:43:46 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 1 Feb 2023 22:43:46 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v2]
In-Reply-To: <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
Message-ID: <ABXQSnkCqoIFYYvNCpiY1S1QOoiN3Qlo0nnfxY9q9ZE=.d7feea14-031c-4342-91ba-58883201ee69@github.com>

On Wed, 1 Feb 2023 22:06:27 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 133:
> 
>> 131:                 reply.println("The target branch `" + targetBranchName + "` does not exist");
>> 132:                 return;
>> 133:             }
> 
> This looks like it has been copied from the other method. Would be better to break it out into methods and reused.

Yes, It's copied from the other method. I tried to extract the code into a method but found it's complex. I will have a try later.

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 208:
> 
>> 206:             var botComment = allComments.stream()
>> 207:                     .filter(comment -> comment.author().equals(bot.repo().forge().currentUser()))
>> 208:                     .filter(comment -> comment.body().contains("Backport for repo `" + repoName + "` on branch `" + targetBranchName + "` was successfully enabled."))
> 
> Instead of parsing the human readable message, I would recommend encoding a more structured data entry in an html comment. That will be easier to parse and less sensitive to future changes of this code. There should be several similar examples of that throughout the bots.

Sure. Will fix it

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 340:
> 
>> 338:                 var text = "Creating backport for repo " + repoName + " on branch " + branchName
>> 339:                         + "\n<!--\n /backport " + repoName + " " + branchName + "\n-->" + "\n"
>> 340:                         + PullRequestCommandWorkItem.VALID_BOT_COMMAND_MARKER;
> 
> In `CheckWorkItem`, when adding `/integrate` based on an earlier `/integrate auto`, we don't hide the command. I think we should be consistent and not hide it here either.

Sure

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Wed Feb  1 22:48:42 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 1 Feb 2023 22:48:42 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v2]
In-Reply-To: <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
Message-ID: <tOzuWUhg8H-s3GXG9M4liS-3PwYyB6KlUJAzgoz4Sdg=.9f0d433b-5e48-4578-a975-53c66798093c@github.com>

On Wed, 1 Feb 2023 22:27:50 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>>  - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
>>    
>>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 246:
> 
>> 244:                 addPrePushComment(pr, amendedHash, rebaseMessage.toString());
>> 245:                 localRepo.push(amendedHash, pr.repository().url(), pr.targetRef());
>> 246:                 processBackportLabel(pr, allComments);
> 
> I think this call should be moved to the top of `markIntegratedAndClosed`. Otherwise, if the bot is interrupted just after line 245, then the next attempt at running `IntegrateCommand` will jump straight into `markIntegratedAndClosed` and skip the backport processing.

I thought of this and call `processBackportLabel` before every `markIntegratedAndClosed` call, so I think the backport processing would not be skipped in any case. But put this method in `markIntegratedAndClosed` is still a good idea. I will do it.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Thu Feb  2 00:14:38 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 2 Feb 2023 00:14:38 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v3]
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <QOl9gcZUsx7xkf4MLRJoDW0HIjFwO6wn_qDX6jA7HHM=.01195016-57a7-47a1-812f-53be76e5f539@github.com>

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

Zhao Song has updated the pull request incrementally with two additional commits since the last revision:

 - fix test
 - fix issues

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1466/files
  - new: https://git.openjdk.org/skara/pull/1466/files/8e6feb06..26b9e7d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=01-02

  Stats: 147 lines in 5 files changed: 68 ins; 43 del; 36 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From david.holmes at oracle.com  Thu Feb  2 07:08:49 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 2 Feb 2023 17:08:49 +1000
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>

On 2/02/2023 7:02 am, Zhao Song wrote:
> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.

This does not sound desirable. Fixes should undergo some bake time in 
the primary repo before they get backported anywhere. With the current 
situation it is up to the person doing the backport to go to the commit 
in question and know that the commit has been suitable tested/baked.

David
-----

> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.
> 
> -------------
> 
> Commit messages:
>   - fix test
>   - SKARA-1797
> 
> Changes: https://git.openjdk.org/skara/pull/1466/files
>   Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=00
>    Issue: https://bugs.openjdk.org/browse/SKARA-1797
>    Stats: 299 lines in 5 files changed: 284 ins; 3 del; 12 mod
>    Patch: https://git.openjdk.org/skara/pull/1466.diff
>    Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466
> 
> PR: https://git.openjdk.org/skara/pull/1466

From thomas.stuefe at gmail.com  Thu Feb  2 08:28:50 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 2 Feb 2023 09:28:50 +0100
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
Message-ID: <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>

>
> > 1. If the `/backport` command is used in an **open** pull request, it
> adds a label `Backport=repo:branch` to the PR. If the PR is later
> integrated, the PR bot scans for backport labels and begins the backporting
> process. To cancel the backport, the user can use `/backport disable repo
> master` to remove the label before the PR is integrated.
>
> This does not sound desirable. Fixes should undergo some bake time in
> the primary repo before they get backported anywhere. With the current
> situation it is up to the person doing the backport to go to the commit
> in question and know that the commit has been suitable tested/baked.
>
> David
> -----
>
>
I agree with David. Making it easy to downport fresh changes right away is
not something we should encourage.

Yes, there are cases of super-simple fixes that can be backported right
away. But those are the exception. Update releases are *maintenance*
releases with a much larger customer surface than the head release. If
something goes wrong, the impact is large and immediate.

But we only have limited testing resources for update releases. We do our
best, but the mainline is still much better tested. We live with that; we
assume that backports have been exposed in the mainline repo long enough
for issues to surface. Immediate backporting breaks this assumption.

Cheers, Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230202/cfa3c7fb/attachment.htm>

From erik.helin at oracle.com  Thu Feb  2 11:33:44 2023
From: erik.helin at oracle.com (Erik Duveblad)
Date: Thu, 2 Feb 2023 11:33:44 +0000
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
Message-ID: <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>

> On 2 Feb 2023, at 09:28, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> 
> > 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 
> This does not sound desirable. Fixes should undergo some bake time in 
> the primary repo before they get backported anywhere. With the current 
> situation it is up to the person doing the backport to go to the commit 
> in question and know that the commit has been suitable tested/baked.
> 
> David
> -----
> 
> 
> I agree with David. Making it easy to downport fresh changes right away is not something we should encourage.

Please do not jump to conclusions about what Zhao is proposing without understanding the patch :) Zhao?s patch is only making it easier to create a backport _pull request_, it will not automatically create any backport commits.

A user can already today type `/backport` in a commit comment for the commit a pull request resulted in once it was integrated. This can be done only seconds after the pull request was integrated and the Skara bots will then go ahead and create a ?backport pull request? (see the Skara wiki on backports for more details [0]). Zhao?s patch only removes the manual step of having to navigate to the GitHub page for the resulting commit and add a commit comment. With Zhao?s patch a user can now instead type `/backport` in the pull request and the Skara bots will create the ?backport pull request? once the pull request has been integrated.

So, this patch is not creating any new workflows, it is just removing a couple of manual steps needed today to create a "backport pull request". The "backport pull request" should of course not be integrated until the commit in mainline has received proper ?soak time? and testing.

Thanks,
Erik

[0]: https://wiki.openjdk.org/display/SKARA/Backports


From ehelin at openjdk.org  Thu Feb  2 11:41:02 2023
From: ehelin at openjdk.org (Erik Helin)
Date: Thu, 2 Feb 2023 11:41:02 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v3]
In-Reply-To: <QOl9gcZUsx7xkf4MLRJoDW0HIjFwO6wn_qDX6jA7HHM=.01195016-57a7-47a1-812f-53be76e5f539@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <QOl9gcZUsx7xkf4MLRJoDW0HIjFwO6wn_qDX6jA7HHM=.01195016-57a7-47a1-812f-53be76e5f539@github.com>
Message-ID: <R6TeIt0gwTqImZP7HDQwQj8YuanDc2N9Kv_LSmcrAJc=.861c34b8-67dd-4f1a-93c3-01ae512e20e6@github.com>

On Thu, 2 Feb 2023 00:14:38 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
>> 
>> Usage of /backport in pull request:
>> 
>> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
>> 
>> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
>> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
>> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix test
>  - fix issues

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 132:

> 130: 
> 131:     private String generateBackportLabel(String targetRepo, String targetBranchName) {
> 132:         return "Backport=" + targetRepo + ":" + targetBranchName;

I think all of the labels we use for OpenJDK use only lowercase, so I would suggest using `backport=<repo>:<branch>` for the labels.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From thomas.stuefe at gmail.com  Thu Feb  2 13:30:27 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 2 Feb 2023 14:30:27 +0100
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
Message-ID: <CAA-vtUxcNwPOZDVt5RhnmA05BPg7fyz8-oQ3jG5ey20rxWKybw@mail.gmail.com>

Hi Erik :)

On Thu, Feb 2, 2023 at 12:33 PM Erik Duveblad <erik.helin at oracle.com> wrote:

> > On 2 Feb 2023, at 09:28, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
> >
> > > 1. If the `/backport` command is used in an **open** pull request, it
> adds a label `Backport=repo:branch` to the PR. If the PR is later
> integrated, the PR bot scans for backport labels and begins the backporting
> process. To cancel the backport, the user can use `/backport disable repo
> master` to remove the label before the PR is integrated.
> >
> > This does not sound desirable. Fixes should undergo some bake time in
> > the primary repo before they get backported anywhere. With the current
> > situation it is up to the person doing the backport to go to the commit
> > in question and know that the commit has been suitable tested/baked.
> >
> > David
> > -----
> >
> >
> > I agree with David. Making it easy to downport fresh changes right away
> is not something we should encourage.
>
> Please do not jump to conclusions about what Zhao is proposing without
> understanding the patch :) Zhao?s patch is only making it easier to create
> a backport _pull request_, it will not automatically create any backport
> commits.
>
> A user can already today type `/backport` in a commit comment for the
> commit a pull request resulted in once it was integrated. This can be done
> only seconds after the pull request was integrated and the Skara bots will
> then go ahead and create a ?backport pull request? (see the Skara wiki on
> backports for more details [0]). Zhao?s patch only removes the manual step
> of having to navigate to the GitHub page for the resulting commit and add a
> commit comment. With Zhao?s patch a user can now instead type `/backport`
> in the pull request and the Skara bots will create the ?backport pull
> request? once the pull request has been integrated.
>
> So, this patch is not creating any new workflows, it is just removing a
> couple of manual steps needed today to create a "backport pull request".
> The "backport pull request" should of course not be integrated until the
> commit in mainline has received proper ?soak time? and testing.
>
>
Sure, I got all that.

But auto-creating a backport branch (and the backport PR too?) after a
patch had been committed makes only sense if you plan to push the backport
in the immediate future. Because if you don't, if you let it sit for a
month, the backport branch will be stale. Even if the stale branch is still
mergeable, one should still rebase it to the top of the backport repo in
order to test it correctly. Since the backport repo may have changed in the
meantime and may now be incompatible with your patch, even though the patch
is technically mergeable.

And my point was that this should be quite rare, and limited to very
important or very simple patches. So simplifying this process may be an
indication that we do something often that we should not do often.

But I don't oppose this change if you think it is fine.

Cheers, Thomas

p.s. there is one detail I did not understand:

"With Zhao?s patch a user can now instead type `/backport` in the pull
request and the Skara bots will create the ?backport pull request? once the
pull request has been integrated."

Today, /backport does not create a pull request, or? It only creates the
backport branch; the pull request creation is still a manual step - either
a button press or a manual process via git. So, will /backport in an open
PR behave differently from that and create the PR right away?


> Thanks,
> Erik
>
> [0]: https://wiki.openjdk.org/display/SKARA/Backports
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230202/5eaa4152/attachment.htm>

From erik.joelsson at oracle.com  Thu Feb  2 14:00:34 2023
From: erik.joelsson at oracle.com (erik.joelsson at oracle.com)
Date: Thu, 2 Feb 2023 06:00:34 -0800
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <CAA-vtUxcNwPOZDVt5RhnmA05BPg7fyz8-oQ3jG5ey20rxWKybw@mail.gmail.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
 <CAA-vtUxcNwPOZDVt5RhnmA05BPg7fyz8-oQ3jG5ey20rxWKybw@mail.gmail.com>
Message-ID: <7c69f3fb-79cb-7143-86f9-4f47d7c44be5@oracle.com>

On 2/2/23 05:30, Thomas St?fe wrote:
> Hi Erik :)
>
> p.s. there is one detail I did not understand:
>
> "With Zhao?s patch a user can now instead type `/backport` in the pull 
> request and the Skara bots will create the ?backport pull request? 
> once the pull request has been integrated."
>
> Today, /backport does not create a pull request, or? It only creates 
> the backport branch; the pull request creation is still a manual step 
> - either a button press or a manual process via git. So, will 
> /backport in an open PR behave differently from that and create the PR 
> right away?

You are correct, the `/backport` command only creates the branch and 
provides a link for creating the backport. That isn't changing. When 
issuing `/backport` in a pull request the difference is that the link 
appears as a comment on the pull request instead of the commit.

Another aspect of this change is that the author can use it to declare 
their intent of backporting the change to a certain release, which 
reviewers have the opportunity to respond to directly in the current review.

/Erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230202/251342cd/attachment-0001.htm>

From thomas.stuefe at gmail.com  Thu Feb  2 14:05:47 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Thu, 2 Feb 2023 15:05:47 +0100
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <7c69f3fb-79cb-7143-86f9-4f47d7c44be5@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
 <CAA-vtUxcNwPOZDVt5RhnmA05BPg7fyz8-oQ3jG5ey20rxWKybw@mail.gmail.com>
 <7c69f3fb-79cb-7143-86f9-4f47d7c44be5@oracle.com>
Message-ID: <CAA-vtUy1LvqFbSCVQmdiOb8WoyK4g+jOw2fSFNTiYKa8yAKqgQ@mail.gmail.com>

On Thu, Feb 2, 2023 at 3:00 PM <erik.joelsson at oracle.com> wrote:

> On 2/2/23 05:30, Thomas St?fe wrote:
>
> Hi Erik :)
>
> p.s. there is one detail I did not understand:
>
> "With Zhao?s patch a user can now instead type `/backport` in the pull
> request and the Skara bots will create the ?backport pull request? once the
> pull request has been integrated."
>
> Today, /backport does not create a pull request, or? It only creates the
> backport branch; the pull request creation is still a manual step - either
> a button press or a manual process via git. So, will /backport in an open
> PR behave differently from that and create the PR right away?
>
> You are correct, the `/backport` command only creates the branch and
> provides a link for creating the backport. That isn't changing. When
> issuing `/backport` in a pull request the difference is that the link
> appears as a comment on the pull request instead of the commit.
>

Thanks for clarifying!

> Another aspect of this change is that the author can use it to declare
> their intent of backporting the change to a certain release, which
> reviewers have the opportunity to respond to directly in the current review.
>

Okay, this could be useful. Especially if Reviewers don't monitor the
updates ML.


> /Erik
>

..Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230202/73e6a98b/attachment.htm>

From zsong at openjdk.org  Thu Feb  2 16:51:59 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 2 Feb 2023 16:51:59 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v3]
In-Reply-To: <R6TeIt0gwTqImZP7HDQwQj8YuanDc2N9Kv_LSmcrAJc=.861c34b8-67dd-4f1a-93c3-01ae512e20e6@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <QOl9gcZUsx7xkf4MLRJoDW0HIjFwO6wn_qDX6jA7HHM=.01195016-57a7-47a1-812f-53be76e5f539@github.com>
 <R6TeIt0gwTqImZP7HDQwQj8YuanDc2N9Kv_LSmcrAJc=.861c34b8-67dd-4f1a-93c3-01ae512e20e6@github.com>
Message-ID: <3PBvvnGInGn3kPqesfXObOSHLoH6bvn9vstKu1I9oQg=.1f43fa39-cf6d-4bbf-aca9-d118eb2cf928@github.com>

On Thu, 2 Feb 2023 11:38:40 GMT, Erik Helin <ehelin at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix test
>>  - fix issues
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 132:
> 
>> 130: 
>> 131:     private String generateBackportLabel(String targetRepo, String targetBranchName) {
>> 132:         return "Backport=" + targetRepo + ":" + targetBranchName;
> 
> I think all of the labels we use for OpenJDK use only lowercase, so I would suggest using `backport=<repo>:<branch>` for the labels.

Thanks for the advice!  I will change it to lowercase.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Thu Feb  2 17:04:31 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 2 Feb 2023 17:04:31 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v4]
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <ctJQcJ_jKyu7zKh8Eycdy89CPlhGeRnnSUB1XSzIU34=.24362a38-afce-46fa-9258-6dac1e1aacb3@github.com>

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  change backport label to lowercase

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1466/files
  - new: https://git.openjdk.org/skara/pull/1466/files/26b9e7d9..65a75740

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=02-03

  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From david.holmes at oracle.com  Fri Feb  3 01:48:25 2023
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 3 Feb 2023 11:48:25 +1000
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
Message-ID: <d2da8d97-9c9a-78e9-185b-f96fdc4da16a@oracle.com>

On 2/02/2023 9:33 pm, Erik Duveblad wrote:
>> On 2 Feb 2023, at 09:28, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>
>>> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels and begins the backporting process. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
>>
>> This does not sound desirable. Fixes should undergo some bake time in
>> the primary repo before they get backported anywhere. With the current
>> situation it is up to the person doing the backport to go to the commit
>> in question and know that the commit has been suitable tested/baked.
>>
>> David
>> -----
>>
>>
>> I agree with David. Making it easy to downport fresh changes right away is not something we should encourage.
> 
> Please do not jump to conclusions about what Zhao is proposing without understanding the patch :) Zhao?s patch is only making it easier to create a backport _pull request_, it will not automatically create any backport commits.

Okay I misconstrued what "begins the backporting process" actually 
meant. Sorry for the false alarm.

> A user can already today type `/backport` in a commit comment for
> the commit a pull request resulted in once it was integrated. This can be
> done only seconds after the pull request was integrated and the Skara
> bots will then go ahead and create a ?backport pull request? (see the
> Skara wiki on backports for more details [0]). Zhao?s patch only removes
> the manual step of having to navigate to the GitHub page for the
> resulting commit and add a commit comment. With Zhao?s patch a user can
> now instead type `/backport` in the pull request and the Skara bots will
> create the ?backport pull request? once the pull request has been
>integrated.

Sure. And I understand better this isn't really trying to allow (though 
it does) the ability to type:

/integrate
/backport ...

in a PR but more dealing with the common(?) problem that when someone 
does decide to backport a change they tend to go to the JBS issue, see 
the PR link, go to the PR and type "/backport ..." only to be told they 
are in the wrong place and need to go to the commit. I know I've done it 
myself :)

Cheers,
David
-----

> 
> So, this patch is not creating any new workflows, it is just removing a couple of manual steps needed today to create a "backport pull request". The "backport pull request" should of course not be integrated until the commit in mainline has received proper ?soak time? and testing.
> 
> Thanks,
> Erik
> 
> [0]: https://wiki.openjdk.org/display/SKARA/Backports
> 

From david.holmes at oracle.com  Fri Feb  3 02:09:34 2023
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 3 Feb 2023 12:09:34 +1000
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <d2da8d97-9c9a-78e9-185b-f96fdc4da16a@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
 <d2da8d97-9c9a-78e9-185b-f96fdc4da16a@oracle.com>
Message-ID: <fe90d6df-a2b7-5acb-a652-5f18bb559e19@oracle.com>

On 3/02/2023 11:48 am, David Holmes wrote:
> On 2/02/2023 9:33 pm, Erik Duveblad wrote:
>>> On 2 Feb 2023, at 09:28, Thomas St?fe <thomas.stuefe at gmail.com> wrote:
>>>
>>>> 1. If the `/backport` command is used in an **open** pull request, 
>>>> it adds a label `Backport=repo:branch` to the PR. If the PR is later 
>>>> integrated, the PR bot scans for backport labels and begins the 
>>>> backporting process. To cancel the backport, the user can use 
>>>> `/backport disable repo master` to remove the label before the PR is 
>>>> integrated.
>>>
>>> This does not sound desirable. Fixes should undergo some bake time in
>>> the primary repo before they get backported anywhere. With the current
>>> situation it is up to the person doing the backport to go to the commit
>>> in question and know that the commit has been suitable tested/baked.
>>>
>>> David
>>> -----
>>>
>>>
>>> I agree with David. Making it easy to downport fresh changes right 
>>> away is not something we should encourage.
>>
>> Please do not jump to conclusions about what Zhao is proposing without 
>> understanding the patch :) Zhao?s patch is only making it easier to 
>> create a backport _pull request_, it will not automatically create any 
>> backport commits.
> 
> Okay I misconstrued what "begins the backporting process" actually 
> meant. Sorry for the false alarm.
> 
>> A user can already today type `/backport` in a commit comment for
>> the commit a pull request resulted in once it was integrated. This can be
>> done only seconds after the pull request was integrated and the Skara
>> bots will then go ahead and create a ?backport pull request? (see the
>> Skara wiki on backports for more details [0]). Zhao?s patch only removes
>> the manual step of having to navigate to the GitHub page for the
>> resulting commit and add a commit comment. With Zhao?s patch a user can
>> now instead type `/backport` in the pull request and the Skara bots will
>> create the ?backport pull request? once the pull request has been
>> integrated.
> 
> Sure. And I understand better this isn't really trying to allow (though 
> it does) the ability to type:
> 
> /integrate
> /backport ...
> 
> in a PR but more dealing with the common(?) problem that when someone 
> does decide to backport a change they tend to go to the JBS issue, see 
> the PR link, go to the PR and type "/backport ..." only to be told they 
> are in the wrong place and need to go to the commit. I know I've done it 
> myself :)

Though that said, there really isn't any motivating usecase I can see 
for allowing /backport in an open PR.

David

> Cheers,
> David
> -----
> 
>>
>> So, this patch is not creating any new workflows, it is just removing 
>> a couple of manual steps needed today to create a "backport pull 
>> request". The "backport pull request" should of course not be 
>> integrated until the commit in mainline has received proper ?soak 
>> time? and testing.
>>
>> Thanks,
>> Erik
>>
>> [0]: https://wiki.openjdk.org/display/SKARA/Backports
>>

From erik.helin at oracle.com  Fri Feb  3 10:19:52 2023
From: erik.helin at oracle.com (Erik Duveblad)
Date: Fri, 3 Feb 2023 10:19:52 +0000
Subject: RFR: 1797: Add support for /backport pull request command
In-Reply-To: <fe90d6df-a2b7-5acb-a652-5f18bb559e19@oracle.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <f3396cf9-d941-0860-2fca-d25c08c740af@oracle.com>
 <CAA-vtUxii8dcCLOWQrD2cbZWPAuV45NDtioDCE3KoTchnEqWfQ@mail.gmail.com>
 <ED803E70-1D83-47E7-A064-C6F52DD8727B@oracle.com>
 <d2da8d97-9c9a-78e9-185b-f96fdc4da16a@oracle.com>
 <fe90d6df-a2b7-5acb-a652-5f18bb559e19@oracle.com>
Message-ID: <9B4E4C25-9DA7-46A1-A306-482DB03413AE@oracle.com>

> On 3 Feb 2023, at 03:09, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 3/02/2023 11:48 am, David Holmes wrote:
>> On 2/02/2023 9:33 pm, Erik Duveblad wrote:
>>> 
>>> A user can already today type `/backport` in a commit comment for
>>> the commit a pull request resulted in once it was integrated. This can be
>>> done only seconds after the pull request was integrated and the Skara
>>> bots will then go ahead and create a ?backport pull request? (see the
>>> Skara wiki on backports for more details [0]). Zhao?s patch only removes
>>> the manual step of having to navigate to the GitHub page for the
>>> resulting commit and add a commit comment. With Zhao?s patch a user can
>>> now instead type `/backport` in the pull request and the Skara bots will
>>> create the ?backport pull request? once the pull request has been
>>> integrated.
>> Sure. And I understand better this isn't really trying to allow (though it does) the ability to type:
>> /integrate
>> /backport ...
>> in a PR but more dealing with the common(?) problem that when someone does decide to backport a change they tend to go to the JBS issue, see the PR link, go to the PR and type "/backport ..." only to be told they are in the wrong place and need to go to the commit. I know I've done it myself :)
> 
> Though that said, there really isn't any motivating usecase I can see for allowing /backport in an open PR.

I agree with what Erik J wrote on this and see three primary motivations:

1. You signal to reviewers of the PR that you intend to backport this PR. This can be useful information to the people reviewing the change in the openjdk/jdk repository. It can also be a useful heads up to the maintainers of the repository you intend to backport to, many of those maintainers are also following pull requests targeting openjdk/jdk:master.

2. It is convenient if I _know_ already when creating the PR in the first place that I will backport this later. I can just add the `/backport` command in the PR body, let the reviews process run its course, let the resulting commit soak for a while. Then I can come back to the PR (for example via the link in the JBS issue) and just click the link that the bots have already prepared for me.

3. In the case of 2), some contributors might actually prefer to create the ?backport pull request? early, as a way to remember to complete the backport at some time in the future (the ?backport pull request? will be assigned to your GitHub user). Such contributors must of course do as Thomas wrote and update their ?backport pull request? with the latest changes before integration, but it is still a scenario I think we should support. Creating a ?backport pull request? somewhat early is also yet another signal to maintainers of that release that ?this is coming?, even though it is not ready just yet.

I personally think the three motivations outlined above is more than enough to support `/backport` in an open pull request, primarily as I can?t see any drawbacks. The only drawback I can imagine would be ?trigger happy? contributors who might backport right away, but as I wrote earlier, that ?problem? (which we?ve never run into AFAIK) can already happen today: a user just have to add the `/backport` _commit_ command to the commit the PR resulted in as soon as it has been created.

Thanks,
Erik

From erikj at openjdk.org  Mon Feb  6 21:14:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 6 Feb 2023 21:14:16 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v4]
In-Reply-To: <ctJQcJ_jKyu7zKh8Eycdy89CPlhGeRnnSUB1XSzIU34=.24362a38-afce-46fa-9258-6dac1e1aacb3@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <ctJQcJ_jKyu7zKh8Eycdy89CPlhGeRnnSUB1XSzIU34=.24362a38-afce-46fa-9258-6dac1e1aacb3@github.com>
Message-ID: <I-JpB1oqN3sHwXBCFIyxFsBGzwo5ZUo9LXkj8GzOzgo=.4776f663-b465-4b46-8303-9d4b5a496144@github.com>

On Thu, 2 Feb 2023 17:04:31 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
>> 
>> Usage of /backport in pull request:
>> 
>> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
>> 
>> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
>> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
>> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change backport label to lowercase

bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 125:

> 123:                 labelsToAdd.add(backportLabel);
> 124:                 reply.println("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was successfully enabled and will be performed once this pull request has been integrated.");
> 125:                 reply.println("Further instructions will be provided at that time.");

No need to post this with line breaks. Better to keep it to one paragraph.
Suggestion:

                reply.print("Backport for repo `" + targetRepoName + "` on branch `" + targetBranchName + "` was successfully enabled and will be performed once this pull request has been integrated.");
                reply.println(" Further instructions will be provided at that time.");

-------------

PR: https://git.openjdk.org/skara/pull/1466

From erikj at openjdk.org  Mon Feb  6 21:14:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 6 Feb 2023 21:14:16 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v4]
In-Reply-To: <ABXQSnkCqoIFYYvNCpiY1S1QOoiN3Qlo0nnfxY9q9ZE=.d7feea14-031c-4342-91ba-58883201ee69@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
 <ABXQSnkCqoIFYYvNCpiY1S1QOoiN3Qlo0nnfxY9q9ZE=.d7feea14-031c-4342-91ba-58883201ee69@github.com>
Message-ID: <jRLK3bcFYwD0NU3k0c6lOMfoxMXm0mwYUwi9bmx7aoo=.72c1036c-df7e-4ae1-928e-7f5f4d0fd575@github.com>

On Wed, 1 Feb 2023 22:39:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java line 208:
>> 
>>> 206:             var botComment = allComments.stream()
>>> 207:                     .filter(comment -> comment.author().equals(bot.repo().forge().currentUser()))
>>> 208:                     .filter(comment -> comment.body().contains("Backport for repo `" + repoName + "` on branch `" + targetBranchName + "` was successfully enabled."))
>> 
>> Instead of parsing the human readable message, I would recommend encoding a more structured data entry in an html comment. That will be easier to parse and less sensitive to future changes of this code. There should be several similar examples of that throughout the bots.
>
> Sure. Will fix it

I don't think you changed this.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Mon Feb  6 21:23:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 6 Feb 2023 21:23:53 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v5]
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <CPMIl50J2UbttE5LyljltXuTP5ogsHNf3Mt4UP9O6_U=.93ac1036-d8eb-4d68-8151-b7829d215714@github.com>

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/BackportCommand.java
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1466/files
  - new: https://git.openjdk.org/skara/pull/1466/files/65a75740..44943c37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=04
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Mon Feb  6 21:23:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 6 Feb 2023 21:23:53 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v5]
In-Reply-To: <jRLK3bcFYwD0NU3k0c6lOMfoxMXm0mwYUwi9bmx7aoo=.72c1036c-df7e-4ae1-928e-7f5f4d0fd575@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <Z47O_jw9TSZxvZugCJL8sNRFu5L0eKGZGjivtjKXDgs=.295ec808-f78e-40b0-b054-79caf3905e0d@github.com>
 <ABXQSnkCqoIFYYvNCpiY1S1QOoiN3Qlo0nnfxY9q9ZE=.d7feea14-031c-4342-91ba-58883201ee69@github.com>
 <jRLK3bcFYwD0NU3k0c6lOMfoxMXm0mwYUwi9bmx7aoo=.72c1036c-df7e-4ae1-928e-7f5f4d0fd575@github.com>
Message-ID: <kIPG2cWAWI5dmvJaGSc8FlQxTnSjfm_B11fF3szlcwY=.e5030ae2-01d6-45c7-be1f-426f90f150f2@github.com>

On Mon, 6 Feb 2023 21:11:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Sure. Will fix it
>
> I don't think you changed this.

Sorry, I misunderstood your advice. I will fix it again.

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Mon Feb  6 21:47:02 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 6 Feb 2023 21:47:02 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v6]
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <gcuZ3k5UYqxTwVwWXUiTXovEZG0thS7b6ShtwU03mzk=.3a92ad73-c2b3-498e-ad12-b57d53d167ef@github.com>

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix an issue

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1466/files
  - new: https://git.openjdk.org/skara/pull/1466/files/44943c37..9a1f8fd3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=05
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1466&range=04-05

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1466.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1466/head:pull/1466

PR: https://git.openjdk.org/skara/pull/1466

From erikj at openjdk.org  Mon Feb  6 22:14:00 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 6 Feb 2023 22:14:00 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v6]
In-Reply-To: <gcuZ3k5UYqxTwVwWXUiTXovEZG0thS7b6ShtwU03mzk=.3a92ad73-c2b3-498e-ad12-b57d53d167ef@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <gcuZ3k5UYqxTwVwWXUiTXovEZG0thS7b6ShtwU03mzk=.3a92ad73-c2b3-498e-ad12-b57d53d167ef@github.com>
Message-ID: <nGYDqkhkds5Zt02Axuxv_5Fv0aeDFk9b7kwd0G2hyEU=.6a5da7ee-0ee0-4466-a8cf-41830ab050f1@github.com>

On Mon, 6 Feb 2023 21:47:02 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
>> 
>> Usage of /backport in pull request:
>> 
>> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
>> 
>> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
>> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
>> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix an issue

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Mon Feb  6 22:29:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 6 Feb 2023 22:29:35 GMT
Subject: Integrated: 1797: Add support for /backport pull request command
In-Reply-To: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
Message-ID: <BwNPpKQfV1e-VbPYafyRcBTLvHVVe8QFZ_nyuCh0hUM=.4ad38b08-cdea-4ccd-8b19-82207be096a0@github.com>

On Wed, 1 Feb 2023 20:38:53 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
> 
> Usage of /backport in pull request:
> 
> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
> 
> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.

This pull request has now been integrated.

Changeset: 6b036dd7
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/6b036dd7d88f2cf445e3f0ab8fabab8d837572b8
Stats:     347 lines in 5 files changed: 309 ins; 2 del; 36 mod

1797: Add support for /backport pull request command

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1466

From zsong at openjdk.org  Mon Feb  6 22:29:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 6 Feb 2023 22:29:35 GMT
Subject: RFR: 1797: Add support for /backport pull request command [v6]
In-Reply-To: <gcuZ3k5UYqxTwVwWXUiTXovEZG0thS7b6ShtwU03mzk=.3a92ad73-c2b3-498e-ad12-b57d53d167ef@github.com>
References: <0hrPWYRsTvNNo6HhVFeEWQb5JKZHy4m0qnnUJ6au_Lw=.6bd5ade3-0f4f-4278-b086-02fc14d1719f@github.com>
 <gcuZ3k5UYqxTwVwWXUiTXovEZG0thS7b6ShtwU03mzk=.3a92ad73-c2b3-498e-ad12-b57d53d167ef@github.com>
Message-ID: <F2NdfjLrIN41Xtr4TzYRHhUfpxGtdN9OlbOYUTls97k=.f53e3345-b7f9-4d31-a92d-9c1b30b6fab5@github.com>

On Mon, 6 Feb 2023 21:47:02 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch introduces support for the /backport command in pull requests. (ErikJ and ErikH proposed the idea and came up with this implementation.)
>> 
>> Usage of /backport in pull request:
>> 
>> Syntax: `/backport <repo> [<branch>] ` ` /backport disable <repo> [<branch>]` (default branch is master)
>> 
>> 1. If the `/backport` command is used in an **open** pull request, it adds a label `Backport=repo:branch` to the PR. If the PR is later integrated, the PR bot scans for backport labels, creates the backport branch and provides a link for creating the backport. To cancel the backport, the user can use `/backport disable repo master` to remove the label before the PR is integrated.
>> 2.  If the `/backport` command is used in an **integrated** PR, it creates the backport branch and comments on the PR. This process is similar to using the /backport command in commits. (This feature was implemented in [SKARA-1495](https://bugs.openjdk.org/browse/SKARA-1495) by guoxiong li, but the usage was not documented on the[ wiki page](https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands), so seems like few people use this command)
>> 3.  If the `/backport` command is used in a **closed** (not integrated) PR, the user will receive an error message stating that the command cannot be used in a closed but not integrated PR.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix an issue

Thanks for review!

-------------

PR: https://git.openjdk.org/skara/pull/1466

From thomas.stuefe at gmail.com  Wed Feb  8 07:59:01 2023
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Wed, 8 Feb 2023 08:59:01 +0100
Subject: Prevent Mails from Draft-state PRs?
Message-ID: <CAA-vtUzKhmza1WfwfjfqfDZXmK_kpNYEG9+-yqFTu9sg65Z=Vg@mail.gmail.com>

Hi,

would it be possible to prevent sending ML mails for PRs in draft state?

ATM, if the PR is created in Draft state, no mail is sent. But if it had
been published and then converted back to Draft, mails are continued to be
sent. Was that intentional?

At least for me, sometimes my workflow requires a PR to go back to draft if
I want to work on it without bothering reviewers. I would prefer to not
flood the MLs with change mails then.

Thank you!

..Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20230208/aea18d09/attachment.htm>

From kevin.rushforth at oracle.com  Wed Feb  8 13:47:52 2023
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Wed, 8 Feb 2023 05:47:52 -0800
Subject: Prevent Mails from Draft-state PRs?
In-Reply-To: <CAA-vtUzKhmza1WfwfjfqfDZXmK_kpNYEG9+-yqFTu9sg65Z=Vg@mail.gmail.com>
References: <CAA-vtUzKhmza1WfwfjfqfDZXmK_kpNYEG9+-yqFTu9sg65Z=Vg@mail.gmail.com>
Message-ID: <bb779418-c89d-48e6-f6cd-1e34266ea4fa@oracle.com>

There is an open bug tracking this:

https://bugs.openjdk.org/browse/SKARA-1588

-- Kevin


On 2/7/2023 11:59 PM, Thomas St?fe wrote:
> Hi,
>
> would it be possible to prevent sending ML mails for PRs in draft state?
>
> ATM, if the PR is created in Draft state, no mail is sent. But if it 
> had been published and then converted back to Draft, mails are 
> continued to be sent. Was that intentional?
>
> At least for me, sometimes my workflow requires a PR to go back to 
> draft if I want to work on it without bothering reviewers. I would 
> prefer to not flood the MLs with change mails then.
>
> Thank you!
>
> ..Thomas


From zsong at openjdk.org  Wed Feb  8 19:55:44 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 19:55:44 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of the
 repo name
Message-ID: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>

In this patch, `.git` is added to the URLs printed by Skara.

-------------

Commit messages:
 - SKARA-1813

Changes: https://git.openjdk.org/skara/pull/1467/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1813
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From erikj at openjdk.org  Wed Feb  8 20:24:12 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 20:24:12 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <TO4j-XhbNdpV4NevFH2Bx14xiwNTpjj-AZ6GuOU_6Ao=.2d2a93e8-f47a-4a0d-9c0a-3df74cc25223@github.com>

On Wed, 8 Feb 2023 19:51:52 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this patch, `.git` is added to the URLs printed by Skara.

I don't think we should just add ".git" to the webUrl. What we need is a new method on `HostedRepository` that returns the URL in a format suitable for the command line client. Basically the form you get in the "Code" drop down on the repository main page on GitHub. There is already a method `HostedRepository::url` which is almost this but not quite. It doesn't perform the transformation, and it adds authentication, which we don't want. Maybe `HostedRepository::transformedUrl`, not sure.

-------------

Changes requested by erikj (Lead).

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 21:40:54 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 21:40:54 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name
In-Reply-To: <TO4j-XhbNdpV4NevFH2Bx14xiwNTpjj-AZ6GuOU_6Ao=.2d2a93e8-f47a-4a0d-9c0a-3df74cc25223@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <TO4j-XhbNdpV4NevFH2Bx14xiwNTpjj-AZ6GuOU_6Ao=.2d2a93e8-f47a-4a0d-9c0a-3df74cc25223@github.com>
Message-ID: <EVyhL0uXC8L33tjXZTPT0NYqO9bs42RsP6HBJHfV28Y=.3680d990-1e46-4422-af7d-902475929f35@github.com>

On Wed, 8 Feb 2023 20:21:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I don't think we should just add ".git" to the webUrl. What we need is a new method on `HostedRepository` that returns the URL in a format suitable for the command line client. Basically the form you get in the "Code" drop down on the repository main page on GitHub. There is already a method `HostedRepository::url` which is almost this but not quite. It doesn't perform the transformation, and it adds authentication, which we don't want. Maybe `HostedRepository::transformedUrl`, not sure.

Ok, I will add a new method. Thanks.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 21:54:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 21:54:35 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v2]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <HzFjXYoI1Prb_liTyiTctCoXz4awSswnOWJQMBfsb-o=.ae777874-b38e-4df8-a5a9-1e60422678fb@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  add method HostedRepository#remoteUrl

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/4606f347..3200f967

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=00-01

  Stats: 27 lines in 6 files changed: 24 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 22:54:39 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 22:54:39 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v3]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <0YAOkcCDcR4AIKHZOe5pJcTI4c0y05FEEscbgmUr4Ho=.ecceb718-83c6-4362-a79c-978d8807fe88@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  Update forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/3200f967..4819086a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=01-02

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From erikj at openjdk.org  Wed Feb  8 22:54:39 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 22:54:39 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v2]
In-Reply-To: <HzFjXYoI1Prb_liTyiTctCoXz4awSswnOWJQMBfsb-o=.ae777874-b38e-4df8-a5a9-1e60422678fb@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <HzFjXYoI1Prb_liTyiTctCoXz4awSswnOWJQMBfsb-o=.ae777874-b38e-4df8-a5a9-1e60422678fb@github.com>
Message-ID: <ooXBFzFgO0k-s52-Zpf4PBp-IhvBC6uz61YeeGxXF6Q=.3e0cff14-4742-4596-95ff-94d9368f3ec5@github.com>

On Wed, 8 Feb 2023 21:54:35 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this patch, `.git` is added to the URLs printed by Skara.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add method HostedRepository#remoteUrl

This is better. There are more places that need to use the new method. The fallback instructions for /backport is one example where I just saw URLs with no .git in example command lines.

forge/src/main/java/org/openjdk/skara/forge/HostedRepository.java line 86:

> 84:     URI diffUrl(String prId);
> 85:     VCS repositoryType();
> 86:     URI remoteUrl();

Suggestion:

    /**
     * Returns a URL suitable for CLI interactions with the repository
     */
    URI remoteUrl();

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 22:54:40 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 22:54:40 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v2]
In-Reply-To: <ooXBFzFgO0k-s52-Zpf4PBp-IhvBC6uz61YeeGxXF6Q=.3e0cff14-4742-4596-95ff-94d9368f3ec5@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <HzFjXYoI1Prb_liTyiTctCoXz4awSswnOWJQMBfsb-o=.ae777874-b38e-4df8-a5a9-1e60422678fb@github.com>
 <ooXBFzFgO0k-s52-Zpf4PBp-IhvBC6uz61YeeGxXF6Q=.3e0cff14-4742-4596-95ff-94d9368f3ec5@github.com>
Message-ID: <qGFW7McUWTMPy9xMJ2GhIPltRzBw1dcSI7WnpBx67Ns=.75e1117c-2e17-4f78-aa52-bff00dfd708e@github.com>

On Wed, 8 Feb 2023 22:47:50 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is better. There are more places that need to use the new method. The fallback instructions for /backport is one example where I just saw URLs with no .git in example command lines.

I would use it in suitable places.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 23:16:38 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 23:16:38 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v4]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <F8B-UgYaiPaGSOXFLnul18NObLfE81djk3FFRiU5CTo=.5b459109-464a-4882-a4e5-a85752c65e35@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  use remoteUrl() in more places

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/4819086a..b3680990

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=02-03

  Stats: 13 lines in 7 files changed: 0 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 23:18:30 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 23:18:30 GMT
Subject: RFR: 1814: Add logic to allow bot run Backport Command
Message-ID: <nKLCcTA6ZwnHB5Y8uFsY3VhWHUeVCYrEqI2ZKVSXL6M=.ab80d794-c592-49eb-9b51-337e9c6debbd@github.com>

In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot might issue /backport command when the pr is integrated. 

However, in the very first of Backport Command, the bot would check whether the command user is in the census. The bot itself is not in the census, so the command issued by the bot would fail.

In this patch, I added the logic to explicitly allow bot run `/backport` command in closed pr or commits.

-------------

Commit messages:
 - SKARA-1814

Changes: https://git.openjdk.org/skara/pull/1468/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1468&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1814
  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1468.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1468/head:pull/1468

PR: https://git.openjdk.org/skara/pull/1468

From erikj at openjdk.org  Wed Feb  8 23:28:50 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 23:28:50 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v4]
In-Reply-To: <F8B-UgYaiPaGSOXFLnul18NObLfE81djk3FFRiU5CTo=.5b459109-464a-4882-a4e5-a85752c65e35@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <F8B-UgYaiPaGSOXFLnul18NObLfE81djk3FFRiU5CTo=.5b459109-464a-4882-a4e5-a85752c65e35@github.com>
Message-ID: <Sj1eOkUI9KjnmsX4l-4zJP75y0Fl6tOscLztR399R7I=.cba91484-620d-4e7e-bb0c-eabb00e9eb2b@github.com>

On Wed, 8 Feb 2023 23:16:38 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this patch, `.git` is added to the URLs printed by Skara.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use remoteUrl() in more places

bots/checkout/src/main/java/org/openjdk/skara/bots/checkout/CheckoutBot.java line 67:

> 65: 
> 66:     private URI webURI() {
> 67:         var webURI = from.remoteUrl().toString();

Converting from URI to String and then back to URI doesn't seem like a good idea. This method is called in one place, so should probably just get rid of it.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From erikj at openjdk.org  Wed Feb  8 23:29:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 8 Feb 2023 23:29:46 GMT
Subject: RFR: 1814: Add logic to allow bot run Backport Command
In-Reply-To: <nKLCcTA6ZwnHB5Y8uFsY3VhWHUeVCYrEqI2ZKVSXL6M=.ab80d794-c592-49eb-9b51-337e9c6debbd@github.com>
References: <nKLCcTA6ZwnHB5Y8uFsY3VhWHUeVCYrEqI2ZKVSXL6M=.ab80d794-c592-49eb-9b51-337e9c6debbd@github.com>
Message-ID: <j6OfnhOaA0mxUVKzVo8tG0cEYqTPTNKeCAKLFUL1UyI=.0adb3c91-a486-4317-977c-8bf7dbc10f01@github.com>

On Wed, 8 Feb 2023 22:48:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot might issue /backport command when the pr is integrated. 
> 
> However, in the very first of Backport Command, the bot would check whether the command user is in the census. The bot itself is not in the census, so the command issued by the bot would fail.
> 
> In this patch, I added the logic to explicitly allow bot run `/backport` command in closed pr or commits.

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1468

From zsong at openjdk.org  Wed Feb  8 23:42:25 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 23:42:25 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v5]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <D8MQItq5hn-ZKqUqeegZ9BkGjWV01U7IIOCWhoy7QT8=.2c782548-7ced-4dec-a814-46c0db6be30e@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix a problem

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/b3680990..9805b916

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=04
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Wed Feb  8 23:42:26 2023
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 8 Feb 2023 23:42:26 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v4]
In-Reply-To: <Sj1eOkUI9KjnmsX4l-4zJP75y0Fl6tOscLztR399R7I=.cba91484-620d-4e7e-bb0c-eabb00e9eb2b@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <F8B-UgYaiPaGSOXFLnul18NObLfE81djk3FFRiU5CTo=.5b459109-464a-4882-a4e5-a85752c65e35@github.com>
 <Sj1eOkUI9KjnmsX4l-4zJP75y0Fl6tOscLztR399R7I=.cba91484-620d-4e7e-bb0c-eabb00e9eb2b@github.com>
Message-ID: <4tg13oVlFhBKMmMYp5FHDSnnJDTxpGzRSabFk3xnEWQ=.741abb76-cc46-4ee1-ae6f-51a4438903e4@github.com>

On Wed, 8 Feb 2023 23:22:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use remoteUrl() in more places
>
> bots/checkout/src/main/java/org/openjdk/skara/bots/checkout/CheckoutBot.java line 67:
> 
>> 65: 
>> 66:     private URI webURI() {
>> 67:         var webURI = from.remoteUrl().toString();
> 
> Converting from URI to String and then back to URI doesn't seem like a good idea. This method is called in one place, so should probably just get rid of it.

Oh, I didn't find this redundant operation.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Thu Feb  9 00:00:06 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 00:00:06 GMT
Subject: Integrated: 1814: Add logic to allow bot run Backport Command
In-Reply-To: <nKLCcTA6ZwnHB5Y8uFsY3VhWHUeVCYrEqI2ZKVSXL6M=.ab80d794-c592-49eb-9b51-337e9c6debbd@github.com>
References: <nKLCcTA6ZwnHB5Y8uFsY3VhWHUeVCYrEqI2ZKVSXL6M=.ab80d794-c592-49eb-9b51-337e9c6debbd@github.com>
Message-ID: <Bq6zfCSiAWfbX2miWOI3gLpqirBTpQKdlLb36UhD69c=.572e3b81-5b10-42b8-b809-9d18c9010565@github.com>

On Wed, 8 Feb 2023 22:48:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot might issue /backport command when the pr is integrated. 
> 
> However, in the very first of Backport Command, the bot would check whether the command user is in the census. The bot itself is not in the census, so the command issued by the bot would fail.
> 
> In this patch, I added the logic to explicitly allow bot run `/backport` command in closed pr or commits.

This pull request has now been integrated.

Changeset: 6e97d991
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/6e97d991b531f04f77e7b4243890a152c1d84eb1
Stats:     3 lines in 3 files changed: 0 ins; 1 del; 2 mod

1814: Add logic to allow bot run Backport Command

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1468

From erikj at openjdk.org  Thu Feb  9 13:40:29 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 13:40:29 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v5]
In-Reply-To: <D8MQItq5hn-ZKqUqeegZ9BkGjWV01U7IIOCWhoy7QT8=.2c782548-7ced-4dec-a814-46c0db6be30e@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <D8MQItq5hn-ZKqUqeegZ9BkGjWV01U7IIOCWhoy7QT8=.2c782548-7ced-4dec-a814-46c0db6be30e@github.com>
Message-ID: <z80Oog1k5CpJGuE3s6HLSA2EVcAMUfPCP9IInv3mPXk=.49cf54e3-384f-45ed-9e44-741a4f7ee796@github.com>

On Wed, 8 Feb 2023 23:42:25 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this patch, `.git` is added to the URLs printed by Skara.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a problem

bots/checkout/src/main/java/org/openjdk/skara/bots/checkout/CheckoutBot.java line 67:

> 65: 
> 66:     private URI webURI() {
> 67:         return from.remoteUrl();

I meant that this whole method is redundant now and can just be inlined.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Thu Feb  9 17:04:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 17:04:23 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v6]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <jN5RFInd8LKndug_wr4TSUk4SJOi5RWwxUTDpNu0e0c=.613140a7-fc56-47bf-b436-120aa632114c@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant method

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/9805b916..959eb93b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=05
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=04-05

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Thu Feb  9 17:04:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 17:04:23 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v5]
In-Reply-To: <z80Oog1k5CpJGuE3s6HLSA2EVcAMUfPCP9IInv3mPXk=.49cf54e3-384f-45ed-9e44-741a4f7ee796@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <D8MQItq5hn-ZKqUqeegZ9BkGjWV01U7IIOCWhoy7QT8=.2c782548-7ced-4dec-a814-46c0db6be30e@github.com>
 <z80Oog1k5CpJGuE3s6HLSA2EVcAMUfPCP9IInv3mPXk=.49cf54e3-384f-45ed-9e44-741a4f7ee796@github.com>
Message-ID: <ee-IdB_RHr8G5kF7vYuDCBqNj3PIqCdvEz4cZhkCwYE=.22faeca4-b730-43db-8535-c0ed86f9daae@github.com>

On Thu, 9 Feb 2023 13:38:23 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix a problem
>
> bots/checkout/src/main/java/org/openjdk/skara/bots/checkout/CheckoutBot.java line 67:
> 
>> 65: 
>> 66:     private URI webURI() {
>> 67:         return from.remoteUrl();
> 
> I meant that this whole method is redundant now and can just be inlined.

Sorry, fixed it now.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From gli at openjdk.org  Thu Feb  9 17:52:10 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 9 Feb 2023 17:52:10 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft state
Message-ID: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>

Hi all,

This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
And the related test case is added.

Thanks for taking the time to review.

Best Regards,
-- Guoxiong

-------------

Commit messages:
 - SKARA-1588

Changes: https://git.openjdk.org/skara/pull/1469/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1588
  Stats: 124 lines in 3 files changed: 121 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1469.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1469/head:pull/1469

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Thu Feb  9 18:46:19 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 18:46:19 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <_4v_tanku92OdNNJvXmKwkPAaBmZRw50LBuWVkWZhQU=.01124ff5-e437-4d01-9517-88170cb0d5d5@github.com>

On Thu, 9 Feb 2023 17:48:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

I think this patch could successfully help us postpone the sending of emails when the pr is in draft mode and some users will be happy to see this update.

-------------

Marked as reviewed by zsong (Committer).

PR: https://git.openjdk.org/skara/pull/1469

From kcr at openjdk.org  Thu Feb  9 19:27:35 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Feb 2023 19:27:35 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <ZfyDjO8-hreiTNVkXeH0IB5QywRxSOlC-n04mNdHlXw=.1735b3c6-dd3d-4a31-81a9-ce3b920bc3a1@github.com>

On Thu, 9 Feb 2023 17:48:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Not sure whether this is sufficient. See my question below.

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBot.java line 206:

> 204:         List<PullRequest> prs = poller.updatedPullRequests();
> 205:         prs.stream()
> 206:                 .filter(pr -> !pr.isDraft())

Are you sure this is the right place to do this? The intention of this fix is to pause notifications for Draft PRs until it becomes "rfr" again, just like it currently does for PRs initially in Draft that become "rfr" for the first time. Will it do this or will it just lose the notifications permanently?

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Thu Feb  9 19:39:16 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 19:39:16 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <Pq90iNQAZiSmkIXFup8eVZ21lxLGzVxphUtfJDqgUnQ=.9e60b136-945b-4b15-9776-dc06eed2f77b@github.com>

On Thu, 9 Feb 2023 17:48:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotTests.java line 3553:

> 3551:             assertEquals(3, archiveContainsCount(archiveFolder.path(), "RFR: 1234: This is a pull request"));
> 3552:             assertEquals(1, archiveContainsCount(archiveFolder.path(), "This is a comment"));
> 3553:             assertEquals(1, archiveContainsCount(archiveFolder.path(), "This is a new comment"));

@kevinrushforth Hi Kevin, see Li's test case here. This pr was 'rfr' and he converted it to draft. When the pr was in draft mode, he added a comment 'This is a new comment' and run the bot. As expected, there is no email sent. After that, he converted the pr to 'rfr' again and run the bot. This time, he got the notification about the comment 'This is a new comment'. So we won't lose the notification permanently. It's just delayed.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From kcr at openjdk.org  Thu Feb  9 20:11:56 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Feb 2023 20:11:56 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <Pq90iNQAZiSmkIXFup8eVZ21lxLGzVxphUtfJDqgUnQ=.9e60b136-945b-4b15-9776-dc06eed2f77b@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <Pq90iNQAZiSmkIXFup8eVZ21lxLGzVxphUtfJDqgUnQ=.9e60b136-945b-4b15-9776-dc06eed2f77b@github.com>
Message-ID: <XiTfl6p81vtB4refPgBVHTotaNjtiHgG2J3rTY28yhw=.028e1284-556e-44d7-9217-e67dcdd189de@github.com>

On Thu, 9 Feb 2023 19:37:12 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> bots/mlbridge/src/test/java/org/openjdk/skara/bots/mlbridge/MailingListBridgeBotTests.java line 3553:
> 
>> 3551:             assertEquals(3, archiveContainsCount(archiveFolder.path(), "RFR: 1234: This is a pull request"));
>> 3552:             assertEquals(1, archiveContainsCount(archiveFolder.path(), "This is a comment"));
>> 3553:             assertEquals(1, archiveContainsCount(archiveFolder.path(), "This is a new comment"));
> 
> @kevinrushforth Hi Kevin, see Li's test case here. This pr was 'rfr' and he converted it to draft. When the pr was in draft mode, he added a comment 'This is a new comment' and run the bot. As expected, there is no email sent. After that, he converted the pr to 'rfr' again and run the bot. This time, he got the notification about the comment 'This is a new comment'. So we won't lose the notification permanently. It's just delayed.

OK, thanks.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Thu Feb  9 21:10:52 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 21:10:52 GMT
Subject: RFR: 1706: Store github checks in PR unique way
In-Reply-To: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
Message-ID: <f_9Dc9z_mm-gkqD5wl-98eRcNDOmbXOElF5Df9WqcZw=.77a826dc-2580-4966-b733-bce5f5b037f4@github.com>

On Thu, 9 Feb 2023 19:13:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>  
> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.

Checked the [checkrun](https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28#get-a-check-run) document in GitHub and I found the document says there will be an `id` for every check-run. The document also says if we want to update the check-run, `id` is required in the header. But in `GitHubPullRequest#updateCheck`, I don't think we have anything related with `id`. Therefore I am wondering how could we update the check in GitHub, do we update the checks by the name?

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 21:10:52 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 21:10:52 GMT
Subject: RFR: 1706: Store github checks in PR unique way
Message-ID: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>

Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
 
This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.

-------------

Commit messages:
 - SKARA-1706

Changes: https://git.openjdk.org/skara/pull/1470/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1470&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1706
  Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1470.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1470/head:pull/1470

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Thu Feb  9 21:41:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 21:41:52 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>

On Thu, 9 Feb 2023 17:48:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This will indeed pause emails while a PR is in draft state. When it gets back from draft, I believe everything that happened while in draft will be sent. That is certainly the easiest way to handle this and I'm good with this change. We will just have to see how it plays out in practice.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From erikj at openjdk.org  Thu Feb  9 21:54:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 21:54:23 GMT
Subject: RFR: 1706: Store github checks in PR unique way
In-Reply-To: <f_9Dc9z_mm-gkqD5wl-98eRcNDOmbXOElF5Df9WqcZw=.77a826dc-2580-4966-b733-bce5f5b037f4@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <f_9Dc9z_mm-gkqD5wl-98eRcNDOmbXOElF5Df9WqcZw=.77a826dc-2580-4966-b733-bce5f5b037f4@github.com>
Message-ID: <30ehibJGDmY6a_odPWn2i239R8RFMUFHel2WHGmVqpY=.b43f27a6-7124-4729-841f-e633d9878617@github.com>

On Thu, 9 Feb 2023 21:00:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Checked the [checkrun](https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28#get-a-check-run) document in GitHub and I found the document says there will be an `id` for every check-run. The document also says if we want to update the check-run, `id` is required in the header. But in `GitHubPullRequest#updateCheck`, I don't think we have anything related with `id`. Therefore I am wondering how could we update the check in GitHub, do we update the checks by the name?

See comment at:
https://github.com/openjdk/skara/blob/51956054485fce5cb42629c9696a3131cb098178/forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java#L454

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 22:01:13 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 22:01:13 GMT
Subject: RFR: 1706: Store github checks in PR unique way
In-Reply-To: <30ehibJGDmY6a_odPWn2i239R8RFMUFHel2WHGmVqpY=.b43f27a6-7124-4729-841f-e633d9878617@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <f_9Dc9z_mm-gkqD5wl-98eRcNDOmbXOElF5Df9WqcZw=.77a826dc-2580-4966-b733-bce5f5b037f4@github.com>
 <30ehibJGDmY6a_odPWn2i239R8RFMUFHel2WHGmVqpY=.b43f27a6-7124-4729-841f-e633d9878617@github.com>
Message-ID: <9PH9aQ9eP_Fy0l3JlkPBZFJ3myEH9ZJLwzERi0Wl1YY=.ff708f7d-a2f7-4c3b-82d0-ac5077120d01@github.com>

On Thu, 9 Feb 2023 21:52:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Checked the [checkrun](https://docs.github.com/en/rest/checks/runs?apiVersion=2022-11-28#get-a-check-run) document in GitHub and I found the document says there will be an `id` for every check-run. The document also says if we want to update the check-run, `id` is required in the header. But in `GitHubPullRequest#updateCheck`, I don't think we have anything related with `id`. Therefore I am wondering how could we update the check in GitHub, do we update the checks by the name?
> 
> See comment at:
> 
> https://github.com/openjdk/skara/blob/51956054485fce5cb42629c9696a3131cb098178/forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java#L454

Thanks!

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Thu Feb  9 22:11:39 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 22:11:39 GMT
Subject: RFR: 1706: Store github checks in PR unique way
In-Reply-To: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
Message-ID: <2s7LhDMiCDc48EVpG9GHRh28FoGSFgZI1vvBmK3GmtI=.b83ec196-5e61-4a3b-8cea-26238b1feb3a@github.com>

On Thu, 9 Feb 2023 19:13:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>  
> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 123:

> 121:         var metadata = getMetadata(censusInstance, pr.title(), pr.body(), comments, reviews, labels, pr.targetRef(), pr.isDraft(), null);
> 122:         var currentChecks = pr.checks(hash);
> 123:         var jcheckName = pr.repository().forge().name().equals("GitHub") ? "jcheck" + pr.repository().name() + pr.id() : "jcheck";

The generation of the name needs to be handled in one place. Possibly a static method on CheckRun or CheckWorkItem, or maybe CheckablePullrequest. I would also suggest some delimiters, something like `jcheck-repo#pull` (if # is a valid character, otherwise just dash).

The check is created in CheckRun, so the name needs to be changed there too.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 64:

> 62:         final var outdated = "the status check `" + checkName + "` has not been performed on commit %s yet";
> 63: 
> 64:         checkName = checkName.equals("jcheck") && pr.repository().forge().name().equals("GitHub") ?

There is just one caller of this method, which explicitly calls with `"jcheck"`. The caller should generate the new check name instead of rewriting it here.

forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 464:

> 462:     public void updateCheck(Check check) {
> 463:         var completedQuery = JSON.object();
> 464:         completedQuery.put("name", check.name().equals("jcheck") ? check.name() + repository().name() + id() : check.name());

I don't understand this change. Why would we need that? I don't think GitHubPullRequest should be changing check names.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 22:26:54 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 22:26:54 GMT
Subject: RFR: 1706: Store github checks in PR unique way
In-Reply-To: <2s7LhDMiCDc48EVpG9GHRh28FoGSFgZI1vvBmK3GmtI=.b83ec196-5e61-4a3b-8cea-26238b1feb3a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <2s7LhDMiCDc48EVpG9GHRh28FoGSFgZI1vvBmK3GmtI=.b83ec196-5e61-4a3b-8cea-26238b1feb3a@github.com>
Message-ID: <8sTGW9257qD1ZgD5XnHcmtEQYuZ9u2QlcZK6veNSiEk=.536e9f9f-9985-443f-9553-62bfca453803@github.com>

On Thu, 9 Feb 2023 22:01:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 64:
> 
>> 62:         final var outdated = "the status check `" + checkName + "` has not been performed on commit %s yet";
>> 63: 
>> 64:         checkName = checkName.equals("jcheck") && pr.repository().forge().name().equals("GitHub") ?
> 
> There is just one caller of this method, which explicitly calls with `"jcheck"`. The caller should generate the new check name instead of rewriting it here.

But in that way, the checkName will be "jcheck-repo#pull" and the error message showed to user would be "the status check jcheck-repo#pull is still in progress".

> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 464:
> 
>> 462:     public void updateCheck(Check check) {
>> 463:         var completedQuery = JSON.object();
>> 464:         completedQuery.put("name", check.name().equals("jcheck") ? check.name() + repository().name() + id() : check.name());
> 
> I don't understand this change. Why would we need that? I don't think GitHubPullRequest should be changing check names.

As you said in the comment above "The check is created in CheckRun, so the name needs to be changed there too.", I didn't change the check name when it is created, so I changed it here. It's my bad, I will fix it.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 22:40:42 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 22:40:42 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
Message-ID: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>

> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>  
> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix problems

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1470/files
  - new: https://git.openjdk.org/skara/pull/1470/files/df2fc3c1..c7909f03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1470&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1470&range=00-01

  Stats: 11 lines in 4 files changed: 4 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/skara/pull/1470.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1470/head:pull/1470

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Thu Feb  9 23:00:35 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 23:00:35 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <8sTGW9257qD1ZgD5XnHcmtEQYuZ9u2QlcZK6veNSiEk=.536e9f9f-9985-443f-9553-62bfca453803@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <2s7LhDMiCDc48EVpG9GHRh28FoGSFgZI1vvBmK3GmtI=.b83ec196-5e61-4a3b-8cea-26238b1feb3a@github.com>
 <8sTGW9257qD1ZgD5XnHcmtEQYuZ9u2QlcZK6veNSiEk=.536e9f9f-9985-443f-9553-62bfca453803@github.com>
Message-ID: <-GiqzDhO7VVxLJOXsajPUND0vakCHmBGMQMwXqb1SqU=.a8f23d7f-ff34-4b93-b635-3f1692d30a6a@github.com>

On Thu, 9 Feb 2023 22:22:51 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/IntegrateCommand.java line 64:
>> 
>>> 62:         final var outdated = "the status check `" + checkName + "` has not been performed on commit %s yet";
>>> 63: 
>>> 64:         checkName = checkName.equals("jcheck") && pr.repository().forge().name().equals("GitHub") ?
>> 
>> There is just one caller of this method, which explicitly calls with `"jcheck"`. The caller should generate the new check name instead of rewriting it here.
>
> But in that way, the checkName will be "jcheck-repo#pull" and the error message showed to user would be "the status check jcheck-repo#pull is still in progress".

I think that's what we want. That's the name the check will have in the GitHub UI as well.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Thu Feb  9 23:04:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 9 Feb 2023 23:04:09 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
Message-ID: <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>

On Thu, 9 Feb 2023 22:40:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix problems

I think this looks ok. Could you run it in staging and verify that it works and looks ok before integrating?

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 23:06:15 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 23:06:15 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
Message-ID: <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>

On Thu, 9 Feb 2023 23:01:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this looks ok. Could you run it in staging and verify that it works and looks ok before integrating?

Sure. I will run my own fork on staging to verify it.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Thu Feb  9 23:38:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 9 Feb 2023 23:38:53 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
Message-ID: <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>

On Thu, 9 Feb 2023 23:04:10 GMT, Zhao Song <zsong at openjdk.org> wrote:

> I think this looks ok. Could you run it in staging and verify that it works and looks ok before integrating?

I think it works fine. Currently, each pr would have a unique jcheck. https://github.com/openjdk/playground/pull/126/checks?check_run_id=11239907703

-------------

PR: https://git.openjdk.org/skara/pull/1470

From gli at openjdk.org  Fri Feb 10 11:22:57 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 Feb 2023 11:22:57 GMT
Subject: RFR: 1725: Clarify "no known role" error message [v2]
In-Reply-To: <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
 <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com>
Message-ID: <OySYV3aYV1fjLFkrTAY-Qt_F5rYMe2ynlzJXJBei8kU=.bd5ac4be-d9ea-4d80-80da-813a83ae1618@github.com>

On Mon, 23 Jan 2023 18:40:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: 
>> 
>> (no known github.com user name / role) 
>> 
>> What it actually means is "no known OpenJDK user name / role".
>> 
>> Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a problem

Now it becomes `no known openjdk user` and `no known oracle user`. Looks good if we can't find a good way to construct `OpenJDK` and `Oracle`.

-------------

Marked as reviewed by gli (Committer).

PR: https://git.openjdk.org/skara/pull/1459

From gli at openjdk.org  Fri Feb 10 11:30:59 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 Feb 2023 11:30:59 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v6]
In-Reply-To: <jN5RFInd8LKndug_wr4TSUk4SJOi5RWwxUTDpNu0e0c=.613140a7-fc56-47bf-b436-120aa632114c@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <jN5RFInd8LKndug_wr4TSUk4SJOi5RWwxUTDpNu0e0c=.613140a7-fc56-47bf-b436-120aa632114c@github.com>
Message-ID: <R9tz2CHvvC7iHABJ6Jq4jSztIhTmhf5pjySKKS0U-Io=.8e20cc96-096d-49b2-8918-0061808bf87d@github.com>

On Thu, 9 Feb 2023 17:04:23 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In this patch, `.git` is added to the URLs printed by Skara.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant method

Looks good. The name `remoteUrl` doesn't seem very good, but with the comment, it is OK.

-------------

Marked as reviewed by gli (Committer).

PR: https://git.openjdk.org/skara/pull/1467

From gli at openjdk.org  Fri Feb 10 11:58:47 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 Feb 2023 11:58:47 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
Message-ID: <A67CYpT9xiKSoQ4f9Ailw_uoKIkAuXBw-bbmrmTsd-8=.d2799052-8981-4598-bfc8-2552d519dc04@github.com>

On Thu, 9 Feb 2023 22:40:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix problems

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1091:

> 1089:         return pr.repository().forge().name().equals("GitHub") ? "jcheck-" + pr.repository().name() + "-" + pr.id() : "jcheck";
> 1090:     }
> 1091: 

Why does the `GitLab merge request` not need to change such name? I think GitLab also needs.

This method is now put in class `CheckRun` and is used in both `CheckRun` and `CheckWorkItem`. It seems not a good design. We can move the method to the interface `PullRequest` with a default implementation, just like below. Then we can use `pr.getJcheckName()` in both `CheckRun` and `CheckWorkItem`.


// file PullRequest.java
    default String getJcheckName() {
        return "jcheck-" + repository().name() + "-" + id();
    }

-------------

PR: https://git.openjdk.org/skara/pull/1470

From gli at openjdk.org  Fri Feb 10 12:30:25 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 10 Feb 2023 12:30:25 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
Message-ID: <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>

On Thu, 9 Feb 2023 23:36:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

> I think it works fine. Currently, each pr would have a unique jcheck. https://github.com/openjdk/playground/pull/126/checks?check_run_id=11239907703

>From the link you provided, I notice there are three items `jcheck`, `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` under the `openjdk`. And the `PR-125`, which is sooner than `PR-126`, also has these three items, please see https://github.com/openjdk/playground/pull/125/checks.

And the `checks`, please see https://github.com/openjdk/skara/pull/1470/checks, of this pull request, it contains both `jcheck` and `jcheck-openjdk/skara-1470`.  And under the `All checks have passed` of this page (this pull request page), it also has two items `jcheck` and `jcheck-openjdk/skara-1470`. It is so strange. I suspect the current patch is not the right solution.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Fri Feb 10 14:06:59 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 14:06:59 GMT
Subject: RFR: 1725: Clarify "no known role" error message [v2]
In-Reply-To: <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
 <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com>
Message-ID: <9SCdBR4C4KKTIalWvzkZLhXZ2Cuwodf-g_bhz-gvdjs=.ced81d69-ef73-44a6-849a-f34a8d6dc5eb@github.com>

On Mon, 23 Jan 2023 18:40:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: 
>> 
>> (no known github.com user name / role) 
>> 
>> What it actually means is "no known OpenJDK user name / role".
>> 
>> Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a problem

Until we have a better field for this stored somewhere in the census data, I would prefer the domain field raw without modification.

-------------

PR: https://git.openjdk.org/skara/pull/1459

From erikj at openjdk.org  Fri Feb 10 14:08:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 14:08:44 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v6]
In-Reply-To: <R9tz2CHvvC7iHABJ6Jq4jSztIhTmhf5pjySKKS0U-Io=.8e20cc96-096d-49b2-8918-0061808bf87d@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <jN5RFInd8LKndug_wr4TSUk4SJOi5RWwxUTDpNu0e0c=.613140a7-fc56-47bf-b436-120aa632114c@github.com>
 <R9tz2CHvvC7iHABJ6Jq4jSztIhTmhf5pjySKKS0U-Io=.8e20cc96-096d-49b2-8918-0061808bf87d@github.com>
Message-ID: <RUwbtGT2ybBMhl6uJJsoeXstfggKETv7wKFDB7EFfxI=.6eb7ab03-ce24-4892-8be8-0d9d7599b3d8@github.com>

On Fri, 10 Feb 2023 11:28:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Looks good. The name `remoteUrl` doesn't seem very good, but with the comment, it is OK.

I agree, it's hard to come up with a good name for this. Ideally I think this one should be just `url` and the existing `url` should be renamed something like `authenticatedUrl`.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From erikj at openjdk.org  Fri Feb 10 14:15:26 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 14:15:26 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
Message-ID: <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>

On Fri, 10 Feb 2023 12:28:09 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> From the link you provided, I notice there are three items `jcheck`, `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` under the `openjdk`. And the `PR-125`, which is sooner than `PR-126`, also has these three items, please see https://github.com/openjdk/playground/pull/125/checks.

That's a good point and the kind of thing I wanted to catch by testing it in staging. This is caused by testinfo bot copying all checks from the source branch into the pull request. This copying will need to be filtered so that only the relevant jcheck checks are copied.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Fri Feb 10 14:20:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 14:20:42 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <A67CYpT9xiKSoQ4f9Ailw_uoKIkAuXBw-bbmrmTsd-8=.d2799052-8981-4598-bfc8-2552d519dc04@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <A67CYpT9xiKSoQ4f9Ailw_uoKIkAuXBw-bbmrmTsd-8=.d2799052-8981-4598-bfc8-2552d519dc04@github.com>
Message-ID: <vQWjIJ--8IJHyYH5I-YYPC4e6cP-ZSSYMQgqH7u3u2E=.1e67a263-e640-45ed-91b0-4dfb027f35e3@github.com>

On Fri, 10 Feb 2023 11:56:36 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix problems
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1091:
> 
>> 1089:         return pr.repository().forge().name().equals("GitHub") ? "jcheck-" + pr.repository().name() + "-" + pr.id() : "jcheck";
>> 1090:     }
>> 1091: 
> 
> Why does the `GitLab merge request` not need to change such name? I think GitLab also needs.
> 
> This method is now put in class `CheckRun` and is used in both `CheckRun` and `CheckWorkItem`. It seems not a good design. We can move the method to the interface `PullRequest` with a default implementation, just like below. Then we can use `pr.getJcheckName()` in both `CheckRun` and `CheckWorkItem`.
> 
> 
> // file PullRequest.java
>     default String getJcheckName() {
>         return "jcheck-" + repository().name() + "-" + id();
>     }

Because there is no concept of a "check" in GitLab. We just store the check results in a comment in the PR, so there is no reason to make the name of the check unique.

Until now my opinion was that the name of the jcheck check was something only the pull request bot module needed to know about, so putting that on the `PullRequest` interface didn't seem right. It was an implementation detail. But now since we need to share this information with testinfo, it would make sense to push this logic into `PullRequest`. The default method should in that case return "jcheck" and `GitHubPullRequest` can have the special implementation needed only on GitHub.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Fri Feb 10 14:56:05 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 14:56:05 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
Message-ID: <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>

On Thu, 9 Feb 2023 21:39:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This will indeed pause emails while a PR is in draft state. When it gets back from draft, I believe everything that happened while in draft will be sent. That is certainly the easiest way to handle this and I'm good with this change. We will just have to see how it plays out in practice.

Thinking about this some more, this simple solution has a pretty big drawback. There is no actual synchronization between events. All bot actions are asynchronous. Imagine the following scenario.

1. User posts comment "I'm putting this PR in draft to work on the feedback"
2. User puts PR in draft
3. mlbridge bot processes PR, finds it in draft and does nothing
4. User removes draft state
5. mlbridge bot processes PR, finds new comment from 1 and posts it.

For this to work correctly, draft PRs still need to be processed by mlbridge, and any events up until the draft state change need to be processed as usual. 

This is still possibly better than what we have, but I'm not sure. Opinions?

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Fri Feb 10 17:14:11 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:14:11 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
Message-ID: <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>

On Fri, 10 Feb 2023 14:13:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > From the link you provided, I notice there are three items `jcheck`, `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` under the `openjdk`. And the `PR-125`, which is sooner than `PR-126`, also has these three items, please see https://github.com/openjdk/playground/pull/125/checks.
> 
> That's a good point and the kind of thing I wanted to catch by testing it in staging. This is caused by testinfo bot copying all checks from the source branch into the pull request. This copying will need to be filtered so that only the relevant jcheck checks are copied.

Yes, I will make testinfo bot only copy the right jcheck run.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 17:20:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:20:53 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
Message-ID: <ObgzOrPsbr0DI7d5xhS-UQhFUBRkiwlnV-WOU0RG3cI=.c95bb4ad-9b0b-4886-b1e9-557ef6f1dfed@github.com>

On Fri, 10 Feb 2023 12:28:09 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> > I think it works fine. Currently, each pr would have a unique jcheck. https://github.com/openjdk/playground/pull/126/checks?check_run_id=11239907703
> 
> From the link you provided, I notice there are three items `jcheck`, `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` under the `openjdk`. And the `PR-125`, which is sooner than `PR-126`, also has these three items, please see https://github.com/openjdk/playground/pull/125/checks.
> 
> And the `checks`, please see https://github.com/openjdk/skara/pull/1470/checks, of this pull request, it contains both `jcheck` and `jcheck-openjdk/skara-1470`. And under the `All checks have passed` of this page (this pull request page), it also has two items `jcheck` and `jcheck-openjdk/skara-1470`. It is so strange. I suspect the current patch is not the right solution.

For the PRs in playground, they contain `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` because PR-125 and PR-126 share the same source commit and testinfo bot will copy all the tests under the source commit. They also contain `jcheck` because after testing, I revert the staging bot, so it will have a normal `jcheck`. 

For this PR in SKARA,  it contains `jcheck-openjdk/skara-1470` because SKARA is also configured to pr bot in staging in our configuration. 

I think after implementing the filter logic in testinfo bot, the checks will look better.

Thank you!

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 17:30:14 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:30:14 GMT
Subject: RFR: 1725: Clarify "no known role" error message [v3]
In-Reply-To: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
Message-ID: <_ryr_XdwQzHPU05JHe0G4RP9TP8m9Donde3GUpZw16o=.2c0f9e7b-b0f8-495c-bbc1-e3f75235677b@github.com>

> A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: 
> 
> (no known github.com user name / role) 
> 
> What it actually means is "no known OpenJDK user name / role".
> 
> Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  keep domain field raw

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1459/files
  - new: https://git.openjdk.org/skara/pull/1459/files/d6479ee3..7cccdd7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1459&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1459&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1459.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1459/head:pull/1459

PR: https://git.openjdk.org/skara/pull/1459

From zsong at openjdk.org  Fri Feb 10 17:30:15 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:30:15 GMT
Subject: RFR: 1725: Clarify "no known role" error message [v2]
In-Reply-To: <9SCdBR4C4KKTIalWvzkZLhXZ2Cuwodf-g_bhz-gvdjs=.ced81d69-ef73-44a6-849a-f34a8d6dc5eb@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
 <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com>
 <9SCdBR4C4KKTIalWvzkZLhXZ2Cuwodf-g_bhz-gvdjs=.ced81d69-ef73-44a6-849a-f34a8d6dc5eb@github.com>
Message-ID: <wSqkCBj_bC95yF57F1yNGK0NhODx0VpLrubL1GfS3xg=.18e0e363-d556-40e8-83d9-725b113cb829@github.com>

On Fri, 10 Feb 2023 14:04:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Until we have a better field for this stored somewhere in the census data, I would prefer the domain field raw without modification.

It will be `no known openjdk.org user` and `no known oracle.com user`.  I think it's also ok.

-------------

PR: https://git.openjdk.org/skara/pull/1459

From erikj at openjdk.org  Fri Feb 10 17:33:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 17:33:54 GMT
Subject: RFR: 1725: Clarify "no known role" error message [v3]
In-Reply-To: <_ryr_XdwQzHPU05JHe0G4RP9TP8m9Donde3GUpZw16o=.2c0f9e7b-b0f8-495c-bbc1-e3f75235677b@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
 <_ryr_XdwQzHPU05JHe0G4RP9TP8m9Donde3GUpZw16o=.2c0f9e7b-b0f8-495c-bbc1-e3f75235677b@github.com>
Message-ID: <RrPbE_EY61fOfKzpSq6DJBFvFpb_Na75GemDpztyVPE=.e56b86a6-416a-4301-8c34-790d4df7c52b@github.com>

On Fri, 10 Feb 2023 17:30:14 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: 
>> 
>> (no known github.com user name / role) 
>> 
>> What it actually means is "no known OpenJDK user name / role".
>> 
>> Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   keep domain field raw

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1459

From zsong at openjdk.org  Fri Feb 10 17:44:34 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:44:34 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
 <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
Message-ID: <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>

On Fri, 10 Feb 2023 14:52:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > This will indeed pause emails while a PR is in draft state. When it gets back from draft, I believe everything that happened while in draft will be sent. That is certainly the easiest way to handle this and I'm good with this change. We will just have to see how it plays out in practice.
> 
> Thinking about this some more, this simple solution has a pretty big drawback. There is no actual synchronization between events. All bot actions are asynchronous. Imagine the following scenario.
> 
> 1. User posts comment "I'm putting this PR in draft to work on the feedback"
> 2. User puts PR in draft
> 3. mlbridge bot processes PR, finds it in draft and does nothing
> 4. User removes draft state
> 5. mlbridge bot processes PR, finds new comment from 1 and posts it.
> 
> For this to work correctly, draft PRs still need to be processed by mlbridge, and any events up until the draft state change need to be processed as usual.
> 
> This is still possibly better than what we have, but I'm not sure. Opinions?

I'm not sure I understand it correctly. Is the problem that the notification 'I'm putting this PR in draft to work on the feedback' won't be sent until the user makes the PR out of draft mode? Maybe it's not a big problem, the window is not very big, just few minutes.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Fri Feb 10 17:48:33 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:48:33 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v6]
In-Reply-To: <RUwbtGT2ybBMhl6uJJsoeXstfggKETv7wKFDB7EFfxI=.6eb7ab03-ce24-4892-8be8-0d9d7599b3d8@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
 <jN5RFInd8LKndug_wr4TSUk4SJOi5RWwxUTDpNu0e0c=.613140a7-fc56-47bf-b436-120aa632114c@github.com>
 <R9tz2CHvvC7iHABJ6Jq4jSztIhTmhf5pjySKKS0U-Io=.8e20cc96-096d-49b2-8918-0061808bf87d@github.com>
 <RUwbtGT2ybBMhl6uJJsoeXstfggKETv7wKFDB7EFfxI=.6eb7ab03-ce24-4892-8be8-0d9d7599b3d8@github.com>
Message-ID: <vaIjw5C0YRUGTakltHfXzZx5zodTOC5Tf5X0JIb_VQk=.f0135e31-524b-45fd-91cf-0d1c6d6803ca@github.com>

On Fri, 10 Feb 2023 14:06:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Looks good. The name `remoteUrl` doesn't seem very good, but with the comment, it is OK.
> 
> I agree, it's hard to come up with a good name for this. Ideally I think this one should be just `url` and the existing `url` should be renamed something like `authenticatedUrl`.

Yes, I found it difficult to come up with a name at that time. I will rename the methods.

-------------

PR: https://git.openjdk.org/skara/pull/1467

From zsong at openjdk.org  Fri Feb 10 17:58:47 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 17:58:47 GMT
Subject: RFR: 1813: URLs printed by Skara should have ".git" at the end of
 the repo name [v7]
In-Reply-To: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
References: <ms1rXsPu-vCRiyhLFrHdcnGwEMbpxexZlQPTbztIZ1M=.9683e93f-a312-4862-88c7-16cc9b897476@github.com>
Message-ID: <wJoXFHY4WLReZMwObe7EYKfVS7zzR4NRBSIILVGgTDg=.927e9537-b273-4a01-b5af-ac952d231c96@github.com>

> In this patch, `.git` is added to the URLs printed by Skara.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  rename remoteUrl and url

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1467/files
  - new: https://git.openjdk.org/skara/pull/1467/files/959eb93b..cfbcec60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=06
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1467&range=05-06

  Stats: 1383 lines in 89 files changed: 0 ins; 19 del; 1364 mod
  Patch: https://git.openjdk.org/skara/pull/1467.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1467/head:pull/1467

PR: https://git.openjdk.org/skara/pull/1467

From erikj at openjdk.org  Fri Feb 10 18:00:08 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 18:00:08 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
 <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
 <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
Message-ID: <VuJCtvTsU56aH7sRprOv8Z6WnX1564MJkvAjZm8IGl8=.3c3d01e6-03a0-4be9-96e2-c3ebd29186ba@github.com>

On Fri, 10 Feb 2023 17:42:16 GMT, Zhao Song <zsong at openjdk.org> wrote:

> I'm not sure I understand it correctly. Is the problem that the notification 'I'm putting this PR in draft to work on the feedback' won't be sent until the user makes the PR out of draft mode? Maybe it's not a big problem, the window is not very big, just few minutes.

Yes, the problem is that the last comments or events before changing a PR to draft could be delayed until the PR is taken out of draft. The size of the window for this to happen is usually just a few minutes, but depending on the state of the bots, it could be much longer. My example scenario seems like a very plausible series of events however, a user comments about making it draft and then puts it in draft, more or less at the same time. In that case it's very likely that the last comment hits the window. Also delaying that particular message would be very confusing to users, and I can guarantee that if it happened, we would get a lot of complaints. A PR could be moved to draft for weeks, and suddenly receiving week old comments from before it was put in draft is pretty bad.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Fri Feb 10 18:14:16 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 18:14:16 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <VuJCtvTsU56aH7sRprOv8Z6WnX1564MJkvAjZm8IGl8=.3c3d01e6-03a0-4be9-96e2-c3ebd29186ba@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
 <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
 <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
 <VuJCtvTsU56aH7sRprOv8Z6WnX1564MJkvAjZm8IGl8=.3c3d01e6-03a0-4be9-96e2-c3ebd29186ba@github.com>
Message-ID: <p7bwIC-8E2S6i1Cuf85-3tNr_An_bdtsSfez-ICMiFo=.e492a537-1485-4a09-9aff-10e7f7e3972e@github.com>

On Fri, 10 Feb 2023 17:57:57 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > I'm not sure I understand it correctly. Is the problem that the notification 'I'm putting this PR in draft to work on the feedback' won't be sent until the user makes the PR out of draft mode? Maybe it's not a big problem, the window is not very big, just few minutes.
> 
> Yes, the problem is that the last comments or events before changing a PR to draft could be delayed until the PR is taken out of draft. The size of the window for this to happen is usually just a few minutes, but depending on the state of the bots, it could be much longer. My example scenario seems like a very plausible series of events however, a user comments about making it draft and then puts it in draft, more or less at the same time. In that case it's very likely that the last comment hits the window. Also delaying that particular message would be very confusing to users, and I can guarantee that if it happened, we would get a lot of complaints. A PR could be moved to draft for weeks, and suddenly receiving week old comments from before it was put in draft is pretty bad.

Ok, I think the solution is that we don't filter in `MailingListBridgeBot#getPeriodicItems`. Instead, in `ArchiveWorkItem#run`, we can check if the pr is in draft mode and record the time. This recorded time can then be used to filter the comments.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From erikj at openjdk.org  Fri Feb 10 18:56:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 18:56:17 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <p7bwIC-8E2S6i1Cuf85-3tNr_An_bdtsSfez-ICMiFo=.e492a537-1485-4a09-9aff-10e7f7e3972e@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
 <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
 <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
 <VuJCtvTsU56aH7sRprOv8Z6WnX1564MJkvAjZm8IGl8=.3c3d01e6-03a0-4be9-96e2-c3ebd29186ba@github.com>
 <p7bwIC-8E2S6i1Cuf85-3tNr_An_bdtsSfez-ICMiFo=.e492a537-1485-4a09-9aff-10e7f7e3972e@github.com>
Message-ID: <9ssof2XRByeMqO7DBbS-rl1HqYSsQg83uvXjpI7yGTo=.33245a99-30cd-4391-a348-00b804d1557f@github.com>

On Fri, 10 Feb 2023 18:12:04 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Ok, I think the solution is that we don't filter in `MailingListBridgeBot#getPeriodicItems`. Instead, in `ArchiveWorkItem#run`, we can check if the pr is in draft mode and record the time. This recorded time can then be used to filter the comments.

There should be events that we can query for with timestamps for when the state change happened. The check would be something like this: If pr.isDraft(), find last event that put it in draft and use the timestamp of that as filter for any email generation.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Fri Feb 10 20:24:47 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 20:24:47 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
Message-ID: <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>

On Fri, 10 Feb 2023 17:11:53 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > From the link you provided, I notice there are three items `jcheck`, `jcheck-openjdk/playground-125` and `jcheck-openjdk/playground-126` under the `openjdk`. And the `PR-125`, which is sooner than `PR-126`, also has these three items, please see https://github.com/openjdk/playground/pull/125/checks.
> 
> That's a good point and the kind of thing I wanted to catch by testing it in staging. This is caused by testinfo bot copying all checks from the source branch into the pull request. This copying will need to be filtered so that only the relevant jcheck checks are copied.

After testing, I realized that just filtering is insufficient for GitHub as checks in pull requests are same as checks in source commits(There is no need to copy). To display only relevant checks, we may need to store checks separately under the source commit.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Fri Feb 10 21:09:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 21:09:55 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
Message-ID: <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>

On Fri, 10 Feb 2023 20:22:31 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After testing, I realized that just filtering is insufficient for GitHub as checks in pull requests are same as checks in source commits(There is no need to copy). To display only relevant checks, we may need to store checks separately under the source commit.

Are you saying that the testinfo bot isn't needed?

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 22:04:27 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 22:04:27 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
Message-ID: <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcyKry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>

On Fri, 10 Feb 2023 21:07:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > After testing, I realized that just filtering is insufficient for GitHub as checks in pull requests are same as checks in source commits(There is no need to copy). To display only relevant checks, we may need to store checks separately under the source commit.
> 
> Are you saying that the testinfo bot isn't needed?

Sorry, what I said is confusing. What I should say is that, jcheck is not triggered by the workflow, it is triggered by Checkrun. So it is not stored in the our own fork and then be copied to the pr.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Fri Feb 10 22:15:22 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 10 Feb 2023 22:15:22 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcyKry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
 <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcy
 Kry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
Message-ID: <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>

On Fri, 10 Feb 2023 22:02:07 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Sorry, what I said is confusing. What I should say is that, jcheck is not triggered by the workflow, it is triggered by Checkrun. So it is not stored in the our own fork and then be copied to the pr.

Right, but then how did we see all the different `jcheck-<repo>-<pull>` in the "checks" tab? Is that just github showing every check related to a commit? If so, I suppose it's ok, the naming should help telling them apart.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 22:15:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 22:15:23 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
Message-ID: <X0J6CjheY3lit5D-WZHwjWa8s9hU06rGRzZVo5QYDgw=.34edc53b-752d-4529-8a1f-3e86f0abe293@github.com>

On Thu, 9 Feb 2023 22:40:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix problems

> > Sorry, what I said is confusing. What I should say is that, jcheck is not triggered by the workflow, it is triggered by Checkrun. So it is not stored in the our own fork and then be copied to the pr.
> 
> Right, but then how did we see all the different jcheck-- in the "checks" tab? Is that just github showing everything related to a commit? If so, I suppose it's ok, the naming should help telling them apart.

I think so. And this problem would happen only when we create multiple prs with same source commit in the **same** repository.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 22:20:42 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 22:20:42 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
 <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcy
 Kry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
 <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>
Message-ID: <x3i8fga0B3GrpAxZVke_fEI3p40c880ap2_1RlA142c=.7bbeb344-631f-43a5-ab0e-dc39a3ab5ab2@github.com>

On Fri, 10 Feb 2023 22:11:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Sorry, what I said is confusing. What I should say is that, jcheck is not triggered by the workflow, it is triggered by Checkrun. So it is not stored in the our own fork and then be copied to the pr.
> 
> Right, but then how did we see all the different `jcheck-<repo>-<pull>` in the "checks" tab? Is that just github showing every check related to a commit? If so, I suppose it's ok, the naming should help telling them apart.

My test yesterday is not very good. I  created multiple pull requests with the same source commit within a single repository, whereas the problem this patch was intended to address was creating multiple pull requests with the same source commit in different repositories.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Fri Feb 10 22:27:23 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 10 Feb 2023 22:27:23 GMT
Subject: Integrated: 1725: Clarify "no known role" error message
In-Reply-To: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
References: <b8NQmIvzi0nIur9WEI4ImwexRLjPghvAU-Ow8ZxanNI=.b33e3040-3696-4dc3-821d-3a61a1d5ecdd@github.com>
Message-ID: <l5-hzCEMoBnvv5clqmLGIUWyOi0LaHO0SbQksPiGC84=.00417d58-a5d5-414b-b6f8-d933ac9894f3@github.com>

On Thu, 19 Jan 2023 22:27:09 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: 
> 
> (no known github.com user name / role) 
> 
> What it actually means is "no known OpenJDK user name / role".
> 
> Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal.

This pull request has now been integrated.

Changeset: 33b3cc32
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/33b3cc328d16307a43303b4b4f0c6bb10951c31e
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

1725: Clarify "no known role" error message

Reviewed-by: gli, erikj

-------------

PR: https://git.openjdk.org/skara/pull/1459

From gli at openjdk.org  Sat Feb 11 12:19:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 11 Feb 2023 12:19:48 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v2]
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Filter the comments in method ArchiveWorkItem#ignoreComment

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1469/files
  - new: https://git.openjdk.org/skara/pull/1469/files/cdcfe380..11704271

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=00-01

  Stats: 137 lines in 11 files changed: 122 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/skara/pull/1469.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1469/head:pull/1469

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Sat Feb 11 12:29:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 11 Feb 2023 12:29:48 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v2]
In-Reply-To: <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <HAspZqwKJeSRIXH1Lpwudf50OiPZ6OBuhFlnJa-ebwc=.b908d4e4-4e65-48d8-8157-369637f25268@github.com>
 <Z8udKb9_wSDE7hM8xR1EbCnYLk5GhF0KaLt1SKzpG1U=.bd13a364-4a7e-44fd-b71b-431e12a4d7f7@github.com>
 <BvtaCqsSRnCXpv5dUyMk5Ieq7dtwGU37jMa_MbQw318=.8c0f2cac-322f-4809-8933-a13e82d7e0bf@github.com>
Message-ID: <CWhGdXekWW3THXqRv9YK6Qn48Kz4Zvny8q0Es1Vg4O4=.1574784f-9216-4e7d-8769-cf5582c177fa@github.com>

On Fri, 10 Feb 2023 17:42:16 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Thinking about this some more, this simple solution has a pretty big drawback. There is no actual synchronization between events. All bot actions are asynchronous. Imagine the following scenario.
> 
> 1. User posts comment "I'm putting this PR in draft to work on the feedback"
> 2. User puts PR in draft
> 3. mlbridge bot processes PR, finds it in draft and does nothing
> 4. User removes draft state
> 5. mlbridge bot processes PR, finds new comment from 1 and posts it.
> 
> For this to work correctly, draft PRs still need to be processed by mlbridge, and any events up until the draft state change need to be processed as usual.
> 
> This is still possibly better than what we have, but I'm not sure. Opinions?

Good Caught. This is a case we need to solve.

I updated the code just now, which ignores the comments in method `ArchiveWorkItem#ignoreComment`
instead of filtering the draft PRs in method `MailingListBridgeBot#getPeriodicItems`.

In order to get the time when the PR was last marked as draft, I add a new API `lastMarkedAsDraftTime` to `PullRequest` 
and implement it in the sub-classes. The related tests about this new case and the new API are also added.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Sat Feb 11 13:13:34 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 11 Feb 2023 13:13:34 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <vQWjIJ--8IJHyYH5I-YYPC4e6cP-ZSSYMQgqH7u3u2E=.1e67a263-e640-45ed-91b0-4dfb027f35e3@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <A67CYpT9xiKSoQ4f9Ailw_uoKIkAuXBw-bbmrmTsd-8=.d2799052-8981-4598-bfc8-2552d519dc04@github.com>
 <vQWjIJ--8IJHyYH5I-YYPC4e6cP-ZSSYMQgqH7u3u2E=.1e67a263-e640-45ed-91b0-4dfb027f35e3@github.com>
Message-ID: <t2aWpwN85tcP2rtjOvFq25BGgKIxDbS5U3p3rUtv1_Q=.7f323d95-e667-42a6-a954-270a1d342b27@github.com>

On Fri, 10 Feb 2023 14:18:13 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Because there is no concept of a "check" in GitLab. We just store the check results in a comment in the PR, so there is no reason to make the name of the check unique.

Thanks for the explanation.

> Until now my opinion was that the name of the jcheck check was something only the pull request bot module needed to know about, so putting that on the `PullRequest` interface didn't seem right. It was an implementation detail. But now since we need to share this information with testinfo, it would make sense to push this logic into `PullRequest`. The default method should in that case return "jcheck" and `GitHubPullRequest` can have the special implementation needed only on GitHub.

I understand what you considered. The name is indeed only used in PR bot. So now I think the current code is also okay.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Mon Feb 13 14:17:46 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 14:17:46 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <x3i8fga0B3GrpAxZVke_fEI3p40c880ap2_1RlA142c=.7bbeb344-631f-43a5-ab0e-dc39a3ab5ab2@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
 <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcy
 Kry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
 <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>
 <x3i8fga0B3GrpAxZVke_fEI3p40c880ap2_1RlA142c=.7bbeb344-631f-43a5-ab0e-dc39a3ab5ab2@github.com>
Message-ID: <GOUJ2PUDtF2Zxm7PiBPpdT5u4UQobEwmfHwhEI2XER8=.049566ac-6bf3-4a9f-9f46-e1058a0a2a72@github.com>

On Fri, 10 Feb 2023 22:18:31 GMT, Zhao Song <zsong at openjdk.org> wrote:

> My test yesterday is not very good. I created multiple pull requests with the same source commit within a single repository, whereas the problem this patch was intended to address was creating multiple pull requests with the same source commit in different repositories.

I would say the intention is to handle both situations.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Mon Feb 13 18:14:05 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 13 Feb 2023 18:14:05 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v2]
In-Reply-To: <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>
Message-ID: <YhmbFvstOhy8_TA0WzZSKcz0pa34CIPMKLd8_sF8n90=.ec7d7a3c-88da-4412-b605-4c370b5fc05f@github.com>

On Sat, 11 Feb 2023 12:19:48 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Filter the comments in method ArchiveWorkItem#ignoreComment

Now, I could remember that my implementation of [SKARA-1683](https://github.com/openjdk/skara/pull/1426) shares the same issue with Li's first version.  I had previously mentioned in that pr "My current implementation has a bug. If a user force-pushes or rebases when the pr is in ready state, and then he converts the pr to draft state very quickly, in such a case, our pullRequestBot won't have enough time to send warning, and then user will never get the notification of this force-push or rebase.". I will fix this issue later this week .

-------------

PR: https://git.openjdk.org/skara/pull/1469

From erikj at openjdk.org  Mon Feb 13 19:18:14 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 19:18:14 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v2]
In-Reply-To: <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>
Message-ID: <Kxn1iPJ1T_aygymG2zHFgjtItqXNcQCQMSOT-K4kpN8=.2c49e558-b474-4439-9382-c5b2c4248259@github.com>

On Sat, 11 Feb 2023 12:19:48 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Filter the comments in method ArchiveWorkItem#ignoreComment

This looks pretty good, but see comments. Were you able to run the manual tests to verify the new methods on PullRequest?

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 144:

> 142:         // after the last converted time should be ignored.
> 143:         if (pr.isDraft()) {
> 144:             var lastDraftTime = pr.lastMarkedAsDraftTime();

This method gets called for every comment on the PR, every time `ArchiveWorkItem` is run for a PR. The result of `pr.lastMarkedAsDraftTime()` needs to be retrieved once and reused.

forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 712:

> 710:                 .filter(obj -> obj.contains("event"))
> 711:                 .filter(obj -> obj.get("event").asString().equals("convert_to_draft"))
> 712:                 .reduce((a, b) -> b)

Are you sure of the order events are returned in? I couldn't find a definition of the order. Maybe safer to map to date and reduce to the highest one?

forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 792:

> 790:                 .filter(obj -> obj.get("system").asBoolean())
> 791:                 .filter(obj -> draftMessage.equals(obj.get("body").asString()))
> 792:                 .reduce((a, b) -> a)

Same here as for GitHub, maybe reduce to highest date just to be safe?

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Mon Feb 13 21:13:18 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 13 Feb 2023 21:13:18 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <GOUJ2PUDtF2Zxm7PiBPpdT5u4UQobEwmfHwhEI2XER8=.049566ac-6bf3-4a9f-9f46-e1058a0a2a72@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
 <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcy
 Kry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
 <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>
 <x3i8fga0B3GrpAxZVke_fEI3p40c880ap2_1RlA142c=.7bbeb344-631f-43a5-ab0e-dc39a3ab5ab2@github.com>
 <GOUJ2PUDtF2Zxm7PiBPpdT5u4UQobEwmfHwhEI2XER8=.049566ac-6bf3-4a9f-9f46-e1058a0a2a72@github.com>
Message-ID: <LuXwQoIkvm8mG0IursDic0J5KxyYlkIVbEQWA9Qdj-U=.4f8b783b-236c-4767-bd04-61e6951b135a@github.com>

On Mon, 13 Feb 2023 14:15:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > My test yesterday is not very good. I created multiple pull requests with the same source commit within a single repository, whereas the problem this patch was intended to address was creating multiple pull requests with the same source commit in different repositories.
> 
> I would say the intention is to handle both situations.

Yes, seems like that checks cannot be stored within a specific PR and must instead be stored in a specific commit. I also reviewed the GitHub documentation, it seems that it is not possible to hide certain checks within a PR. I am afraid that I am unable to improve the current code, however, I believe that it will work correctly. The names of the checks will indicate to the user which one is associated with the PR, and only the relevant check will have impact. Checks from other PRs will not be an integrationBlocker for this PR.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From zsong at openjdk.org  Mon Feb 13 21:21:47 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 13 Feb 2023 21:21:47 GMT
Subject: RFR: 1818: Get rid of extra REST request in GitLabMergeRequest#author
Message-ID: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>

Currently, in GitLabMergeRequest#author, the bot makes an unnecessary REST request to retrieve the HostUser object. 
However, with recent advancements in GitLab, it's possible to parse the HostUser directly from the pull request JSON. 
Getting rid of this redundant REST request would also solve the 'user is inactive' issue.

-------------

Commit messages:
 - SKARA-1818

Changes: https://git.openjdk.org/skara/pull/1471/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1471&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1818
  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1471.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1471/head:pull/1471

PR: https://git.openjdk.org/skara/pull/1471

From erikj at openjdk.org  Mon Feb 13 21:25:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 21:25:09 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
Message-ID: <EnSmnpUENBQ_OHbZjxjS59zTnYqLIZgqXnVBQy_lb28=.4305d3a7-3dd7-4ed3-9c73-38cc6668d58c@github.com>

On Thu, 9 Feb 2023 22:40:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix problems

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Mon Feb 13 21:25:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 21:25:09 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <LuXwQoIkvm8mG0IursDic0J5KxyYlkIVbEQWA9Qdj-U=.4f8b783b-236c-4767-bd04-61e6951b135a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
 <aaC4r0vNRjKpLFXalm8UZIjswI9z2klvV9t0uGEMhPY=.96253f29-c9c4-4c29-b69d-ca262deaf87d@github.com>
 <35IHg8X2sJHV-f9H8ET_TvazkSq7oYa3TNDn3uWBBpM=.f871346c-14cf-470f-9437-466c881dd3d3@github.com>
 <gV8_GWrQwyjZo4V324PD0riOViTDIbyaYzngeOfOTq8=.2506d576-232e-4db3-bc7b-52839cb6db60@github.com>
 <vXd4v9Wa2rrSqwp6OGeIpy67jnYCzIkOFM9Z-zfgSMM=.0c6b1dd1-ee41-4570-8936-a7ec66a44a42@github.com>
 <b-x8TRasRd2qvcBmdjrP1couRBsckUdXZ2yzE19YWwI=.130f97d5-7c2c-4c1e-827f-f13c3b1ab590@github.com>
 <jakbO6349-kQ_lgRETc8JyOej2kJk7Bk1viV3X4O048=.34ea40df-01b8-4140-85d2-fdd726fd57b8@github.com>
 <P7Ms2i1_J14qzFblsFC8hDPUCk6CwdYzF6GVJ4U3PkE=.7fb5c263-2b71-4cf4-88d5-50412d68566d@github.com>
 <_rxNyMx84TJOUUWzMuccBnBZdaQ97eN4w7LIa346D9g=.74a5073b-ea1d-485a-8fd5-446f039337dc@github.com>
 <iW3P7LJgwuA7XFuxVGtlP2JtgtPgXvMRqcy
 Kry9auaE=.9d2c1c6c-1bbe-4b93-a044-b4bad355d7e4@github.com>
 <lVl3ak3hrKelGwyhjddxQ9wHDGv6tvoeiz3lYxjjWzo=.3caa76b3-9aa7-4d23-bd50-e5b214bcc321@github.com>
 <x3i8fga0B3GrpAxZVke_fEI3p40c880ap2_1RlA142c=.7bbeb344-631f-43a5-ab0e-dc39a3ab5ab2@github.com>
 <GOUJ2PUDtF2Zxm7PiBPpdT5u4UQobEwmfHwhEI2XER8=.049566ac-6bf3-4a9f-9f46-e1058a0a2a72@github.com>
 <LuXwQoIkvm8mG0IursDic0J5KxyYlkIVbEQWA9Qdj-U=.4f8b783b-236c-4767-bd04-61e6951b135a@github.com>
Message-ID: <CL44VqCa_BXWzBAZC1Azs9pSQt9Dc0drqSRdNM-fwT0=.bf0b8b5c-dc19-4f13-9e26-19e9b5bf5247@github.com>

On Mon, 13 Feb 2023 21:11:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > I would say the intention is to handle both situations.
> 
> Yes, seems like that checks cannot be stored within a specific PR and must instead be stored in a specific commit. I also reviewed the GitHub documentation, it seems that it is not possible to hide certain checks within a PR. I am afraid that I am unable to improve the current code, however, I believe that it will work correctly. The names of the checks will indicate to the user which one is associated with the PR, and only the relevant check will have impact. Checks from other PRs will not be an integrationBlocker for this PR.

Then I think this looks good.

-------------

PR: https://git.openjdk.org/skara/pull/1470

From erikj at openjdk.org  Mon Feb 13 22:28:10 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 22:28:10 GMT
Subject: RFR: 1818: Get rid of extra REST request in
 GitLabMergeRequest#author
In-Reply-To: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
References: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
Message-ID: <ubUk0a-iwRgRaIntAHjqmq7lg-pX49vrwSyu7YYkYTY=.92ef238a-4a7f-4d99-92ff-fa6509ee86f0@github.com>

On Mon, 13 Feb 2023 21:01:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, in GitLabMergeRequest#author, the bot makes an unnecessary REST request to retrieve the HostUser object. 
> However, with recent advancements in GitLab, it's possible to parse the HostUser directly from the pull request JSON. 
> Getting rid of this redundant REST request would also solve the 'user is inactive' issue.

forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 85:

> 83:     @Override
> 84:     public HostUser author() {
> 85:         return host.parseAuthorField(json);

Did you test this? I would assume you need something like this:
Suggestion:

        return host.parseAuthorField(json.get("author"));

-------------

PR: https://git.openjdk.org/skara/pull/1471

From zsong at openjdk.org  Mon Feb 13 22:33:11 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 13 Feb 2023 22:33:11 GMT
Subject: RFR: 1818: Get rid of extra REST request in
 GitLabMergeRequest#author
In-Reply-To: <ubUk0a-iwRgRaIntAHjqmq7lg-pX49vrwSyu7YYkYTY=.92ef238a-4a7f-4d99-92ff-fa6509ee86f0@github.com>
References: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
 <ubUk0a-iwRgRaIntAHjqmq7lg-pX49vrwSyu7YYkYTY=.92ef238a-4a7f-4d99-92ff-fa6509ee86f0@github.com>
Message-ID: <MyAJTX0oKl5z_V1P4s_VDZFsSm_x755vCrcHJHE7_do=.c37ab689-9bb5-430e-9b1f-9837b73301ea@github.com>

On Mon, 13 Feb 2023 22:26:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, in GitLabMergeRequest#author, the bot makes an unnecessary REST request to retrieve the HostUser object. 
>> However, with recent advancements in GitLab, it's possible to parse the HostUser directly from the pull request JSON. 
>> Getting rid of this redundant REST request would also solve the 'user is inactive' issue.
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 85:
> 
>> 83:     @Override
>> 84:     public HostUser author() {
>> 85:         return host.parseAuthorField(json);
> 
> Did you test this? I would assume you need something like this:
> Suggestion:
> 
>         return host.parseAuthorField(json.get("author"));

Yes, I tested it. We don't need to get author here. Because we get author in this method.


    HostUser parseAuthorField(JSONValue json) {
        return parseAuthorObject(json.get("author").asObject());
    }

-------------

PR: https://git.openjdk.org/skara/pull/1471

From erikj at openjdk.org  Mon Feb 13 22:45:50 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 22:45:50 GMT
Subject: RFR: 1818: Get rid of extra REST request in
 GitLabMergeRequest#author
In-Reply-To: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
References: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
Message-ID: <koX6GlZ_BCyMQ4Vd9rLFuSUifvkS1ONdd_JnhpE1Puk=.1b37b59a-13ea-4123-90d1-1feadabbdd6f@github.com>

On Mon, 13 Feb 2023 21:01:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, in GitLabMergeRequest#author, the bot makes an unnecessary REST request to retrieve the HostUser object. 
> However, with recent advancements in GitLab, it's possible to parse the HostUser directly from the pull request JSON. 
> Getting rid of this redundant REST request would also solve the 'user is inactive' issue.

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1471

From erikj at openjdk.org  Mon Feb 13 22:45:50 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 13 Feb 2023 22:45:50 GMT
Subject: RFR: 1818: Get rid of extra REST request in
 GitLabMergeRequest#author
In-Reply-To: <MyAJTX0oKl5z_V1P4s_VDZFsSm_x755vCrcHJHE7_do=.c37ab689-9bb5-430e-9b1f-9837b73301ea@github.com>
References: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
 <ubUk0a-iwRgRaIntAHjqmq7lg-pX49vrwSyu7YYkYTY=.92ef238a-4a7f-4d99-92ff-fa6509ee86f0@github.com>
 <MyAJTX0oKl5z_V1P4s_VDZFsSm_x755vCrcHJHE7_do=.c37ab689-9bb5-430e-9b1f-9837b73301ea@github.com>
Message-ID: <RtZ1Sb6BHVK-FWwho-T7HhrlYsvnmPSAlr9LiiEqM4w=.b2ae8f10-95c8-4fac-a010-11b965d53f2c@github.com>

On Mon, 13 Feb 2023 22:31:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 85:
>> 
>>> 83:     @Override
>>> 84:     public HostUser author() {
>>> 85:         return host.parseAuthorField(json);
>> 
>> Did you test this? I would assume you need something like this:
>> Suggestion:
>> 
>>         return host.parseAuthorField(json.get("author"));
>
> Yes, I tested it. We don't need to get author here. Because we get author in this method.
> 
> 
>     HostUser parseAuthorField(JSONValue json) {
>         return parseAuthorObject(json.get("author").asObject());
>     }

Oh, right, I misread the method name. Yes, that should work.

-------------

PR: https://git.openjdk.org/skara/pull/1471

From zsong at openjdk.org  Mon Feb 13 23:00:17 2023
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 13 Feb 2023 23:00:17 GMT
Subject: Integrated: 1818: Get rid of extra REST request in
 GitLabMergeRequest#author
In-Reply-To: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
References: <KkdysccxjLM8dm2CGI8N9849FFxwtretmx5n4nMrChE=.eaf2c1fc-257e-41ca-afc8-0ef12371513c@github.com>
Message-ID: <VJEUDqdVPBZBmKBdmq1RaUdc1M4DvxPWVM9TCUeHF2I=.2243cbbc-5bda-457d-b974-4a7abd387969@github.com>

On Mon, 13 Feb 2023 21:01:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, in GitLabMergeRequest#author, the bot makes an unnecessary REST request to retrieve the HostUser object. 
> However, with recent advancements in GitLab, it's possible to parse the HostUser directly from the pull request JSON. 
> Getting rid of this redundant REST request would also solve the 'user is inactive' issue.

This pull request has now been integrated.

Changeset: 5b209c62
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/5b209c62e2e18e9951711972413ae5d239553aa5
Stats:     7 lines in 1 file changed: 0 ins; 6 del; 1 mod

1818: Get rid of extra REST request in GitLabMergeRequest#author

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1471

From zsong at openjdk.org  Tue Feb 14 00:11:14 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 14 Feb 2023 00:11:14 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests' in
 GitLab
Message-ID: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>

Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

-------------

Commit messages:
 - SKARA-1817

Changes: https://git.openjdk.org/skara/pull/1472/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1472&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1817
  Stats: 28 lines in 4 files changed: 22 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/skara/pull/1472.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1472/head:pull/1472

PR: https://git.openjdk.org/skara/pull/1472

From zsong at openjdk.org  Tue Feb 14 00:13:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 14 Feb 2023 00:13:35 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
Message-ID: <fdCiewUSTTvW-M2_lzE78OR2uEoQlYxtcHcq4myVIDQ=.f29cbb6e-7e1a-43af-b698-90b1b9b47251@github.com>

On Mon, 13 Feb 2023 22:56:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 117:

> 115:                         .body("source_branch", sourceRef)
> 116:                         .body("target_branch", targetRef)
> 117:                         .body("title", (draft ? "Draft: " : "") + title)

During my test, I was surprised that when `draft` is true, the title will be "Draft: " without the real title. Seems like priority of operators is a little weird. `+` is greater than `?:`.

-------------

PR: https://git.openjdk.org/skara/pull/1472

From gli at openjdk.org  Tue Feb 14 07:43:07 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 07:43:07 GMT
Subject: RFR: 1706: Store github checks in PR unique way [v2]
In-Reply-To: <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
 <foLRZrcZOwwL7uc-uoeoIIH5GPgsfqLfD_aLRIjXj-A=.8bf8e0d7-e727-44a4-a979-e334227b5357@github.com>
Message-ID: <-az9kZsdYxpUPmOLG7qKtWauey5IJeWrQhM8drGv5xU=.462c90a9-8a0f-4021-ba8c-fac2a7aa89db@github.com>

On Thu, 9 Feb 2023 22:40:42 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>>  
>> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix problems

Marked as reviewed by gli (Committer).

-------------

PR: https://git.openjdk.org/skara/pull/1470

From gli at openjdk.org  Tue Feb 14 09:01:32 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 09:01:32 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v3]
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <lCP1tIVF0laNgIlPRiqbUbqtbfSLGoeaUxjImIqP_0U=.2adb95c2-d8d2-4176-bdfc-0ea5ca5eea81@github.com>

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Move the last draft invocation out of the method 'ignoreComment'. Adjust the API implementation.

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1469/files
  - new: https://git.openjdk.org/skara/pull/1469/files/11704271..2d139bce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=01-02

  Stats: 11 lines in 3 files changed: 1 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/skara/pull/1469.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1469/head:pull/1469

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Tue Feb 14 09:01:33 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 09:01:33 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v2]
In-Reply-To: <Kxn1iPJ1T_aygymG2zHFgjtItqXNcQCQMSOT-K4kpN8=.2c49e558-b474-4439-9382-c5b2c4248259@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <v6wWd2uepX8y5cvnTsB5ywIElvnL3eihd1pfYr_98eg=.e725cb16-f214-4e12-8c6b-a8dec903901c@github.com>
 <Kxn1iPJ1T_aygymG2zHFgjtItqXNcQCQMSOT-K4kpN8=.2c49e558-b474-4439-9382-c5b2c4248259@github.com>
Message-ID: <tK_vZWWgRrPx3w4Lgn6EiKsnHcCqa-_5QXup33zBsgs=.31b658a5-d2c2-4227-b1cc-c838291e17aa@github.com>

On Mon, 13 Feb 2023 19:15:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Were you able to run the manual tests to verify the new methods on PullRequest?

I had run the manual tests locally. Everything looks fine.

> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveWorkItem.java line 144:
> 
>> 142:         // after the last converted time should be ignored.
>> 143:         if (pr.isDraft()) {
>> 144:             var lastDraftTime = pr.lastMarkedAsDraftTime();
> 
> This method gets called for every comment on the PR, every time `ArchiveWorkItem` is run for a PR. The result of `pr.lastMarkedAsDraftTime()` needs to be retrieved once and reused.

I move `pr.lastMarkedAsDraftTime()` to the method `ArchiveWorkItem#run` to avoid the duplicated invocation.

> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 712:
> 
>> 710:                 .filter(obj -> obj.contains("event"))
>> 711:                 .filter(obj -> obj.get("event").asString().equals("convert_to_draft"))
>> 712:                 .reduce((a, b) -> b)
> 
> Are you sure of the order events are returned in? I couldn't find a definition of the order. Maybe safer to map to date and reduce to the highest one?

I can't find the related document too. I tried the rest api to get the related data and found the order personally. Now I adjust the code to find the highest one to avoid the API result changes in the future.

> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabMergeRequest.java line 792:
> 
>> 790:                 .filter(obj -> obj.get("system").asBoolean())
>> 791:                 .filter(obj -> draftMessage.equals(obj.get("body").asString()))
>> 792:                 .reduce((a, b) -> a)
> 
> Same here as for GitHub, maybe reduce to highest date just to be safe?

Same as above and also adjust it.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From ihse at openjdk.org  Tue Feb 14 09:07:57 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 09:07:57 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
Message-ID: <cyVPM_pZoRlHvDpapfUH3Ic1urtklJT8m-_lnSA2GWw=.a0e3809b-d3e5-437b-a81a-d687a9cd6b91@github.com>

On Mon, 13 Feb 2023 22:56:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/skara/pull/1472

From gli at openjdk.org  Tue Feb 14 09:07:57 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 09:07:57 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
Message-ID: <R6077N4wG_wCy66hqmlcRYSx0sKkNHGHfLAfd9Dofyw=.695e8d3e-4d91-4654-9501-49d2e774db3f@github.com>

On Mon, 13 Feb 2023 22:56:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

Marked as reviewed by gli (Committer).

-------------

PR: https://git.openjdk.org/skara/pull/1472

From ihse at openjdk.org  Tue Feb 14 09:07:58 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 14 Feb 2023 09:07:58 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <fdCiewUSTTvW-M2_lzE78OR2uEoQlYxtcHcq4myVIDQ=.f29cbb6e-7e1a-43af-b698-90b1b9b47251@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
 <fdCiewUSTTvW-M2_lzE78OR2uEoQlYxtcHcq4myVIDQ=.f29cbb6e-7e1a-43af-b698-90b1b9b47251@github.com>
Message-ID: <oYNm3UaIgfXNcQ8TJxA_56tEIbZnQ5G6qWBHQH8qQqY=.4573c00e-7005-4c05-b1ec-e6bd02fd5016@github.com>

On Tue, 14 Feb 2023 00:11:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 117:
> 
>> 115:                         .body("source_branch", sourceRef)
>> 116:                         .body("target_branch", targetRef)
>> 117:                         .body("title", (draft ? "Draft: " : "") + title)
> 
> During my test, I was surprised that when `draft` is true, the title will be "Draft: " without the real title. Seems like priority of operators is a little weird. `+` is greater than `?:`.

I think `?:` has one of the lowest precedents in C-like languages. If you think of it more like an "if" construct, it kind of make sense. But nicely spotted, anyway!

-------------

PR: https://git.openjdk.org/skara/pull/1472

From gli at openjdk.org  Tue Feb 14 09:07:58 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 09:07:58 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <oYNm3UaIgfXNcQ8TJxA_56tEIbZnQ5G6qWBHQH8qQqY=.4573c00e-7005-4c05-b1ec-e6bd02fd5016@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
 <fdCiewUSTTvW-M2_lzE78OR2uEoQlYxtcHcq4myVIDQ=.f29cbb6e-7e1a-43af-b698-90b1b9b47251@github.com>
 <oYNm3UaIgfXNcQ8TJxA_56tEIbZnQ5G6qWBHQH8qQqY=.4573c00e-7005-4c05-b1ec-e6bd02fd5016@github.com>
Message-ID: <ufxjIHNUh-Cc8DUww4VdIbY0Zq3VNhTw7Dp18DI8L44=.9448b0ab-82c2-4940-a4fe-4fce4460fcb6@github.com>

On Tue, 14 Feb 2023 09:02:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 117:
>> 
>>> 115:                         .body("source_branch", sourceRef)
>>> 116:                         .body("target_branch", targetRef)
>>> 117:                         .body("title", (draft ? "Draft: " : "") + title)
>> 
>> During my test, I was surprised that when `draft` is true, the title will be "Draft: " without the real title. Seems like priority of operators is a little weird. `+` is greater than `?:`.
>
> I think `?:` has one of the lowest precedents in C-like languages. If you think of it more like an "if" construct, it kind of make sense. But nicely spotted, anyway!

Nice found.

-------------

PR: https://git.openjdk.org/skara/pull/1472

From erikj at openjdk.org  Tue Feb 14 14:11:34 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 14 Feb 2023 14:11:34 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v3]
In-Reply-To: <lCP1tIVF0laNgIlPRiqbUbqtbfSLGoeaUxjImIqP_0U=.2adb95c2-d8d2-4176-bdfc-0ea5ca5eea81@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <lCP1tIVF0laNgIlPRiqbUbqtbfSLGoeaUxjImIqP_0U=.2adb95c2-d8d2-4176-bdfc-0ea5ca5eea81@github.com>
Message-ID: <CGOIfKQgEMEC1eTsTL_GazQ15ZH4A35oezwSU7AmCSE=.7eb65029-3188-4a71-929f-9cc6c21b9724@github.com>

On Tue, 14 Feb 2023 09:01:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the last draft invocation out of the method 'ignoreComment'. Adjust the API implementation.

forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 713:

> 711:                 .filter(obj -> obj.get("event").asString().equals("convert_to_draft"))
> 712:                 .map(obj -> ZonedDateTime.parse(obj.get("created_at").asString()))
> 713:                 .reduce((a, b) -> a.isBefore(b) ? b : a);

I think this could be expressed as `max()`.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From erikj at openjdk.org  Tue Feb 14 14:14:18 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 14 Feb 2023 14:14:18 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
Message-ID: <CtzzFHCpq15t-v1ChmwHUYvO28Eo6Go-bIx5xpxeI1w=.8033a38a-94b8-480e-ade7-39942eeebd51@github.com>

On Mon, 13 Feb 2023 22:56:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1472

From gli at openjdk.org  Tue Feb 14 14:31:17 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 14:31:17 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v4]
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Use max method instead of reduce

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1469/files
  - new: https://git.openjdk.org/skara/pull/1469/files/2d139bce..4d50eaad

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1469.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1469/head:pull/1469

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Tue Feb 14 14:31:19 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 14:31:19 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v3]
In-Reply-To: <CGOIfKQgEMEC1eTsTL_GazQ15ZH4A35oezwSU7AmCSE=.7eb65029-3188-4a71-929f-9cc6c21b9724@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <lCP1tIVF0laNgIlPRiqbUbqtbfSLGoeaUxjImIqP_0U=.2adb95c2-d8d2-4176-bdfc-0ea5ca5eea81@github.com>
 <CGOIfKQgEMEC1eTsTL_GazQ15ZH4A35oezwSU7AmCSE=.7eb65029-3188-4a71-929f-9cc6c21b9724@github.com>
Message-ID: <F-0O07PSNCbLw2lHWEX3CqtgTZAg4PKxaFM7W0DFUUs=.dc6bd499-4b8c-437f-bf37-7b8e40b4195d@github.com>

On Tue, 14 Feb 2023 14:08:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the last draft invocation out of the method 'ignoreComment'. Adjust the API implementation.
>
> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 713:
> 
>> 711:                 .filter(obj -> obj.get("event").asString().equals("convert_to_draft"))
>> 712:                 .map(obj -> ZonedDateTime.parse(obj.get("created_at").asString()))
>> 713:                 .reduce((a, b) -> a.isBefore(b) ? b : a);
> 
> I think this could be expressed as `max()`.

Fixed.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From erikj at openjdk.org  Tue Feb 14 16:51:15 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 14 Feb 2023 16:51:15 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v4]
In-Reply-To: <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
Message-ID: <IpzhX5cEyJ2kVe4xurUVFZy3uwqkd-1jUWEAMluaLHo=.66dc7bf3-c404-43ef-98bf-b339c4981c82@github.com>

On Tue, 14 Feb 2023 14:31:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use max method instead of reduce

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1469

From zsong at openjdk.org  Tue Feb 14 16:58:59 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 14 Feb 2023 16:58:59 GMT
Subject: RFR: 1817: 'WIP merge requests' renamed to 'draft merge requests'
 in GitLab
In-Reply-To: <ufxjIHNUh-Cc8DUww4VdIbY0Zq3VNhTw7Dp18DI8L44=.9448b0ab-82c2-4940-a4fe-4fce4460fcb6@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
 <fdCiewUSTTvW-M2_lzE78OR2uEoQlYxtcHcq4myVIDQ=.f29cbb6e-7e1a-43af-b698-90b1b9b47251@github.com>
 <oYNm3UaIgfXNcQ8TJxA_56tEIbZnQ5G6qWBHQH8qQqY=.4573c00e-7005-4c05-b1ec-e6bd02fd5016@github.com>
 <ufxjIHNUh-Cc8DUww4VdIbY0Zq3VNhTw7Dp18DI8L44=.9448b0ab-82c2-4940-a4fe-4fce4460fcb6@github.com>
Message-ID: <UHpv_8JLNJJsWB51QeI0x_GUDxrOLietfRpSSxNgyls=.01c223b1-3984-40a0-81ba-a0bba56dfb0a@github.com>

On Tue, 14 Feb 2023 09:04:37 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> I think `?:` has one of the lowest precedents in C-like languages. If you think of it more like an "if" construct, it kind of make sense. But nicely spotted, anyway!
>
> Nice found.

> I think `?:` has one of the lowest precedents in C-like languages. If you think of it more like an "if" construct, it kind of make sense. But nicely spotted, anyway!

Make sense! Thx!

-------------

PR: https://git.openjdk.org/skara/pull/1472

From zsong at openjdk.org  Tue Feb 14 17:26:04 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 14 Feb 2023 17:26:04 GMT
Subject: Integrated: 1817: 'WIP merge requests' renamed to 'draft merge
 requests' in GitLab
In-Reply-To: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
References: <TLLAdVU8lYramp5-ZSQMX5CJ31qBtjMtxRMTWEGyUxI=.2b9eedfe-30b5-45ae-b01c-c7a1e16d7e5b@github.com>
Message-ID: <NQFKP_v93NUV7DDzGkVkUQ1DvR6Xm8xQ2wEZ_NEmRCQ=.15eaa249-3910-4465-af99-54e54d3cfcbf@github.com>

On Mon, 13 Feb 2023 22:56:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Since 'WIP' is deprecated in GitLab, we need to update methods related with 'WIP'.

This pull request has now been integrated.

Changeset: 964ff9c2
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/964ff9c2e3bdfe49c89b3c3ec2723d7d3e675aaa
Stats:     28 lines in 4 files changed: 22 ins; 1 del; 5 mod

1817: 'WIP merge requests' renamed to 'draft merge requests' in GitLab

Reviewed-by: ihse, gli, erikj

-------------

PR: https://git.openjdk.org/skara/pull/1472

From zsong at openjdk.org  Tue Feb 14 17:57:43 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 14 Feb 2023 17:57:43 GMT
Subject: Integrated: 1706: Store github checks in PR unique way
In-Reply-To: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
References: <Y2EboxNUTiMEiL0kviIpgoKrx0jqco1a31_o5ZhkzwQ=.f08d55e3-13b2-4c63-b0cb-f5ce6300903a@github.com>
Message-ID: <Ge48oyzz02nGQt1uIhDZ31WZHd1-fhr8emOnZ7ho6JE=.efd57783-d99c-4563-92e8-dc3de7f1ad23@github.com>

On Thu, 9 Feb 2023 19:13:37 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, checks in GitHub are stored in the commit. So if multiple PRs share the same source commit, then they will compete with the check-runs and store their different checksum in there. This in turn means that all, or most of those PRs will always think the check is outdated when a CheckRun is performed next.
>  
> This patch adds repository name and pull request id to the name of check in Github. Therefore, even if multiple PRs share the same source commit, every PR will store a unique check in the commit and there is no competition exists.

This pull request has now been integrated.

Changeset: 6b2d04a8
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/6b2d04a876eade36803b4a47c0b70206139f11d0
Stats:     9 lines in 3 files changed: 5 ins; 0 del; 4 mod

1706: Store github checks in PR unique way

Reviewed-by: erikj, gli

-------------

PR: https://git.openjdk.org/skara/pull/1470

From gli at openjdk.org  Tue Feb 14 20:42:58 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 20:42:58 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v4]
In-Reply-To: <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
Message-ID: <Fb1KkHXAGGitNEfE-TihCL74xFWj2u2b7yK9JpDOIOk=.df8e5465-2776-444c-88be-13558181689c@github.com>

On Tue, 14 Feb 2023 14:31:17 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
>> And the related test case is added.
>> 
>> Thanks for taking the time to review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use max method instead of reduce

It seems a new bug:

When a PR has become ready and then another PR, of which code conflicts with the former one, was integrated, the former PR remains ready. But actually, it should have a `merge-conflict` label and should not be ready.

This PR-1469 (SKARA-1588) has became ready and then PR-1472 (SKARA-1817) was integrated. This PR is still ready now. But actually, this PR should have a `merge-conflict` label and should not be ready (the `ready` label should be removed and the related comment aboud conflict should be added).

I suspect it is because PR bot have not been triggerred in this PR (since this PR has not been updated). This comment can update this PR and can verify my idea.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Tue Feb 14 21:20:34 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 21:20:34 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v4]
In-Reply-To: <Fb1KkHXAGGitNEfE-TihCL74xFWj2u2b7yK9JpDOIOk=.df8e5465-2776-444c-88be-13558181689c@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
 <Fb1KkHXAGGitNEfE-TihCL74xFWj2u2b7yK9JpDOIOk=.df8e5465-2776-444c-88be-13558181689c@github.com>
Message-ID: <mFkU8Q3VpgzQgIhd1A5Vhg8mKRAfY1xJfY7moIP6M9o=.f79c29d7-54b5-4d24-91ef-f675d58d9a1c@github.com>

On Tue, 14 Feb 2023 20:40:20 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> I suspect it is because PR bot have not been triggered in this PR (since this PR has not been updated). This comment can update this PR and can verify my idea.

This suspicion looks wrong now.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Tue Feb 14 21:27:09 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 21:27:09 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v5]
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <t04dRGcheR23mBSyTqmSVurJmiPRcB-sJAoYPvxbyVg=.456e337f-ad27-47a3-9035-d50fbd244245@github.com>

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into SKARA-1588
   
   # Conflicts:
   #	forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabRestApiTest.java
 - Use max method instead of reduce
 - Move the last draft invocation out of the method 'ignoreComment'. Adjust the API implementation.
 - Filter the comments in method ArchiveWorkItem#ignoreComment
 - SKARA-1588

-------------

Changes: https://git.openjdk.org/skara/pull/1469/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1469&range=04
  Stats: 257 lines in 10 files changed: 242 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/skara/pull/1469.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1469/head:pull/1469

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Tue Feb 14 21:27:10 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Feb 2023 21:27:10 GMT
Subject: RFR: 1588: Bridge messages should not be sent for PRs in draft
 state [v4]
In-Reply-To: <Fb1KkHXAGGitNEfE-TihCL74xFWj2u2b7yK9JpDOIOk=.df8e5465-2776-444c-88be-13558181689c@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
 <xFJuJSUAaBR9JyGcrK76em_binUaIp6EbH5vImynNtY=.61e345b3-3fd4-4a96-bb87-08a4f54d9401@github.com>
 <Fb1KkHXAGGitNEfE-TihCL74xFWj2u2b7yK9JpDOIOk=.df8e5465-2776-444c-88be-13558181689c@github.com>
Message-ID: <JwxDkZ5bAt3V6MTVunLoBCvLv1s9F_Ju29zfnzfEzzQ=.ea8916be-4443-4580-8bc1-e9ea344a2330@github.com>

On Tue, 14 Feb 2023 20:40:20 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> It seems a new bug:
> 
> When a PR has become ready and then another PR, of which code conflicts with the former one, was integrated, the former PR remains ready. But actually, it should have a `merge-conflict` label and should not be ready.
> 
> This PR-1469 (SKARA-1588) has became ready and then PR-1472 (SKARA-1817) was integrated. This PR is still ready now. But actually, this PR should have a `merge-conflict` label and should not be ready (the `ready` label should be removed and the related comment aboud conflict should be added).
> 
> I suspect it is because PR bot have not been triggered in this PR (since this PR has not been updated). This comment can update this PR and can verify my idea.

Filed https://bugs.openjdk.org/browse/SKARA-1820 to record it.

-------------

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Wed Feb 15 07:22:26 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 07:22:26 GMT
Subject: Integrated: 1588: Bridge messages should not be sent for PRs in draft
 state
In-Reply-To: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
References: <t-RwfMqo35pDUIYLz3ofW790ALJXnsptiOlnzQ23cjI=.71110e40-e34a-41de-a298-288245af00c2@github.com>
Message-ID: <0LwMXP22VaCECtEf_QG40bdYj_llTD7BUONqu_syk4s=.c141edbf-4fe0-4737-9e47-eb95ebb4c2ae@github.com>

On Thu, 9 Feb 2023 17:48:28 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch prevents the `mailling bridge bot` from sending emails when a PR is draft.
> And the related test case is added.
> 
> Thanks for taking the time to review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: baa4fae5
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/baa4fae50b8dcb08aceb39a546d5e70835110212
Stats:     257 lines in 10 files changed: 242 ins; 0 del; 15 mod

1588: Bridge messages should not be sent for PRs in draft state

Reviewed-by: zsong, erikj

-------------

PR: https://git.openjdk.org/skara/pull/1469

From gli at openjdk.org  Wed Feb 15 10:37:30 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 10:37:30 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the sorting
 order
Message-ID: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>

Hi all,

This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
I worry that the time complexity may change from O(N) to O(N*N), but not sure.

Thanks for the review.

Best Regards,
-- Guoxiong

-------------

Commit messages:
 - SKARA-1821

Changes: https://git.openjdk.org/skara/pull/1473/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1473&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1821
  Stats: 19 lines in 2 files changed: 15 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1473.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1473/head:pull/1473

PR: https://git.openjdk.org/skara/pull/1473

From erikj at openjdk.org  Wed Feb 15 14:07:13 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 15 Feb 2023 14:07:13 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order
In-Reply-To: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
Message-ID: <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>

On Wed, 15 Feb 2023 10:31:55 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 776:

> 774:                           var secondTime = ZonedDateTime.parse(second.get("created_at").asString());
> 775:                           return firstTime.compareTo(secondTime);
> 776:                       })

Suggestion:

                      .max(Comparator.comparing(o -> ZonedDateTime.parse(o.get("created_at").asString())))

forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 797:

> 795:                 .filter(obj -> ZonedDateTime.parse(obj.get("created_at").asString()).isAfter(lastMarkedAsReadyTime(timelineJSON)))
> 796:                 .map(obj -> ZonedDateTime.parse(obj.get("created_at").asString()))
> 797:                 .max(ZonedDateTime::compareTo);

Suggestion:

                .max(Comparator.naturalOrder());

-------------

PR: https://git.openjdk.org/skara/pull/1473

From erikj at openjdk.org  Wed Feb 15 14:07:14 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 15 Feb 2023 14:07:14 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order
In-Reply-To: <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>
Message-ID: <UjkDmRxsbWIasLE6FApP9ILVFi-8HQwFkZTRQzMxRSM=.4a9054b4-a5ec-4a3d-a5e4-273557489627@github.com>

On Wed, 15 Feb 2023 14:02:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
>> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 776:
> 
>> 774:                           var secondTime = ZonedDateTime.parse(second.get("created_at").asString());
>> 775:                           return firstTime.compareTo(secondTime);
>> 776:                       })
> 
> Suggestion:
> 
>                       .max(Comparator.comparing(o -> ZonedDateTime.parse(o.get("created_at").asString())))

It will parse the date up to two times for each element, but I think that's ok. There shouldn't be that many of them.

-------------

PR: https://git.openjdk.org/skara/pull/1473

From gli at openjdk.org  Wed Feb 15 14:35:13 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 14:35:13 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
Message-ID: <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>

> Hi all,
> 
> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Simplify lambda expression.

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1473/files
  - new: https://git.openjdk.org/skara/pull/1473/files/8c15a216..25208e04

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1473&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1473&range=00-01

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1473.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1473/head:pull/1473

PR: https://git.openjdk.org/skara/pull/1473

From gli at openjdk.org  Wed Feb 15 14:35:16 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 14:35:16 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <UjkDmRxsbWIasLE6FApP9ILVFi-8HQwFkZTRQzMxRSM=.4a9054b4-a5ec-4a3d-a5e4-273557489627@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>
 <UjkDmRxsbWIasLE6FApP9ILVFi-8HQwFkZTRQzMxRSM=.4a9054b4-a5ec-4a3d-a5e4-273557489627@github.com>
Message-ID: <96YScvdpQ5GAytdt78zBMCcJXS5s4v5oqv8XK-oSscQ=.4ee8c2d3-c697-4cfd-989f-f7d6ec5d1b83@github.com>

On Wed, 15 Feb 2023 14:03:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 776:
>> 
>>> 774:                           var secondTime = ZonedDateTime.parse(second.get("created_at").asString());
>>> 775:                           return firstTime.compareTo(secondTime);
>>> 776:                       })
>> 
>> Suggestion:
>> 
>>                       .max(Comparator.comparing(o -> ZonedDateTime.parse(o.get("created_at").asString())))
>
> It will parse the date up to two times for each element, but I think that's ok. There shouldn't be that many of them.

Fixed.

-------------

PR: https://git.openjdk.org/skara/pull/1473

From gli at openjdk.org  Wed Feb 15 14:35:16 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 14:35:16 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <DTn0sRjgkYMLVHrSivyYNdQatQYrBleehg5wEviGRIw=.b182e750-8a55-4b1c-8b0c-2ba35bf3ca85@github.com>
Message-ID: <VHck1wCVfk0BgpiAkVEth8PIXW5VggtZCHS4pRFyIEQ=.9eaeda54-88ed-4fb9-9a92-12f07c7c9ec8@github.com>

On Wed, 15 Feb 2023 14:04:25 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify lambda expression.
>
> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 797:
> 
>> 795:                 .filter(obj -> ZonedDateTime.parse(obj.get("created_at").asString()).isAfter(lastMarkedAsReadyTime(timelineJSON)))
>> 796:                 .map(obj -> ZonedDateTime.parse(obj.get("created_at").asString()))
>> 797:                 .max(ZonedDateTime::compareTo);
> 
> Suggestion:
> 
>                 .max(Comparator.naturalOrder());

Fixed.

-------------

PR: https://git.openjdk.org/skara/pull/1473

From ihse at openjdk.org  Wed Feb 15 14:49:39 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 15 Feb 2023 14:49:39 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
Message-ID: <dcB6O2k-YHnSLQJApDfvNRFk_kQiBWOFZ7Ww4VC2Yec=.abf50013-7458-478f-8f1e-13ee366ba3ad@github.com>

On Wed, 15 Feb 2023 14:35:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
>> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify lambda expression.

LGTM

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/skara/pull/1473

From erikj at openjdk.org  Wed Feb 15 15:22:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 15 Feb 2023 15:22:42 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
Message-ID: <2i93XB145z-K-urEcc6q-wXoaKmXZVhQxfzvm-99xrs=.0688868b-0249-49e4-9c2a-9df28669bad8@github.com>

On Wed, 15 Feb 2023 14:35:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
>> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify lambda expression.

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1473

From gli at openjdk.org  Wed Feb 15 16:13:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 16:13:48 GMT
Subject: RFR: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order [v2]
In-Reply-To: <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
 <_cOZAvj2cygeYrpBp3mtngxc2Hufh9tA3yZQXU2GCtM=.ecb6f36a-ae85-4d51-8d08-2f5fcae9e1c7@github.com>
Message-ID: <IMHtDkKN499wVs-iJpSOPdeqAZeXIwwY2ZlQ0godmmU=.cf372fba-8a76-491d-b3c8-048d51495aca@github.com>

On Wed, 15 Feb 2023 14:35:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
>> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
>> 
>> Thanks for the review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify lambda expression.

Thanks for the review.

-------------

PR: https://git.openjdk.org/skara/pull/1473

From gli at openjdk.org  Wed Feb 15 16:13:48 2023
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 15 Feb 2023 16:13:48 GMT
Subject: Integrated: 1821: The 'timeline` API in GitHub doesn't point out the
 sorting order
In-Reply-To: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
References: <G8hPRMdtAw8uZNJ6rbfufYXl4I0xKdIcH5-M3fOQjR8=.e11d5312-a727-4b69-8d92-a1ede8da5802@github.com>
Message-ID: <ewYy-ftnQU7MuYHDzdLMrq0EW3nC0W0eM65H7EfFLJA=.411d93f8-3a47-43a4-9eaf-c13f3a14dc2a@github.com>

On Wed, 15 Feb 2023 10:31:55 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This patch adjusts the code to avoid GitHub changing the sorting order of the `timeline` API in the future.
> I worry that the time complexity may change from O(N) to O(N*N), but not sure.
> 
> Thanks for the review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: d6825bf2
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/d6825bf279798c43d6c824c64fe0c1f6be5e9a7b
Stats:     15 lines in 2 files changed: 11 ins; 1 del; 3 mod

1821: The 'timeline` API in GitHub doesn't point out the sorting order

Reviewed-by: ihse, erikj

-------------

PR: https://git.openjdk.org/skara/pull/1473

From duke at openjdk.org  Wed Feb 15 21:18:49 2023
From: duke at openjdk.org (vijayk22oracle)
Date: Wed, 15 Feb 2023 21:18:49 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos
Message-ID: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>

SKARA-1035: Race when creating backports for bug spanning multiple repos

-------------

Commit messages:
 - SKARA-1035: Race when creating backports for bug spanning multiple repos
 - SKARA-1035: Race when creating backports for bug spanning multiple repos

Changes: https://git.openjdk.org/skara/pull/1474/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1474&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1035
  Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1474.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1474/head:pull/1474

PR: https://git.openjdk.org/skara/pull/1474

From duke at openjdk.org  Wed Feb 15 21:44:51 2023
From: duke at openjdk.org (vijayk22oracle)
Date: Wed, 15 Feb 2023 21:44:51 GMT
Subject: Withdrawn: 1035: Race when creating backports for bug spanning
 multiple repos
In-Reply-To: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>
References: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>
Message-ID: <xQPxA3Wq8LM1jGcgehAaIMJ4znwszVxBW68u4Omk-KY=.ef632df6-5781-4721-8897-e6d709e39f5f@github.com>

On Wed, 15 Feb 2023 21:14:57 GMT, vijayk22oracle <duke at openjdk.org> wrote:

> SKARA-1035: Race when creating backports for bug spanning multiple repos

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/skara/pull/1474

From duke at openjdk.org  Wed Feb 15 22:56:49 2023
From: duke at openjdk.org (vijayk22oracle)
Date: Wed, 15 Feb 2023 22:56:49 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>
References: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>
Message-ID: <u7mclMze8f2DnH7_W7lPNeTtEtMLYXIph3rgb0HA5bo=.5568e1f1-82c2-403a-a05f-61b9bb1d8288@github.com>

> SKARA-1035: Race when creating backports for bug spanning multiple repos

vijayk22oracle has updated the pull request incrementally with two additional commits since the last revision:

 - Merge master
 - Merge master

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1474/files
  - new: https://git.openjdk.org/skara/pull/1474/files/084ba42f..51613841

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1474&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1474&range=00-01

  Stats: 4853 lines in 458 files changed: 3133 ins; 643 del; 1077 mod
  Patch: https://git.openjdk.org/skara/pull/1474.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1474/head:pull/1474

PR: https://git.openjdk.org/skara/pull/1474

From duke at openjdk.org  Wed Feb 15 23:10:40 2023
From: duke at openjdk.org (vijayk22oracle)
Date: Wed, 15 Feb 2023 23:10:40 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <u7mclMze8f2DnH7_W7lPNeTtEtMLYXIph3rgb0HA5bo=.5568e1f1-82c2-403a-a05f-61b9bb1d8288@github.com>
References: <mAZQqiR4IUJ3BZvoeWRiu1ak0ba8gz1M2c--ydr_wlo=.89a6bebd-6715-49c5-83d1-2a5626e06159@github.com>
 <u7mclMze8f2DnH7_W7lPNeTtEtMLYXIph3rgb0HA5bo=.5568e1f1-82c2-403a-a05f-61b9bb1d8288@github.com>
Message-ID: <TqmrCNk8A0boCIgNBxc92CwZqTaAyyDfK9aXiTIM35g=.7f5a6b6e-c023-47d8-b317-a962761cecca@github.com>

On Wed, 15 Feb 2023 22:56:49 GMT, vijayk22oracle <duke at openjdk.org> wrote:

>> SKARA-1035: Race when creating backports for bug spanning multiple repos
>
> vijayk22oracle has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge master
>  - Merge master

Closing the MR in favor of a cleaner one to avoid merge conflicts.

-------------

PR: https://git.openjdk.org/skara/pull/1474

From zsong at openjdk.org  Thu Feb 16 00:09:20 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 00:09:20 GMT
Subject: RFR: 1271: Webrev generation should be optional
Message-ID: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>

Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.

In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

-------------

Commit messages:
 - SKARA-1271

Changes: https://git.openjdk.org/skara/pull/1475/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1271
  Stats: 257 lines in 3 files changed: 240 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/skara/pull/1475.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1475/head:pull/1475

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 00:09:20 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 00:09:20 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>

On Thu, 16 Feb 2023 00:03:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From duke at openjdk.org  Thu Feb 16 01:48:13 2023
From: duke at openjdk.org (vijayk22oracle)
Date: Thu, 16 Feb 2023 01:48:13 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos
Message-ID: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>

SKARA-1035: Race when creating backports for bug spanning multiple repos

-------------

Commit messages:
 - SKARA-1035: Race when creating backports for bug spanning multiple repos

Changes: https://git.openjdk.org/skara/pull/1476/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1476&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1035
  Stats: 12 lines in 1 file changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1476.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1476/head:pull/1476

PR: https://git.openjdk.org/skara/pull/1476

From erikj at openjdk.org  Thu Feb 16 14:21:43 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 14:21:43 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos
In-Reply-To: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
Message-ID: <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>

On Thu, 16 Feb 2023 01:44:21 GMT, vijayk22oracle <duke at openjdk.org> wrote:

> SKARA-1035: Race when creating backports for bug spanning multiple repos

bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 310:

> 308:                                 try {
> 309:                                     issue = jbsBackport.createBackport(issue, requestedVersion, username.orElse(null), defaultSecurity(branch));
> 310:                                 } catch (Exception exp) {

Catching `Exception` is too wide a net. We need to catch `UncheckedRestException` and ideally check that the response code indicates this kind of error. Unfortunately I don't know what response that would be, so perhaps it's ok to just change the exception type for now.

Exception variables in catch statements are usually just called `e` in this codebase.

bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 313:

> 311:                                     existing = Backports.findIssue(issue, fixVersion);
> 312:                                     if (existing.isPresent()) {
> 313:                                         log.info("Race condition occurred while creating the back port. So returning an existing backport for " + issue.id() + " and requested fixVersion "

Suggestion:

                                        log.info("Race condition occurred while creating backport issue, returning the existing backport for " + issue.id() + " and requested fixVersion "

-------------

PR: https://git.openjdk.org/skara/pull/1476

From duke at openjdk.org  Thu Feb 16 17:03:58 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Thu, 16 Feb 2023 17:03:58 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
Message-ID: <3OxLLo9Zkv_ShdFEG31JefEzf8D7PIX4D0MhfW_p9xs=.e3bfde70-f9b0-4f00-8fd9-995185b6cdb1@github.com>

> SKARA-1035: Race when creating backports for bug spanning multiple repos

Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:

  Caught more specific exception in case of backport fails & updated error message.

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1476/files
  - new: https://git.openjdk.org/skara/pull/1476/files/84026657..2b7510f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1476&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1476&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/skara/pull/1476.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1476/head:pull/1476

PR: https://git.openjdk.org/skara/pull/1476

From duke at openjdk.org  Thu Feb 16 17:13:27 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Thu, 16 Feb 2023 17:13:27 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
Message-ID: <etkd2zEjsjSj-gk0bosA-gJL_i_PMH5WKeQZADM6HLA=.54ce11f3-1d12-47ee-a7a9-ef11338cd7e0@github.com>

On Thu, 16 Feb 2023 14:18:50 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Caught more specific exception in case of backport fails & updated error message.
>
> bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 313:
> 
>> 311:                                     existing = Backports.findIssue(issue, fixVersion);
>> 312:                                     if (existing.isPresent()) {
>> 313:                                         log.info("Race condition occurred while creating the back port. So returning an existing backport for " + issue.id() + " and requested fixVersion "
> 
> Suggestion:
> 
>                                         log.info("Race condition occurred while creating backport issue, returning the existing backport for " + issue.id() + " and requested fixVersion "

Sure, did the rewording as suggested, thanks.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From duke at openjdk.org  Thu Feb 16 17:16:52 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Thu, 16 Feb 2023 17:16:52 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
Message-ID: <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>

On Thu, 16 Feb 2023 14:16:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Caught more specific exception in case of backport fails & updated error message.
>
> bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 310:
> 
>> 308:                                 try {
>> 309:                                     issue = jbsBackport.createBackport(issue, requestedVersion, username.orElse(null), defaultSecurity(branch));
>> 310:                                 } catch (Exception exp) {
> 
> Catching `Exception` is too wide a net. We need to catch `UncheckedRestException` and ideally check that the response code indicates this kind of error. Unfortunately I don't know what response that would be, so perhaps it's ok to just change the exception type for now.
> 
> Exception variables in catch statements are usually just called `e` in this codebase.

Yes, I agree, used the more specific exception as suggested.

Regarding the specific exception code, yes I tried to run two test cases in parallel by putting the debug points to simulate the race condition but TestHost returned 2nd issue as a new one. I guess because of two instances of TestHost (one per test case). So could not verify the exception code.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Thu Feb 16 17:25:13 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 17:25:13 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
Message-ID: <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>

On Thu, 16 Feb 2023 17:14:35 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

>> bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java line 310:
>> 
>>> 308:                                 try {
>>> 309:                                     issue = jbsBackport.createBackport(issue, requestedVersion, username.orElse(null), defaultSecurity(branch));
>>> 310:                                 } catch (Exception exp) {
>> 
>> Catching `Exception` is too wide a net. We need to catch `UncheckedRestException` and ideally check that the response code indicates this kind of error. Unfortunately I don't know what response that would be, so perhaps it's ok to just change the exception type for now.
>> 
>> Exception variables in catch statements are usually just called `e` in this codebase.
>
> Yes, I agree, used the more specific exception as suggested.
> 
> Regarding the specific exception code, yes I tried to run two test cases in parallel by putting the debug points to simulate the race condition but TestHost returned 2nd issue as a new one. I guess because of two instances of TestHost (one per test case). So could not verify the exception code.

If you are interested, I think you can add the status code to the log with method `UncheckedRestException#getStatusCode`.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Thu Feb 16 17:25:12 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 17:25:12 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <3OxLLo9Zkv_ShdFEG31JefEzf8D7PIX4D0MhfW_p9xs=.e3bfde70-f9b0-4f00-8fd9-995185b6cdb1@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <3OxLLo9Zkv_ShdFEG31JefEzf8D7PIX4D0MhfW_p9xs=.e3bfde70-f9b0-4f00-8fd9-995185b6cdb1@github.com>
Message-ID: <iBZgVZ5UBXA9WvJ-UdZCeKmSP0kmlJwg8OY8RPrejHw=.1f74f161-2a3f-4003-b769-688319338690@github.com>

On Thu, 16 Feb 2023 17:03:58 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

>> SKARA-1035: Race when creating backports for bug spanning multiple repos
>
> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Caught more specific exception in case of backport fails & updated error message.

LGTM

-------------

Marked as reviewed by zsong (Committer).

PR: https://git.openjdk.org/skara/pull/1476

From erikj at openjdk.org  Thu Feb 16 19:47:49 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 19:47:49 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>

On Thu, 16 Feb 2023 00:03:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

This looks like it solves the stated problem, but the WebrevStorage is still initiated and will still do some work, like creating directories for webrev creation. Ideally I would like that whole part of the bot be optional, but it seems really hard to achieve without having to add null checks all over the place.

I'm not sure what the best solution is here. Maybe we can introduce another `WebrevDescription.Type.NONE` and if neither kind of webrev has been configured, then `WebrevGenerator::generate` would return a `Webrevdescription` of `NONE` type. 

Another possible solution would be to have an `enabled()` method on `WebrevStorage` and wrap all uses of `webrevGenerator` in a check for that. That may get messy though, but would definitely reduce unnecessary work when webrevs are disabled.

Have you looked at `updateWebrevComment`. When webrevs are disabled, we shouldn't post that comment either.

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 315:

> 313: 
> 314:         return composeDependsOn(pr).map(line -> line + "\n\n").orElse("") +
> 315:                 "Commit messages:\n" +

// When changing this, ensure that the PR pattern in the notifier still matches

Have you verified this?

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 318:

> 316:                 formatCommitMessagesBrief(commits, commitsLink).orElse("") + "\n\n" +
> 317:                 "Changes: " + pr.changeUrl() + "\n" +
> 318:                 (webrev.uri() == null ? "" : " Webrev: " + webrev.uri().toString()) + "\n" +

I think this will create an empty line instead of the webrev URL. I think it would be better to skip the newline so we just don't print anything.

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 332:

> 330:         if (webrevs.size() > 0) {
> 331:             if (webrevs.stream().noneMatch(w -> w.uri() != null)) {
> 332:                 webrevLinks = "Webrev is disabled\n\n";

I think this should just be `""` or possibly `"\n"`, not sure.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From erikj at openjdk.org  Thu Feb 16 19:54:11 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 19:54:11 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
Message-ID: <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>

On Thu, 16 Feb 2023 00:05:55 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.

I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From erikj at openjdk.org  Thu Feb 16 20:02:12 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 20:02:12 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <3OxLLo9Zkv_ShdFEG31JefEzf8D7PIX4D0MhfW_p9xs=.e3bfde70-f9b0-4f00-8fd9-995185b6cdb1@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <3OxLLo9Zkv_ShdFEG31JefEzf8D7PIX4D0MhfW_p9xs=.e3bfde70-f9b0-4f00-8fd9-995185b6cdb1@github.com>
Message-ID: <crZJofviLoq9lBEa0HrCLXPozRnRClj_pASiaQo7bZw=.ee5e2183-07d4-4f81-8405-cacf04a9fa18@github.com>

On Thu, 16 Feb 2023 17:03:58 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

>> SKARA-1035: Race when creating backports for bug spanning multiple repos
>
> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Caught more specific exception in case of backport fails & updated error message.

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1476

From erikj at openjdk.org  Thu Feb 16 20:02:13 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 20:02:13 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
 <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
Message-ID: <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>

On Thu, 16 Feb 2023 17:22:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Yes, I agree, used the more specific exception as suggested.
>> 
>> Regarding the specific exception code, yes I tried to run two test cases in parallel by putting the debug points to simulate the race condition but TestHost returned 2nd issue as a new one. I guess because of two instances of TestHost (one per test case). So could not verify the exception code.
>
> If you are interested, I think you can add the status code to the log with method `UncheckedRestException#getStatusCode`.

I think logging the statusCode as suggested by Zhao is a good idea.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From erikj at openjdk.org  Thu Feb 16 20:02:13 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 20:02:13 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
 <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
 <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>
Message-ID: <5pyfuMhaFIYMKjmDjQQGfgmVNqKCDuwXRO_o0oHknVc=.e28cea70-2b68-4e6f-aa98-77714613193b@github.com>

On Thu, 16 Feb 2023 19:58:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> If you are interested, I think you can add the status code to the log with method `UncheckedRestException#getStatusCode`.
>
> I think logging the statusCode as suggested by Zhao is a good idea.

Or never mind, we already log when throwing that exception.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Thu Feb 16 21:12:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:12:35 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <5pyfuMhaFIYMKjmDjQQGfgmVNqKCDuwXRO_o0oHknVc=.e28cea70-2b68-4e6f-aa98-77714613193b@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
 <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
 <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>
 <5pyfuMhaFIYMKjmDjQQGfgmVNqKCDuwXRO_o0oHknVc=.e28cea70-2b68-4e6f-aa98-77714613193b@github.com>
Message-ID: <wzX1A4YbJLrKFV2T8UgIt9teLYS7qQKwTtFZpJx3iBc=.d7a19213-6154-4e25-a03d-5bc8242c7d6e@github.com>

On Thu, 16 Feb 2023 19:59:37 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I think logging the statusCode as suggested by Zhao is a good idea.
>
> Or never mind, we already log when throwing that exception.

I don't think so, when the race condition occurs, the exception won't be thrown again.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From erikj at openjdk.org  Thu Feb 16 21:19:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 21:19:42 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <wzX1A4YbJLrKFV2T8UgIt9teLYS7qQKwTtFZpJx3iBc=.d7a19213-6154-4e25-a03d-5bc8242c7d6e@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
 <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
 <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>
 <5pyfuMhaFIYMKjmDjQQGfgmVNqKCDuwXRO_o0oHknVc=.e28cea70-2b68-4e6f-aa98-77714613193b@github.com>
 <wzX1A4YbJLrKFV2T8UgIt9teLYS7qQKwTtFZpJx3iBc=.d7a19213-6154-4e25-a03d-5bc8242c7d6e@github.com>
Message-ID: <2k8B9__1i3AwLjayY6CUntppCjtWsSlkFb1hCWmUYEk=.f5622f6e-34c3-412b-9617-558c15c11665@github.com>

On Thu, 16 Feb 2023 21:10:23 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Or never mind, we already log when throwing that exception.
>
> I don't think so, when the race condition occurs, the exception won't be thrown again.

We log in `RestRequest::transformBadResponse` before throwing the exception.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Thu Feb 16 21:22:20 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:22:20 GMT
Subject: RFR: 1035: Race when creating backports for bug spanning multiple
 repos [v2]
In-Reply-To: <2k8B9__1i3AwLjayY6CUntppCjtWsSlkFb1hCWmUYEk=.f5622f6e-34c3-412b-9617-558c15c11665@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
 <vk5fdPNptN0iQDK7oXLK1GtXPz6jgMeyR8xXrV-rzaQ=.2cf1be4b-4fa6-4e42-81ff-c607226c41a8@github.com>
 <DphomE_tvWoXNYnNLFjrIP3aOwYfAmK7NRZMzaoLrAY=.a6c11a20-d214-4240-978d-8050437d2db7@github.com>
 <taXsDwB0aRmlPNq_MaKvldPo1RQWolvD78XBGLzUPmc=.4689f3db-341b-415f-a4ab-5a6a88d66049@github.com>
 <2WnjHWEiCrwzuEEnl5WTBLvMtB3-1ccrR0cm7qxX5IQ=.e9c04d67-820a-40c6-9a3e-eda49ab7b5be@github.com>
 <5pyfuMhaFIYMKjmDjQQGfgmVNqKCDuwXRO_o0oHknVc=.e28cea70-2b68-4e6f-aa98-77714613193b@github.com>
 <wzX1A4YbJLrKFV2T8UgIt9teLYS7qQKwTtFZpJx3iBc=.d7a19213-6154-4e25-a03d-5bc8242c7d6e@github.com>
 <2k8B9__1i3AwLjayY6CUntppCjtWsSlkFb1hCWmUYEk=.f5622f6e-34c3-412b-9617-558c15c11665@github.com>
Message-ID: <Ux-IbtRXsWbAkSXZrV-wt5K_pnGSw3mU_fruESgN0JI=.8ec6110d-26af-4437-89bd-ef816f05fd9d@github.com>

On Thu, 16 Feb 2023 21:17:31 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I don't think so, when the race condition occurs, the exception won't be thrown again.
>
> We log in `RestRequest::transformBadResponse` before throwing the exception.

Oh, right.

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Thu Feb 16 21:38:26 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:38:26 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
Message-ID: <XGfI6-UAtJV1lGYxlr-7XsIOoYRoFlY3x9ri7BeAQCQ=.ed32f781-f968-40b3-9409-fd56ed18b433@github.com>

On Thu, 16 Feb 2023 19:45:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This looks like it solves the stated problem, but the WebrevStorage is still initiated and will still do some work, like creating directories for webrev creation. Ideally I would like that whole part of the bot be optional, but it seems really hard to achieve without having to add null checks all over the place.
> 
> I'm not sure what the best solution is here. Maybe we can introduce another `WebrevDescription.Type.NONE` and if neither kind of webrev has been configured, then `WebrevGenerator::generate` would return a `Webrevdescription` of `NONE` type.
> 
> Another possible solution would be to have an `enabled()` method on `WebrevStorage` and wrap all uses of `webrevGenerator` in a check for that. That may get messy though, but would definitely reduce unnecessary work when webrevs are disabled.
> 
> Have you looked at `updateWebrevComment`. When webrevs are disabled, we shouldn't post that comment either.

Yesterday, I was also thinking about what's the best way to solve this problem. And I thought my current change would have the least impact to current code. But your opinion is right, it still trigger some unnecessary work. I would think more about it.
And yes, I already made change in `updateWebrevComment`, it won't post comment in pr when webrev is disabled.

> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 318:
> 
>> 316:                 formatCommitMessagesBrief(commits, commitsLink).orElse("") + "\n\n" +
>> 317:                 "Changes: " + pr.changeUrl() + "\n" +
>> 318:                 (webrev.uri() == null ? "" : " Webrev: " + webrev.uri().toString()) + "\n" +
> 
> I think this will create an empty line instead of the webrev URL. I think it would be better to skip the newline so we just don't print anything.

Sure, will fix it.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 21:42:57 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:42:57 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
Message-ID: <Yn_3vjmfx-BvsX1CDbmvL71PU9WiIyUaPzXgQgB05LU=.7c3b9f24-66f4-477f-86c2-21c3e8a99eed@github.com>

On Thu, 16 Feb 2023 19:16:32 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
>> 
>> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.
>
> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 315:
> 
>> 313: 
>> 314:         return composeDependsOn(pr).map(line -> line + "\n\n").orElse("") +
>> 315:                 "Commit messages:\n" +
> 
> // When changing this, ensure that the PR pattern in the notifier still matches
> 
> Have you verified this?

I tried to find the related PR pattern again this morning, but unfortunately I still couldn't find it. I'm still confused about where to look for it. AFAIK, it's just the footer of the email.  Is there some place in the code where we would use this email and and parse it? I also tried resetting my head to the commit where the comment was added, but I couldn't find anything related to the notifier.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 21:46:07 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:46:07 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
Message-ID: <slvimPiQVuQHfx_38ymwgbSe0oYBC6GbaxSB-oYvFx8=.74945203-e145-4a00-a1dd-235354f31f61@github.com>

On Thu, 16 Feb 2023 19:22:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
>> 
>> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.
>
> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 332:
> 
>> 330:         if (webrevs.size() > 0) {
>> 331:             if (webrevs.stream().noneMatch(w -> w.uri() != null)) {
>> 332:                 webrevLinks = "Webrev is disabled\n\n";
> 
> I think this should just be `""` or possibly `"\n"`, not sure.

else {
            webrevLinks = "The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.\n\n";
        }

I just tried to align with this.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 21:51:34 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 21:51:34 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
Message-ID: <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>

On Thu, 16 Feb 2023 19:52:01 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.
> 
> I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.

Just see this comment. I will check it again.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From erikj at openjdk.org  Thu Feb 16 22:13:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 22:13:17 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <slvimPiQVuQHfx_38ymwgbSe0oYBC6GbaxSB-oYvFx8=.74945203-e145-4a00-a1dd-235354f31f61@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
 <slvimPiQVuQHfx_38ymwgbSe0oYBC6GbaxSB-oYvFx8=.74945203-e145-4a00-a1dd-235354f31f61@github.com>
Message-ID: <JK7U3nCTg5vHiJv_cB3tXg6HF1q53Es-XLOzqIVZOc8=.3f246090-807e-4d00-8c05-88e7d7cbbf1b@github.com>

On Thu, 16 Feb 2023 21:43:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 332:
>> 
>>> 330:         if (webrevs.size() > 0) {
>>> 331:             if (webrevs.stream().noneMatch(w -> w.uri() != null)) {
>>> 332:                 webrevLinks = "Webrev is disabled\n\n";
>> 
>> I think this should just be `""` or possibly `"\n"`, not sure.
>
> else {
>             webrevLinks = "The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.\n\n";
>         }
> 
> I just tried to align with this.

Yes, I figured that, but there is an important difference. That message explains why there is no webrevs where the user would expect them to be, but for a repo where they are completely turned off, I think we shouldn't even mention them.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 22:35:36 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 22:35:36 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
 <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
Message-ID: <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>

On Thu, 16 Feb 2023 21:49:13 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.
> 
> I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.

I couldn't find where this logic is. Could you please point it out to me?

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 22:38:53 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 22:38:53 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
 <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
 <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>
Message-ID: <d0fIBcIvJIM2_xA-w4zRyZzOtB5sTBdS_u5qYIcVkTg=.55278983-f3a3-4dd0-bedc-6f1677fe1fd3@github.com>

On Thu, 16 Feb 2023 22:33:26 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > > Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.
> > 
> > 
> > I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.
> 
> I couldn't find where this logic is. Could you please point it out to me?

I think I found it...

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Thu Feb 16 22:58:21 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 16 Feb 2023 22:58:21 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <d0fIBcIvJIM2_xA-w4zRyZzOtB5sTBdS_u5qYIcVkTg=.55278983-f3a3-4dd0-bedc-6f1677fe1fd3@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
 <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
 <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>
 <d0fIBcIvJIM2_xA-w4zRyZzOtB5sTBdS_u5qYIcVkTg=.55278983-f3a3-4dd0-bedc-6f1677fe1fd3@github.com>
Message-ID: <pgFCaUIF124hTwUJoI3XLdLEuKNqW4ltSou6fzOIpRY=.b24c9263-4e18-4531-8b71-251f6d1d8b14@github.com>

On Thu, 16 Feb 2023 22:36:48 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > Above `ArchiveMessages#composeConversationFooter`, there is a comment says `// When changing this, ensure that the PR pattern in the notifier still matches`. I tried to figure out where the PR pattern is, but I couldn't find it.
> 
> I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.

The logic you mentioned seems like has been deleted in SKARA-386. So I think we are safe.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From erikj at openjdk.org  Thu Feb 16 23:46:21 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 16 Feb 2023 23:46:21 GMT
Subject: RFR: 1825: BotTaskAggregationHandler causes OOME
Message-ID: <eMQ_4P6MnKk9hxQi4DEisLt4gNel_BKd_pppNo7S8_Q=.249bdc86-b7fd-4315-8ce4-6f438895b7c7@github.com>

The BotTaskAggregationHandler saves all log records in a list per thread and publishes them when a specific marker is detected in a record. This marker signals the end of a WorkItem run. If a large amount of log messages are generated by a single WorkItem, this can result in a very large amount of log messages being saved. We currently have a case where 18 million+ have been observed when processing the webrevs for https://github.com/openjdk/mobile/pull/16 in MailingListBridgeBot.

The irony here is that the only subclass of this abstract handler, the BotSlackHandler, throws away all log records that are lower level than what it's supposed to log, so we are saving all of these, only to log those of level SEVERE in the end. In the past, this class was also used for logging to logstash, and in that case, when we had one SEVERE log record, we actually wanted to log everything that lead up to it.

This fix makes it an option for the BotTaskAggregationHandler if it should save everything or just above the configured level, so a subclass can choose which behavior it expects. I also removed the filtering in BotSlackHandler as its no longer needed.

-------------

Commit messages:
 - SKARA-1825

Changes: https://git.openjdk.org/skara/pull/1477/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1477&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1825
  Stats: 30 lines in 3 files changed: 11 ins; 14 del; 5 mod
  Patch: https://git.openjdk.org/skara/pull/1477.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1477/head:pull/1477

PR: https://git.openjdk.org/skara/pull/1477

From erikj at openjdk.org  Fri Feb 17 00:19:28 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 Feb 2023 00:19:28 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <pgFCaUIF124hTwUJoI3XLdLEuKNqW4ltSou6fzOIpRY=.b24c9263-4e18-4531-8b71-251f6d1d8b14@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
 <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
 <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>
 <d0fIBcIvJIM2_xA-w4zRyZzOtB5sTBdS_u5qYIcVkTg=.55278983-f3a3-4dd0-bedc-6f1677fe1fd3@github.com>
 <pgFCaUIF124hTwUJoI3XLdLEuKNqW4ltSou6fzOIpRY=.b24c9263-4e18-4531-8b71-251f6d1d8b14@github.com>
Message-ID: <NV7KDhSN2At-NQ1L_6XqusxXpAdMzu-TEMps5bvURrs=.c0bf8c6d-a7ea-48b7-a4c6-e31134804b74@github.com>

On Thu, 16 Feb 2023 22:56:15 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.
> 
> The logic you mentioned seems like has been deleted in SKARA-386. So I think we are safe.

The logic I was thinking about is in `MailingListArchiveReaderBot` `PULL_REQUEST_LINK_PATTERN`.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From ihse at openjdk.org  Fri Feb 17 10:25:48 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 17 Feb 2023 10:25:48 GMT
Subject: RFR: 1825: BotTaskAggregationHandler causes OOME
In-Reply-To: <eMQ_4P6MnKk9hxQi4DEisLt4gNel_BKd_pppNo7S8_Q=.249bdc86-b7fd-4315-8ce4-6f438895b7c7@github.com>
References: <eMQ_4P6MnKk9hxQi4DEisLt4gNel_BKd_pppNo7S8_Q=.249bdc86-b7fd-4315-8ce4-6f438895b7c7@github.com>
Message-ID: <8dO90H0yCbjaVNzPgN9AX3SJAubU_Taj8Fto0rpX7qk=.27b99c61-ab1d-49dd-a749-75b7a41c190b@github.com>

On Thu, 16 Feb 2023 23:42:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The BotTaskAggregationHandler saves all log records in a list per thread and publishes them when a specific marker is detected in a record. This marker signals the end of a WorkItem run. If a large amount of log messages are generated by a single WorkItem, this can result in a very large amount of log messages being saved. We currently have a case where 18 million+ have been observed when processing the webrevs for https://github.com/openjdk/mobile/pull/16 in MailingListBridgeBot.
> 
> The irony here is that the only subclass of this abstract handler, the BotSlackHandler, throws away all log records that are lower level than what it's supposed to log, so we are saving all of these, only to log those of level SEVERE in the end. In the past, this class was also used for logging to logstash, and in that case, when we had one SEVERE log record, we actually wanted to log everything that lead up to it.
> 
> This fix makes it an option for the BotTaskAggregationHandler if it should save everything or just above the configured level, so a subclass can choose which behavior it expects. I also removed the filtering in BotSlackHandler as its no longer needed.

LGTM.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.org/skara/pull/1477

From erikj at openjdk.org  Fri Feb 17 16:40:22 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 Feb 2023 16:40:22 GMT
Subject: Integrated: 1825: BotTaskAggregationHandler causes OOME
In-Reply-To: <eMQ_4P6MnKk9hxQi4DEisLt4gNel_BKd_pppNo7S8_Q=.249bdc86-b7fd-4315-8ce4-6f438895b7c7@github.com>
References: <eMQ_4P6MnKk9hxQi4DEisLt4gNel_BKd_pppNo7S8_Q=.249bdc86-b7fd-4315-8ce4-6f438895b7c7@github.com>
Message-ID: <IOuMvQqxpQzZLPt1CvbdkG1-e4ZbzvjzxvQvkHAlMrg=.22deb307-db08-4b83-8e20-70b475ee4212@github.com>

On Thu, 16 Feb 2023 23:42:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The BotTaskAggregationHandler saves all log records in a list per thread and publishes them when a specific marker is detected in a record. This marker signals the end of a WorkItem run. If a large amount of log messages are generated by a single WorkItem, this can result in a very large amount of log messages being saved. We currently have a case where 18 million+ have been observed when processing the webrevs for https://github.com/openjdk/mobile/pull/16 in MailingListBridgeBot.
> 
> The irony here is that the only subclass of this abstract handler, the BotSlackHandler, throws away all log records that are lower level than what it's supposed to log, so we are saving all of these, only to log those of level SEVERE in the end. In the past, this class was also used for logging to logstash, and in that case, when we had one SEVERE log record, we actually wanted to log everything that lead up to it.
> 
> This fix makes it an option for the BotTaskAggregationHandler if it should save everything or just above the configured level, so a subclass can choose which behavior it expects. I also removed the filtering in BotSlackHandler as its no longer needed.

This pull request has now been integrated.

Changeset: e1eb7e73
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/e1eb7e73276af2539d6aafa2e4f9177048a95d52
Stats:     30 lines in 3 files changed: 11 ins; 14 del; 5 mod

1825: BotTaskAggregationHandler causes OOME

Reviewed-by: ihse

-------------

PR: https://git.openjdk.org/skara/pull/1477

From zsong at openjdk.org  Fri Feb 17 17:20:46 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 17 Feb 2023 17:20:46 GMT
Subject: RFR: 1271: Webrev generation should be optional
In-Reply-To: <NV7KDhSN2At-NQ1L_6XqusxXpAdMzu-TEMps5bvURrs=.c0bf8c6d-a7ea-48b7-a4c6-e31134804b74@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <IsV0Aa39ATZy0TPuIUvWJudO9JqPBPjfR4YgzGiJzhg=.ecc4781c-a547-4a9f-bf01-9340698ca4a4@github.com>
 <qQI7WDaQZleP7KBAXFBdPnAhQmgZADz95K1i3ZHCdLE=.5ee47286-e0a4-4956-a823-f2c823d8359c@github.com>
 <xa9b_cU-niRUxYFxk_Diz2NF9S_RFFERYZu_nj_k1sM=.022738c9-bdd1-493f-a851-e6dc39c0f3bb@github.com>
 <l66XSHzIb3DXnUp6pYbMRlD9HnLc_c9lu6XPatymYEw=.1a7ccb7d-bdfa-4505-9b42-c5556d9b2b18@github.com>
 <d0fIBcIvJIM2_xA-w4zRyZzOtB5sTBdS_u5qYIcVkTg=.55278983-f3a3-4dd0-bedc-6f1677fe1fd3@github.com>
 <pgFCaUIF124hTwUJoI3XLdLEuKNqW4ltSou6fzOIpRY=.b24c9263-4e18-4531-8b71-251f6d1d8b14@github.com>
 <NV7KDhSN2At-NQ1L_6XqusxXpAdMzu-TEMps5bvURrs=.c0bf8c6d-a7ea-48b7-a4c6-e31134804b74@github.com>
Message-ID: <ZqXZ_6jRLoK9tUeRCXVtsG20d4rlnPY3fVaWbcPQH9I=.66345986-0b19-4ced-b107-c4c15255ad25@github.com>

On Fri, 17 Feb 2023 00:17:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > > I believe it's the logic that parses email from the email list server and extracts the PR URL from the verify first email in the each thread. You are likely safe here as you aren't changing the line that contains the PR URL, but better be safe.
> > 
> > 
> > The logic you mentioned seems like has been deleted in SKARA-386. So I think we are safe.
> 
> The logic I was thinking about is in `MailingListArchiveReaderBot` `PULL_REQUEST_LINK_PATTERN`.

You're right, it was not deleted, just moved.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Fri Feb 17 19:47:15 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 17 Feb 2023 19:47:15 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the Git
 forge
Message-ID: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>

This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot

The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 

For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

-------------

Commit messages:
 - SKARA-1823

Changes: https://git.openjdk.org/skara/pull/1478/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-1823
  Stats: 205 lines in 11 files changed: 182 ins; 0 del; 23 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From erikj at openjdk.org  Fri Feb 17 21:00:25 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 17 Feb 2023 21:00:25 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <1UJgXragwDuoqcnKmci2pvNbq80aznD7FSvglh3lxes=.6714a9aa-4db6-4224-a031-b1806a048f01@github.com>

On Fri, 17 Feb 2023 18:56:58 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

When publishing URLs in emails, we rewrite them to be (somewhat) forge agnostic. If you look in any PR email, you will not that it says "git.openjdk.org" and not github.com. This is a service we host that redirects to "github.com/openjdk". If we were to ever move to a different provider, we can change that rewrite service. Because of this, we can't use the URLs in the PR object for emails. We need to generate them.

Since we don't need these URLs every time we fetch comments or reviews, I think it would make sense to let the PullRequest handle generation of these URLs, something like `PullRequest.reviewUrl(Review)` and `PullRequest.commentUrl(Comment)`, similar to the existing `PullRequest.changeUrl`.

-------------

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Fri Feb 17 21:13:00 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 17 Feb 2023 21:13:00 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge
In-Reply-To: <1UJgXragwDuoqcnKmci2pvNbq80aznD7FSvglh3lxes=.6714a9aa-4db6-4224-a031-b1806a048f01@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
 <1UJgXragwDuoqcnKmci2pvNbq80aznD7FSvglh3lxes=.6714a9aa-4db6-4224-a031-b1806a048f01@github.com>
Message-ID: <YX7XfcdoWwEMFae5CifzeEYw7D51-aHdX3jKvFptVlk=.039aa36b-22c3-494e-874a-90d5632cc9dd@github.com>

On Fri, 17 Feb 2023 20:58:06 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> When publishing URLs in emails, we rewrite them to be (somewhat) forge agnostic. If you look in any PR email, you will not that it says "git.openjdk.org" and not github.com. This is a service we host that redirects to "github.com/openjdk". If we were to ever move to a different provider, we can change that rewrite service. Because of this, we can't use the URLs in the PR object for emails. We need to generate them.
> 
> Since we don't need these URLs every time we fetch comments or reviews, I think it would make sense to let the PullRequest handle generation of these URLs, something like `PullRequest.reviewUrl(Review)` and `PullRequest.commentUrl(Comment)`, similar to the existing `PullRequest.changeUrl`.

Oh, got it. I will fix the problems. Thx!

-------------

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Sat Feb 18 00:09:26 2023
From: zsong at openjdk.org (Zhao Song)
Date: Sat, 18 Feb 2023 00:09:26 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v2]
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <QMnNH-2BCJeoYqq2Z3KV57sHMkB_9Mu74EXvy8p3Oew=.87ad9165-8f66-403d-bb7b-f9186c3a9860@github.com>

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  SKARA-1823

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1478/files
  - new: https://git.openjdk.org/skara/pull/1478/files/2e0c3bcd..a3e50106

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=00-01

  Stats: 267 lines in 15 files changed: 100 ins; 129 del; 38 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Sat Feb 18 04:03:48 2023
From: zsong at openjdk.org (Zhao Song)
Date: Sat, 18 Feb 2023 04:03:48 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v3]
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <y3mYrx7K500RmwXbhXfPrKGG6-_biXJ-fkraspVALE8=.abe5ea79-7e0d-4afb-9702-71da931839af@github.com>

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix a problem

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1478/files
  - new: https://git.openjdk.org/skara/pull/1478/files/a3e50106..fce6b232

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Tue Feb 21 16:56:35 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 16:56:35 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v4]
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <XN-qc24A3Y3iWEAKbg45dME3KPrtLwnT5yfgqnTYagc=.90eec5aa-9e6d-4ca0-8659-f694f7961337@github.com>

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  trigger workflow

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1478/files
  - new: https://git.openjdk.org/skara/pull/1478/files/fce6b232..2ffb2a56

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=02-03

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From duke at openjdk.org  Tue Feb 21 18:15:44 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Tue, 21 Feb 2023 18:15:44 GMT
Subject: Integrated: 1035: Race when creating backports for bug spanning
 multiple repos
In-Reply-To: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
References: <iFvP9RNDAjoKUeKAZQXmWcTOj0_uDhx80Kc2R8tfSK4=.48280fbb-81d6-4305-8796-4c5dc6185bef@github.com>
Message-ID: <u_nMFn6F1YRgWuHY43CrQC3zGz2rUhI8jClVAvk7KYI=.5091ad7d-f3d4-4418-92e2-db25b051449c@github.com>

On Thu, 16 Feb 2023 01:44:21 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> SKARA-1035: Race when creating backports for bug spanning multiple repos

This pull request has now been integrated.

Changeset: a80b1d2f
Author:    Vijay Kulkarni <vijay.s.kulkarni at oracle.com>
Committer: Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/a80b1d2f7179d86a8719d053b5d20a171295d195
Stats:     13 lines in 1 file changed: 12 ins; 0 del; 1 mod

1035: Race when creating backports for bug spanning multiple repos

Reviewed-by: zsong, erikj

-------------

PR: https://git.openjdk.org/skara/pull/1476

From zsong at openjdk.org  Tue Feb 21 18:58:44 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 18:58:44 GMT
Subject: RFR: 1271: Webrev generation should be optional [v2]
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <WVEhwiNEg6Fdv2_uIxQDzOT1LemdPajomOkLtVHAg0A=.c3c326d1-6b10-4561-b2e3-2eee8b8028de@github.com>

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix linebreaker issue

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1475/files
  - new: https://git.openjdk.org/skara/pull/1475/files/85bda4d3..71027edb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1475.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1475/head:pull/1475

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Tue Feb 21 19:08:04 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 19:08:04 GMT
Subject: RFR: 1271: Webrev generation should be optional [v3]
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <Xt6gtiio2a6YDmZQxMcDCS_0c2Mme2g_4jPD0LOLQK8=.84fd8df8-e371-4b64-94f0-eea060f098e5@github.com>

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix test

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1475/files
  - new: https://git.openjdk.org/skara/pull/1475/files/71027edb..a5f1b544

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=02
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1475.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1475/head:pull/1475

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Tue Feb 21 19:31:40 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 19:31:40 GMT
Subject: RFR: 1271: Webrev generation should be optional [v4]
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <rxry3OZ2yKLlWZY_6Tvkz5eZg9oURRIAOlu_7m5CB5Y=.8efedc20-878e-4b00-be81-4298fc9eb596@github.com>

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  skip generating paths in WebrevStorage#createAndArchive

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1475/files
  - new: https://git.openjdk.org/skara/pull/1475/files/a5f1b544..4b6e9938

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=03
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1475&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/skara/pull/1475.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1475/head:pull/1475

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Tue Feb 21 19:31:40 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 19:31:40 GMT
Subject: RFR: 1271: Webrev generation should be optional [v4]
In-Reply-To: <XGfI6-UAtJV1lGYxlr-7XsIOoYRoFlY3x9ri7BeAQCQ=.ed32f781-f968-40b3-9409-fd56ed18b433@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <o-49syjfUunbPG29ZOnZ4IIWoRtWKB_Hjos5qx5Dft4=.535cdd8b-21d9-41d5-91f5-2261fce212c6@github.com>
 <XGfI6-UAtJV1lGYxlr-7XsIOoYRoFlY3x9ri7BeAQCQ=.ed32f781-f968-40b3-9409-fd56ed18b433@github.com>
Message-ID: <jlTfFjXq_0qYF52vkZDA4AOfRA-EiV7Tgo5sHqbo65k=.a6136360-6bc4-416d-81e7-ee0353b34e41@github.com>

On Thu, 16 Feb 2023 21:35:55 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This looks like it solves the stated problem, but the WebrevStorage is still initiated and will still do some work, like creating directories for webrev creation. Ideally I would like that whole part of the bot be optional, but it seems really hard to achieve without having to add null checks all over the place.
> 
> I'm not sure what the best solution is here. Maybe we can introduce another `WebrevDescription.Type.NONE` and if neither kind of webrev has been configured, then `WebrevGenerator::generate` would return a `Webrevdescription` of `NONE` type.
> 
> Another possible solution would be to have an `enabled()` method on `WebrevStorage` and wrap all uses of `webrevGenerator` in a check for that. That may get messy though, but would definitely reduce unnecessary work when webrevs are disabled.
> 
> Have you looked at `updateWebrevComment`. When webrevs are disabled, we shouldn't post that comment either.

Checked the logic again and I found although `WebrevStorage` is still initiated, it will just generate some paths but not create directories.

-------------

PR: https://git.openjdk.org/skara/pull/1475

From erikj at openjdk.org  Tue Feb 21 20:44:07 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Feb 2023 20:44:07 GMT
Subject: RFR: 1271: Webrev generation should be optional [v4]
In-Reply-To: <rxry3OZ2yKLlWZY_6Tvkz5eZg9oURRIAOlu_7m5CB5Y=.8efedc20-878e-4b00-be81-4298fc9eb596@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <rxry3OZ2yKLlWZY_6Tvkz5eZg9oURRIAOlu_7m5CB5Y=.8efedc20-878e-4b00-be81-4298fc9eb596@github.com>
Message-ID: <oM-IjR3TyKqONP52s4KW-vXkGRlOdKDf3XT3xKQDgqk=.422c70a1-aac9-4763-87c8-c97658d0ea21@github.com>

On Tue, 21 Feb 2023 19:31:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
>> 
>> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip generating paths in WebrevStorage#createAndArchive

Marked as reviewed by erikj (Lead).

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Tue Feb 21 20:45:55 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 20:45:55 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v5]
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <xpxIi8htB-eUQ-_h4a2X01LP5aKh0R5QH65LwnkkZlM=.fc050a30-af3a-46bc-b201-734cdb1be11b@github.com>

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

Zhao Song has updated the pull request incrementally with four additional commits since the last revision:

 - Update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ReviewArchive.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1478/files
  - new: https://git.openjdk.org/skara/pull/1478/files/2ffb2a56..f7bee158

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=04
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=03-04

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From erikj at openjdk.org  Tue Feb 21 20:45:56 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 21 Feb 2023 20:45:56 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v4]
In-Reply-To: <XN-qc24A3Y3iWEAKbg45dME3KPrtLwnT5yfgqnTYagc=.90eec5aa-9e6d-4ca0-8659-f694f7961337@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
 <XN-qc24A3Y3iWEAKbg45dME3KPrtLwnT5yfgqnTYagc=.90eec5aa-9e6d-4ca0-8659-f694f7961337@github.com>
Message-ID: <EVUT0q9gC7GOLLxWrxaHGBKrpdFMFq-4VJxnlkCLkkg=.28a25062-f013-4051-944d-2ab8f3276216@github.com>

On Tue, 21 Feb 2023 16:56:35 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
>> 
>> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
>> 
>> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trigger workflow

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 308:

> 306:     }
> 307: 
> 308:     static String composeReplyFooter(PullRequest pr, Comment comment, ReviewComment reviewComment, Review review) {

I think you should just split this into 3 separate methods. I can't see any caller that uses more than one of Comment, ReviewComment or Review.

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 311:

> 309:         var footer = new StringBuilder();
> 310:         if (comment != null) {
> 311:             footer.append("Comment: " + pr.commentUrl(comment).toString());

Suggestion:

            footer.append("PR Comment: " + pr.commentUrl(comment).toString());

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 314:

> 312:         }
> 313:         if (reviewComment != null) {
> 314:             footer.append("ReviewComment: " + pr.reviewCommentUrl(reviewComment).toString());

Suggestion:

            footer.append("PR Review Comment: " + pr.reviewCommentUrl(reviewComment).toString());

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 317:

> 315:         }
> 316:         if (review != null) {
> 317:             footer.append("Review: " + pr.reviewUrl(review).toString());

Suggestion:

            footer.append("PR Review: " + pr.reviewUrl(review).toString());

bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ReviewArchive.java line 357:

> 355:                                                .filter(line -> !includedFooterFragments.contains(line))
> 356:                                                .collect(Collectors.toList());
> 357:                 if(!footer.isEmpty() && !newFooterFragments.isEmpty()){

Suggestion:

                if (!footer.isEmpty() && !newFooterFragments.isEmpty()) {

-------------

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Tue Feb 21 20:45:56 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 20:45:56 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v4]
In-Reply-To: <EVUT0q9gC7GOLLxWrxaHGBKrpdFMFq-4VJxnlkCLkkg=.28a25062-f013-4051-944d-2ab8f3276216@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
 <XN-qc24A3Y3iWEAKbg45dME3KPrtLwnT5yfgqnTYagc=.90eec5aa-9e6d-4ca0-8659-f694f7961337@github.com>
 <EVUT0q9gC7GOLLxWrxaHGBKrpdFMFq-4VJxnlkCLkkg=.28a25062-f013-4051-944d-2ab8f3276216@github.com>
Message-ID: <nXbKWSJTApudGdUUtodNU3AM694oRIUZmQOfroDkgxg=.3ddbeb33-50f4-4a4f-a977-5a3ea21558ed@github.com>

On Tue, 21 Feb 2023 20:29:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trigger workflow
>
> bots/mlbridge/src/main/java/org/openjdk/skara/bots/mlbridge/ArchiveMessages.java line 308:
> 
>> 306:     }
>> 307: 
>> 308:     static String composeReplyFooter(PullRequest pr, Comment comment, ReviewComment reviewComment, Review review) {
> 
> I think you should just split this into 3 separate methods. I can't see any caller that uses more than one of Comment, ReviewComment or Review.

Sure. I will fix it.

-------------

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Tue Feb 21 20:58:46 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 20:58:46 GMT
Subject: RFR: 1823: Mailing list bot should include link to comment on the
 Git forge [v6]
In-Reply-To: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
References: <PM6NQH3uG2W-j-Z3whFrLZ3lBiq4TkB3EQrDGLUd5_Q=.dfa89935-aea1-4f5a-8549-5b3f8b73f312@github.com>
Message-ID: <0dta6H36iX1j3v5g1-_05ZxdC5rP28x1sjB2b1XHzKo=.38aa2b4e-77bf-49f1-b827-1869e243cd2a@github.com>

> This patch will add the ability to attach comment/reviewComment/review link to the email generated by mlbridge bot
> 
> The implementation for GitHub is straightforward, we can extract the URL for a specific comment or review from the JSON response using the `html_url` field and include it in the email. 
> 
> For GitLab, we will need to generate the URL using the `id` field in `note,` since GitLab does not provide an field like `html_url` in its JSON responses.

Zhao Song has updated the pull request incrementally with one additional commit since the last revision:

  fix a problem

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1478/files
  - new: https://git.openjdk.org/skara/pull/1478/files/f7bee158..d7aa239d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=05
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1478&range=04-05

  Stats: 15 lines in 2 files changed: 0 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/skara/pull/1478.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1478/head:pull/1478

PR: https://git.openjdk.org/skara/pull/1478

From zsong at openjdk.org  Tue Feb 21 21:26:05 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 21:26:05 GMT
Subject: RFR: 1271: Webrev generation should be optional [v4]
In-Reply-To: <rxry3OZ2yKLlWZY_6Tvkz5eZg9oURRIAOlu_7m5CB5Y=.8efedc20-878e-4b00-be81-4298fc9eb596@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
 <rxry3OZ2yKLlWZY_6Tvkz5eZg9oURRIAOlu_7m5CB5Y=.8efedc20-878e-4b00-be81-4298fc9eb596@github.com>
Message-ID: <-WrrDXQtrGtNgfK-NqJpUwg_lmbMVZez9IMho0V5mGw=.181ad736-618a-4b24-95df-9e04e52a07e4@github.com>

On Tue, 21 Feb 2023 19:31:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
>> 
>> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip generating paths in WebrevStorage#createAndArchive

Thanks for the review!

-------------

PR: https://git.openjdk.org/skara/pull/1475

From zsong at openjdk.org  Tue Feb 21 21:26:05 2023
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 21 Feb 2023 21:26:05 GMT
Subject: Integrated: 1271: Webrev generation should be optional
In-Reply-To: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
References: <YpWGlNNf82w05G7Fw4A9VUN6R6u9yi1qw2xzmVamWSY=.389c8d9c-0744-48de-9bfd-277ad2ac6e59@github.com>
Message-ID: <y7nj9O-yPQ7NYFkCJ791end-BMYwwtc3oc_mfVPm2NA=.0dce4736-0d71-4a51-89f8-312de687b3e0@github.com>

On Thu, 16 Feb 2023 00:03:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, webrevs are generated automatically when a user pushes a new commit, and it's mandatory to choose either JSON or HTML when configuring the mlbridge bot. If both of them are disabled in the configuration, the bot will throw errors.
> 
> In this patch, generating a webrev will be optional. If both JSON and HTML are disabled, no webrev will be generated.

This pull request has now been integrated.

Changeset: 50e7e8cc
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/50e7e8cc1f6b2081b0e607b1b37529936d173e7b
Stats:     259 lines in 4 files changed: 242 ins; 0 del; 17 mod

1271: Webrev generation should be optional

Reviewed-by: erikj

-------------

PR: https://git.openjdk.org/skara/pull/1475

From duke at openjdk.org  Fri Feb 24 14:42:17 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Fri, 24 Feb 2023 14:42:17 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
Message-ID: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>

755: Anything starting with a "/" is treated as a command

-------------

Commit messages:
 - 755: Anything starting with a "/" is treated as a command

Changes: https://git.openjdk.org/skara/pull/1479/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1479&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-755
  Stats: 94 lines in 10 files changed: 54 ins; 14 del; 26 mod
  Patch: https://git.openjdk.org/skara/pull/1479.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1479/head:pull/1479

PR: https://git.openjdk.org/skara/pull/1479

From kcr at openjdk.org  Fri Feb 24 15:12:52 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Feb 2023 15:12:52 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <eG5eCCvnXbOnPXvSiDOMtRzJ2krpPEXxcQf_jxKz43E=.5f99e319-7b51-4f3b-93e7-618e1ddc1a7c@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

This seem like too simplistic an approach to me, in that it trades one problem for another. Now a typo in a command name, such as `/intigrate` or similar, will show up as a review comment without the helpful "unrecognized command" comment and suggestion to type `/help`.

I might recommend the more targeted solution of not treating `/sometext` as a command when it appears in a code block.

As for other problematic cases, wasn't there an earlier change to not treat `/sometext` as a command unless it was at the beginning of a line (after trimming whitespace)? If not, then that would also be a good change.

I'll test that theory now: /integrate which Skara should ignore.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From duke at openjdk.org  Fri Feb 24 15:45:58 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Fri, 24 Feb 2023 15:45:58 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <eG5eCCvnXbOnPXvSiDOMtRzJ2krpPEXxcQf_jxKz43E=.5f99e319-7b51-4f3b-93e7-618e1ddc1a7c@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <eG5eCCvnXbOnPXvSiDOMtRzJ2krpPEXxcQf_jxKz43E=.5f99e319-7b51-4f3b-93e7-618e1ddc1a7c@github.com>
Message-ID: <nWWHn7OhdohtOURtC21hcsh5ewcJOIIPhZkS_5JSxoQ=.2a26f315-c4fe-46b0-87a1-ad1036ab1aa7@github.com>

On Fri, 24 Feb 2023 15:10:47 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> This seem like too simplistic an approach to me, in that it trades one problem for another. Now a typo in a command name, such as `/intigrate` or similar, will show up as a review comment without the helpful "unrecognized command" comment and suggestion to type `/help`.
> 
> I might recommend the more targeted solution of not treating `/sometext` as a command when it appears in a code block.
> 
> As for other problematic cases, wasn't there an earlier change to not treat `/sometext` as a command unless it was at the beginning of a line (after trimming whitespace)? If not, then that would also be a good change.
> 
> I'll test that theory now: /integrate which Skara should ignore.

Thanks, for your feedback, yes, I agree that with this change, we won't be able to provide user feedback if there is a typo in the Skara command. But providing Skara feedback for the text mentioned only in the code block comes with assumptions that:

a) user won't type text starting with '/' outside the code block (e.g. /name-of-commenter)
b) user will always type Skara and non-Skara commands starting with '/' (e.g. windows/Linux commands) in the code block

If any of the above rules are not followed that would result in Skara bot feedback for invalid command. 

Would that be an acceptable outcome?

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Fri Feb 24 15:52:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Feb 2023 15:52:55 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <QzWuW8fmqAtf1TYlO581hgwxz_FmX4AGEynb-VNDmcs=.6f983fc3-4593-4f26-8758-3d1f92587af6@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

The code looks good, but please hold off integrating until we have agreement.

-------------

Marked as reviewed by erikj (Lead).

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Fri Feb 24 15:52:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Feb 2023 15:52:55 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <nWWHn7OhdohtOURtC21hcsh5ewcJOIIPhZkS_5JSxoQ=.2a26f315-c4fe-46b0-87a1-ad1036ab1aa7@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <eG5eCCvnXbOnPXvSiDOMtRzJ2krpPEXxcQf_jxKz43E=.5f99e319-7b51-4f3b-93e7-618e1ddc1a7c@github.com>
 <nWWHn7OhdohtOURtC21hcsh5ewcJOIIPhZkS_5JSxoQ=.2a26f315-c4fe-46b0-87a1-ad1036ab1aa7@github.com>
Message-ID: <bke8dO5JwYb3ejtGYwush4MaZ-oIf2zHZA5_Uxi3lO0=.92f1427d-ca43-4939-bd52-f0f87da4695d@github.com>

On Fri, 24 Feb 2023 15:43:42 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> This seem like too simplistic an approach to me, in that it trades one problem for another. Now a typo in a command name, such as `/intigrate` or similar, will show up as a review comment without the helpful "unrecognized command" comment and suggestion to type `/help`.

I think this change is good and I directed Vijay to tackle this issue. 
 
It's a difficult tradeoff for sure, but I've seen the command extractor trigger on unintentional command looking comments more often than I would like. Especially the filtering when sending emails is problematic. See for example this PR and corresponding email:

https://github.com/openjdk/jdk/pull/12695
https://mail.openjdk.org/pipermail/build-dev/2023-February/037829.html

I'm not sure why the PR bot didn't reply to that instance though.

> I might recommend the more targeted solution of not treating `/sometext` as a command when it appears in a code block.

That would be another approach, but it would require a more complicated parsing logic. I could also imagine adding some kind of fuzzy matcher on the existing commands so that obvious spelling errors were caught. I'm not sure it's worth the effort.

> As for other problematic cases, wasn't there an earlier change to not treat `/sometext` as a command unless it was at the beginning of a line (after trimming whitespace)? If not, then that would also be a good change.
> 
> I'll test that theory now: /integrate which Skara should ignore.

It's correct that we only try to match commands preceded by whitespace. I just don't think it's enough to avoid enough false positive matches.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From kcr at openjdk.org  Fri Feb 24 16:04:11 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 24 Feb 2023 16:04:11 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <sdtzjj3jiX-YLBbXVwBiD9pxv6NsCYn7Y-y-0dDfT5w=.faad5085-f358-41b2-abbb-b7a3a85187e4@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

> I think this change is good and I directed Vijay to tackle this issue.
> 
> It's a difficult tradeoff for sure, but I've seen the command extractor trigger on unintentional command looking comments more often than I would like. Especially the filtering when sending emails is problematic. See for example this PR and corresponding email:
> 
> [openjdk/jdk#12695](https://github.com/openjdk/jdk/pull/12695) https://mail.openjdk.org/pipermail/build-dev/2023-February/037829.html
> 
> I'm not sure why the PR bot didn't reply to that instance though.
> 
> > I might recommend the more targeted solution of not treating `/sometext` as a command when it appears in a code block.
> 
> That would be another approach, but it would require a more complicated parsing logic. I could also imagine adding some kind of fuzzy matcher on the existing commands so that obvious spelling errors were caught. I'm not sure it's worth the effort.

OK, I can see your point. What do you think about also producing a comment with a warning (but not filtering the email) in case there is an unrecognized command with a `/` at the beginning of a line? Something like:

"I see that you entered a comment with `/sometext` at the beginning of a line. `/sometext` is not a recognized Skara PR command, so it was ignored and treated like an ordinary comment. If you intended to issue a Skara command, use `/help` in a comment to see a complete list of Skara commands."

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Fri Feb 24 16:34:45 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Feb 2023 16:34:45 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <xKNYR8LLzPJpHHVQcRDEZC2nRXwnfMJ25lgg8mJPKBM=.68a29e1e-b4e8-496d-82f8-7263a3129014@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

I did a search on github `org:openjdk "for a list of valid commands use"` and from the first handful of hits, it seems about even between good and bad matches. The good matches do seem really useful. Common misspellings are "/labels" and "/intergrate". So maybe we still need some kind of suggestion posted. Another consequence of the proposed change is that any misspelled attempt will now also be emailed.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Fri Feb 24 16:45:53 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Feb 2023 16:45:53 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <sdtzjj3jiX-YLBbXVwBiD9pxv6NsCYn7Y-y-0dDfT5w=.faad5085-f358-41b2-abbb-b7a3a85187e4@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <sdtzjj3jiX-YLBbXVwBiD9pxv6NsCYn7Y-y-0dDfT5w=.faad5085-f358-41b2-abbb-b7a3a85187e4@github.com>
Message-ID: <yjY2OyFRcnM1XAYTIYGuR10O5i3egg8B_4mwSymvgGQ=.055cb850-5d9c-44dc-9384-edc3c1a26fac@github.com>

On Fri, 24 Feb 2023 16:02:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> See for example this PR and corresponding email:
> 
> [openjdk/jdk#12695](https://github.com/openjdk/jdk/pull/12695) https://mail.openjdk.org/pipermail/build-dev/2023-February/037829.html
> 
> I'm not sure why the PR bot didn't reply to that instance though.

I figured out why this was filtered in the email but not interpreted as a command in PR bot. The regex is different. In mlbridge, there is no matching of space between the command and the optional arguments. One way we could reduce false positives is to further restrict the regex. Stop accepting capital letters, as we only have lower case commands, and make sure the regex in the different bots match (maybe even unify them into one location in the common module).

Another pattern I saw in the search was a user using `/keepalive` in a comment to stop the bot from auto closing the PR. He probably knows it's an invalid command, but by using an invalid command, there is no email sent, which is actually a feature in this case.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From duke at openjdk.org  Fri Feb 24 17:12:02 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Fri, 24 Feb 2023 17:12:02 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <Ms6gIQKd9BgjUi_uQx1tA5pYcPDoHTxxS7OkGjWj5QY=.a025a5b4-ddcf-47b5-946a-d6cacacfcf21@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

Thanks for the above feedback, so as per the suggestions I will
    1. consolidate the patterns and move those to the common module
    2. modify the regex to verify that the command starts with a lowercase

**Question**: In case the command starts with '/' but does not match with the standard command regex, do we need to provide suggestions based on the mistyped command in the message (e.g. Do you mean 'integrate' instead of 'intergate'?) or a generic warning message suggested by Kevin well enough?

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Fri Feb 24 17:23:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 24 Feb 2023 17:23:51 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <Ms6gIQKd9BgjUi_uQx1tA5pYcPDoHTxxS7OkGjWj5QY=.a025a5b4-ddcf-47b5-946a-d6cacacfcf21@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <Ms6gIQKd9BgjUi_uQx1tA5pYcPDoHTxxS7OkGjWj5QY=.a025a5b4-ddcf-47b5-946a-d6cacacfcf21@github.com>
Message-ID: <GK7fr3w_6fgYJ9jrTAbAMf1sumZT6StFCbWZEeCmsNQ=.d078a629-8baa-4c7e-b56f-f23ab3f12ded@github.com>

On Fri, 24 Feb 2023 17:09:56 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> Thanks for the above feedback, so as per the suggestions I will 1. consolidate the patterns and move those to the common module 2. modify the regex to verify that the command starts with a lowercase

We don't need to match any capital letters in command names as we don't have any such commands.

> **Question**: In case the command starts with '/' but does not match with the standard command regex, do we need to provide suggestions based on the mistyped command in the message (e.g. Do you mean 'integrate' instead of 'intergate'?) or a generic warning message suggested by Kevin well enough?

The generic message is enough.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From ihse at openjdk.org  Fri Feb 24 17:43:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 24 Feb 2023 17:43:44 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <PTmDdl4EsEJpy30WZBHvmmbwJFnYvVS0-hv-7AVlOh0=.5525a488-8000-4ac5-b048-fdeadf52f4c4@github.com>

On Fri, 24 Feb 2023 14:38:34 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

> 755: Anything starting with a "/" is treated as a command

An idea might be to compare if the entered text is "roughly" equals to a Skara command. This can be measured e.g. by comparing e.g. a simplistic soundex-conversion of the command, or possibly calculating the levenshtein distance; these algorithms sound a bit scary but should be rather simple to implement, if Java does not have anything similar already.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Mon Feb 27 19:22:40 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 19:22:40 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <sdtzjj3jiX-YLBbXVwBiD9pxv6NsCYn7Y-y-0dDfT5w=.faad5085-f358-41b2-abbb-b7a3a85187e4@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <sdtzjj3jiX-YLBbXVwBiD9pxv6NsCYn7Y-y-0dDfT5w=.faad5085-f358-41b2-abbb-b7a3a85187e4@github.com>
Message-ID: <gEL71CplaYfybToiTBAAWMU7_hbolmc_S_O9pTneSuw=.6c70ae1b-37b1-4975-af2d-52153713b7c0@github.com>

On Fri, 24 Feb 2023 16:02:06 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> OK, I can see your point. What do you think about also producing a comment with a warning (but not filtering the email) in case there is an unrecognized command with a `/` at the beginning of a line?

I forgot to respond to this. After having reviewed how users are actually interacting with the current functionality (bot replying to "bad" commands and emails being filtered, I think we absolutely must filter and react uniformly. That means if we react to something as being a command, then we should also filter the email, and vice versa.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Mon Feb 27 19:25:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 19:25:06 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
In-Reply-To: <PTmDdl4EsEJpy30WZBHvmmbwJFnYvVS0-hv-7AVlOh0=.5525a488-8000-4ac5-b048-fdeadf52f4c4@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <PTmDdl4EsEJpy30WZBHvmmbwJFnYvVS0-hv-7AVlOh0=.5525a488-8000-4ac5-b048-fdeadf52f4c4@github.com>
Message-ID: <uoi1ZaylEvRdkI_Adzi3jDz10jZ40X8QlMPKWm0vA5I=.339f521b-6722-4ef2-aa2f-7cbc6ffc97c8@github.com>

On Fri, 24 Feb 2023 17:41:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> An idea might be to compare if the entered text is "roughly" equals to a Skara command. This can be measured e.g. by comparing e.g. a simplistic soundex-conversion of the command, or possibly calculating the levenshtein distance; these algorithms sound a bit scary but should be rather simple to implement, if Java does not have anything similar already.

Yes, that kind of matching would be even better. Looking into such a solution could be an interesting followup to this fix. We currently don't use any external dependencies for Skara, and breaking that tradition shouldn't be done lightly.

-------------

PR: https://git.openjdk.org/skara/pull/1479

From duke at openjdk.org  Tue Feb 28 17:06:35 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Tue, 28 Feb 2023 17:06:35 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
 [v2]
In-Reply-To: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
Message-ID: <faDOWKLmKmcHh0bLbbV95WQIrSkmZOOjJrrC0dckaAs=.5e359004-32cd-46b7-bdf4-3caedc8eb345@github.com>

> 755: Anything starting with a "/" is treated as a command

Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:

  755:unified the regex for archive and execution command. Bot should react to invalid sakra commands

-------------

Changes:
  - all: https://git.openjdk.org/skara/pull/1479/files
  - new: https://git.openjdk.org/skara/pull/1479/files/77a3025b..4b125592

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=skara&pr=1479&range=01
 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1479&range=00-01

  Stats: 76 lines in 9 files changed: 55 ins; 6 del; 15 mod
  Patch: https://git.openjdk.org/skara/pull/1479.diff
  Fetch: git fetch https://git.openjdk.org/skara pull/1479/head:pull/1479

PR: https://git.openjdk.org/skara/pull/1479

From duke at openjdk.org  Tue Feb 28 19:29:07 2023
From: duke at openjdk.org (Vijay Kulkarni)
Date: Tue, 28 Feb 2023 19:29:07 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
 [v2]
In-Reply-To: <faDOWKLmKmcHh0bLbbV95WQIrSkmZOOjJrrC0dckaAs=.5e359004-32cd-46b7-bdf4-3caedc8eb345@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <faDOWKLmKmcHh0bLbbV95WQIrSkmZOOjJrrC0dckaAs=.5e359004-32cd-46b7-bdf4-3caedc8eb345@github.com>
Message-ID: <f8YhWTzlnHEj0kM53pgw7lydQpE0H4J0Tt57EsFvv0s=.ff5a1964-6e3f-45f7-8233-523baad34235@github.com>

On Tue, 28 Feb 2023 17:06:35 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

>> 755: Anything starting with a "/" is treated as a command
>
> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   755:unified the regex for archive and execution command. Bot should react to invalid sakra commands

Implemented suggested changes to 
1. unify the command identification check for the bot and archive
2. tightened the regex pattern to identify Skara-like commands more accurately. (lowercase and separated by white space).

-------------

PR: https://git.openjdk.org/skara/pull/1479

From erikj at openjdk.org  Tue Feb 28 21:35:37 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 21:35:37 GMT
Subject: RFR: 755: Anything starting with a "/" is treated as a command
 [v2]
In-Reply-To: <faDOWKLmKmcHh0bLbbV95WQIrSkmZOOjJrrC0dckaAs=.5e359004-32cd-46b7-bdf4-3caedc8eb345@github.com>
References: <yxkxpBDAWMVFULdYt9LvfVBQquqAYjPZn8GFgU1YmLM=.51f0055c-b65f-4b6b-8fdd-d65cda0e29e8@github.com>
 <faDOWKLmKmcHh0bLbbV95WQIrSkmZOOjJrrC0dckaAs=.5e359004-32cd-46b7-bdf4-3caedc8eb345@github.com>
Message-ID: <Oin-a85gTfVhFSLzIKtUcX5AFBAl8g-2gL7ME03b-DM=.b7a4e357-677b-491d-8d3b-95f19bdd7617@github.com>

On Tue, 28 Feb 2023 17:06:35 GMT, Vijay Kulkarni <duke at openjdk.org> wrote:

>> 755: Anything starting with a "/" is treated as a command
>
> Vijay Kulkarni has updated the pull request incrementally with one additional commit since the last revision:
> 
>   755:unified the regex for archive and execution command. Bot should react to invalid sakra commands

bots/mlbridge/build.gradle line 50:

> 48:     implementation project(':metrics')
> 49:     implementation project(':bots:common')
> 50:     implementation project(path: ':jbs')

What does the `path:` prefix mean here? If it's not significant, better stay with the same pattern as the other dependencies.

bots/mlbridge/src/main/java/module-info.java line 35:

> 33:     requires org.openjdk.skara.network;
> 34:     requires org.openjdk.skara.version;
> 35:     requires org.openjdk.skara.jbs;

Do we really require jbs now?

bots/pr/src/main/java/org/openjdk/skara/bots/pr/CommitCommandWorkItem.java line 118:

> 116:                     `/{0}` is not a recognized Skara PR command, so it was ignored and treated like an ordinary comment.
> 117:                     If you intended to issue a Skara command, use `/help` in a comment to see a complete list of Skara commands.
> 118:                     """, command.name()));

Since we are keeping the mail filtering rules the same as command execution, I don't think we should change this message.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 172:

> 170:                     `/{0}` is not a recognized Skara PR command, so it was ignored and treated like an ordinary comment
> 171:                     If you intended to issue a Skara command, use `/help` in a comment to see a complete list of Skara commands.
> 172:                     """, command.name()));

Same here, keep the message as is.

-------------

PR: https://git.openjdk.org/skara/pull/1479