From zsong at openjdk.org  Tue Jan  2 22:18:05 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 2 Jan 2024 22:18:05 GMT
Subject: RFR: 2131: Make second jcheck run work on merge-style PR
Message-ID: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>

When testing [SKARA-2115](https://bugs.openjdk.org/browse/SKARA-2115), I find that if we change the jcheck conf in the source branch of a merge style PR. The pr will NOT run jcheck against the localJCheckConf(merged conf of source and target JCheckConf).
After investigation, I realized that this bug exists since the first time we introduced the second jcheck run feature. This bug was partly fixed by introducing IsJCheckConfUpdatedInMergePR.
However, IsJCheckConfUpdatedInMergePR will only be set correctly when workItem.bot.jcheckMerge() is true.
To fix it, we should set isJCheckConfUpdatedInMergePR correctly when the PR is a merge-style PR.

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

Commit messages:
 - SKARA-2131

Changes: https://git.openjdk.org/skara/pull/1595/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1595&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2131
  Stats: 109 lines in 2 files changed: 99 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/skara/pull/1595.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1595/head:pull/1595

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

From erikj at openjdk.org  Wed Jan  3 13:40:10 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 Jan 2024 13:40:10 GMT
Subject: RFR: 2131: Make second jcheck run work on merge-style PR
In-Reply-To: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
References: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
Message-ID: <zzf85MDVL9ijcBxXUE0x4hkVAVBece30NcrDITFwm7g=.f9d2405a-1ea3-4f13-a28e-5c0c3aa25bcf@github.com>

On Tue, 2 Jan 2024 22:00:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When testing [SKARA-2115](https://bugs.openjdk.org/browse/SKARA-2115), I find that if we change the jcheck conf in the source branch of a merge style PR. The pr will NOT run jcheck against the localJCheckConf(merged conf of source and target JCheckConf).
> After investigation, I realized that this bug exists since the first time we introduced the second jcheck run feature. This bug was partly fixed by introducing IsJCheckConfUpdatedInMergePR.
> However, IsJCheckConfUpdatedInMergePR will only be set correctly when workItem.bot.jcheckMerge() is true.
> To fix it, we should set isJCheckConfUpdatedInMergePR correctly when the PR is a merge-style PR.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1595#pullrequestreview-1802087435

From zsong at openjdk.org  Wed Jan  3 17:23:44 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 3 Jan 2024 17:23:44 GMT
Subject: RFR: 2131: Make second jcheck run work on merge-style PR
In-Reply-To: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
References: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
Message-ID: <BRe9_iq_PnTCwlQodwtecGYiHL2zLFuy_tbM076k6gw=.7ce65bff-fe81-4947-a666-4eb88a1f79ac@github.com>

On Tue, 2 Jan 2024 22:00:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When testing [SKARA-2115](https://bugs.openjdk.org/browse/SKARA-2115), I find that if we change the jcheck conf in the source branch of a merge style PR. The pr will NOT run jcheck against the localJCheckConf(merged conf of source and target JCheckConf).
> After investigation, I realized that this bug exists since the first time we introduced the second jcheck run feature. This bug was partly fixed by introducing IsJCheckConfUpdatedInMergePR.
> However, IsJCheckConfUpdatedInMergePR will only be set correctly when workItem.bot.jcheckMerge() is true.
> To fix it, we should set isJCheckConfUpdatedInMergePR correctly when the PR is a merge-style PR.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1595#issuecomment-1875710780

From zsong at openjdk.org  Wed Jan  3 17:23:45 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 3 Jan 2024 17:23:45 GMT
Subject: Integrated: 2131: Make second jcheck run work on merge-style PR
In-Reply-To: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
References: <f6qpWok-Dk36qz0l-E7_BPg3e_AgYnfA0ogL-ymdtl4=.cc16ec0c-bac7-4819-a139-d079756f09a3@github.com>
Message-ID: <ozqSGtnsmjYYVuV-GpYOsP5ewJDl0zLozJ32jJ95ygA=.4ebd2bd6-6a3d-4a2f-b614-ef5bf0a0c793@github.com>

On Tue, 2 Jan 2024 22:00:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When testing [SKARA-2115](https://bugs.openjdk.org/browse/SKARA-2115), I find that if we change the jcheck conf in the source branch of a merge style PR. The pr will NOT run jcheck against the localJCheckConf(merged conf of source and target JCheckConf).
> After investigation, I realized that this bug exists since the first time we introduced the second jcheck run feature. This bug was partly fixed by introducing IsJCheckConfUpdatedInMergePR.
> However, IsJCheckConfUpdatedInMergePR will only be set correctly when workItem.bot.jcheckMerge() is true.
> To fix it, we should set isJCheckConfUpdatedInMergePR correctly when the PR is a merge-style PR.

This pull request has now been integrated.

Changeset: ef8238c3
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/ef8238c35070094e979a13ad872d105f883f3881
Stats:     109 lines in 2 files changed: 99 ins; 8 del; 2 mod

2131: Make second jcheck run work on merge-style PR

Reviewed-by: erikj

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

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

From shipilev at amazon.de  Tue Jan  9 15:53:10 2024
From: shipilev at amazon.de (Aleksey Shipilev)
Date: Tue, 9 Jan 2024 16:53:10 +0100
Subject: Bug report: bots report bad hashes after /backport
Message-ID: <f2bfff60-73f4-4552-ab10-46c3b1cba9d6@amazon.de>

Hi folks,

It seems bots are confused about the repository states. Is this something known?

I did `/backport jdk21u-dev` here:
 
https://github.com/openjdk/jdk/commit/eb9e754b3a439cc3ce36c2c9393bc8b250343844#commitcomment-136598429

Yet the bots say the commit hash is unknown:
   https://github.com/openjdk/jdk21u-dev/pull/151

-- 
Thanks,
-Aleksey



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879



From christoph.langer at sap.com  Tue Jan  9 16:48:47 2024
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 9 Jan 2024 16:48:47 +0000
Subject: Bug report: bots report bad hashes after /backport
In-Reply-To: <f2bfff60-73f4-4552-ab10-46c3b1cba9d6@amazon.de>
References: <f2bfff60-73f4-4552-ab10-46c3b1cba9d6@amazon.de>
Message-ID: <DU0PR02MB9800E350BCBDF2709848D2DE8A6A2@DU0PR02MB9800.eurprd02.prod.outlook.com>

Hi,

I see the same in jdk22: https://github.com/openjdk/jdk22/pull/43#issuecomment-1883062537

There must be something wrong with the overall system.

Best regards
Christoph

> -----Original Message-----
> From: skara-dev <skara-dev-retn at openjdk.org> On Behalf Of Aleksey Shipilev
> Sent: Dienstag, 9. Januar 2024 16:53
> To: skara-dev at openjdk.org
> Subject: Bug report: bots report bad hashes after /backport
> 
> Hi folks,
> 
> It seems bots are confused about the repository states. Is this something
> known?
> 
> I did `/backport jdk21u-dev` here:
> 
> https://github.com/openjdk/jdk/commit/eb9e754b3a439cc3ce36c2c9393bc8b
> 250343844#commitcomment-136598429
> 
> Yet the bots say the commit hash is unknown:
>    https://github.com/openjdk/jdk21u-dev/pull/151
> 
> --
> Thanks,
> -Aleksey
> 
> 
> 
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
> 


From zhao.song at oracle.com  Tue Jan  9 17:22:45 2024
From: zhao.song at oracle.com (Zhao Song)
Date: Tue, 9 Jan 2024 17:22:45 +0000
Subject: Bug report: bots report bad hashes after /backport
In-Reply-To: <DU0PR02MB9800E350BCBDF2709848D2DE8A6A2@DU0PR02MB9800.eurprd02.prod.outlook.com>
References: <f2bfff60-73f4-4552-ab10-46c3b1cba9d6@amazon.de>
 <DU0PR02MB9800E350BCBDF2709848D2DE8A6A2@DU0PR02MB9800.eurprd02.prod.outlook.com>
Message-ID: <DS7PR10MB4973738FB9A64B2E03BFD6D7846A2@DS7PR10MB4973.namprd10.prod.outlook.com>

Hi,

GitHub was experiencing issues few hours ago.
https://www.githubstatus.com/history

The incident is resolved right now, and I believe the bot will catch up.

Thank you,
Zhao

From: skara-dev <skara-dev-retn at openjdk.org> on behalf of Langer, Christoph <christoph.langer at sap.com>
Date: Tuesday, January 9, 2024 at 08:49
To: Aleksey Shipilev <shipilev at amazon.de>, skara-dev at openjdk.org <skara-dev at openjdk.org>
Subject: RE: Bug report: bots report bad hashes after /backport
Hi,

I see the same in jdk22: https://github.com/openjdk/jdk22/pull/43#issuecomment-1883062537

There must be something wrong with the overall system.

Best regards
Christoph

> -----Original Message-----
> From: skara-dev <skara-dev-retn at openjdk.org> On Behalf Of Aleksey Shipilev
> Sent: Dienstag, 9. Januar 2024 16:53
> To: skara-dev at openjdk.org
> Subject: Bug report: bots report bad hashes after /backport
>
> Hi folks,
>
> It seems bots are confused about the repository states. Is this something
> known?
>
> I did `/backport jdk21u-dev` here:
>
> https://github.com/openjdk/jdk/commit/eb9e754b3a439cc3ce36c2c9393bc8b
> 250343844#commitcomment-136598429
>
> Yet the bots say the commit hash is unknown:
>    https://github.com/openjdk/jdk21u-dev/pull/151
>
> --
> Thanks,
> -Aleksey
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20240109/82201852/attachment.htm>

From christoph.langer at sap.com  Tue Jan  9 21:49:37 2024
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 9 Jan 2024 21:49:37 +0000
Subject: Bug report: bots report bad hashes after /backport
In-Reply-To: <DS7PR10MB4973738FB9A64B2E03BFD6D7846A2@DS7PR10MB4973.namprd10.prod.outlook.com>
References: <f2bfff60-73f4-4552-ab10-46c3b1cba9d6@amazon.de>
 <DU0PR02MB9800E350BCBDF2709848D2DE8A6A2@DU0PR02MB9800.eurprd02.prod.outlook.com>
 <DS7PR10MB4973738FB9A64B2E03BFD6D7846A2@DS7PR10MB4973.namprd10.prod.outlook.com>
Message-ID: <DU0PR02MB9800399D74C26AB831ABD83B8A6A2@DU0PR02MB9800.eurprd02.prod.outlook.com>

Hi Zhao,

thanks for your efforts to resolve this. Seems to work now.

Cheers
Christoph

From: Zhao Song <zhao.song at oracle.com>
Sent: Dienstag, 9. Januar 2024 18:23
To: Langer, Christoph <christoph.langer at sap.com>; Aleksey Shipilev <shipilev at amazon.de>; skara-dev at openjdk.org
Subject: Re: Bug report: bots report bad hashes after /backport

You don't often get email from zhao.song at oracle.com<mailto:zhao.song at oracle.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hi,

GitHub was experiencing issues few hours ago.
https://www.githubstatus.com/history

The incident is resolved right now, and I believe the bot will catch up.

Thank you,
Zhao

From: skara-dev <skara-dev-retn at openjdk.org<mailto:skara-dev-retn at openjdk.org>> on behalf of Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>>
Date: Tuesday, January 9, 2024 at 08:49
To: Aleksey Shipilev <shipilev at amazon.de<mailto:shipilev at amazon.de>>, skara-dev at openjdk.org<mailto:skara-dev at openjdk.org> <skara-dev at openjdk.org<mailto:skara-dev at openjdk.org>>
Subject: RE: Bug report: bots report bad hashes after /backport
Hi,

I see the same in jdk22: https://github.com/openjdk/jdk22/pull/43#issuecomment-1883062537

There must be something wrong with the overall system.

Best regards
Christoph

> -----Original Message-----
> From: skara-dev <skara-dev-retn at openjdk.org<mailto:skara-dev-retn at openjdk.org>> On Behalf Of Aleksey Shipilev
> Sent: Dienstag, 9. Januar 2024 16:53
> To: skara-dev at openjdk.org<mailto:skara-dev at openjdk.org>
> Subject: Bug report: bots report bad hashes after /backport
>
> Hi folks,
>
> It seems bots are confused about the repository states. Is this something
> known?
>
> I did `/backport jdk21u-dev` here:
>
> https://github.com/openjdk/jdk/commit/eb9e754b3a439cc3ce36c2c9393bc8b
> 250343844#commitcomment-136598429
>
> Yet the bots say the commit hash is unknown:
>    https://github.com/openjdk/jdk21u-dev/pull/151
>
> --
> Thanks,
> -Aleksey
>
>
>
> Amazon Development Center Germany GmbH
> Krausenstr. 38
> 10117 Berlin
> Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
> Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
> Sitz: Berlin
> Ust-ID: DE 289 237 879
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20240109/91455c5c/attachment-0001.htm>

From ehelin at openjdk.org  Wed Jan 10 09:17:24 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Wed, 10 Jan 2024 09:17:24 GMT
Subject: RFR: 2137: Add integrity check to integrate and sponsor commands
Message-ID: <rTkum7HRbPasVlZ6CN-Wm_Ss_cL3zPu0hS4gOIvZcQY=.a72d2aca-76d4-487e-9c4c-3206b40cb7f7@github.com>

Hi all,

please review this patch that adds that makes it possible to enable an "integrity check" for the `/integrate` and `/sponsor` commands. The integrity check will be run before a commit is pushed and ensures that the most recent commit on the target branch was integrated by the bots.

The integrity check is implemented by utilizing an additional repository that for each repository and branch combination for a forge stores the two most recent commits pushed by the bots. This is information is stored in a text file called `heads.txt`, the first list line being the full hash of the most recent commit and the second line being the full hash of the next to most recent commit. The hashes of the two most recent commits are needed for the scenario when a bot throws an exception _after_ the file `heads.txt` in the integrity repo has been updated but _before_ the actual commit has been pushed to the target branch of the pull request. The `IntegrityVerifier` will recognize this case the next time a commit is verified (via a call to `verifyBranch`) and automatically correct the data in the integrity repository.

I also added a couple of new unit tests as well as two larger unit tests for the `/integrate` and `/sponsor` commands.

Thanks,
Erik

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

Commit messages:
 - 2137

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

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

From erikj at openjdk.org  Wed Jan 10 20:48:07 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Jan 2024 20:48:07 GMT
Subject: RFR: 2137: Add integrity check to integrate and sponsor commands
In-Reply-To: <rTkum7HRbPasVlZ6CN-Wm_Ss_cL3zPu0hS4gOIvZcQY=.a72d2aca-76d4-487e-9c4c-3206b40cb7f7@github.com>
References: <rTkum7HRbPasVlZ6CN-Wm_Ss_cL3zPu0hS4gOIvZcQY=.a72d2aca-76d4-487e-9c4c-3206b40cb7f7@github.com>
Message-ID: <r2GcEVTRzDbYlqYnmB8dFa9N_nnlCyc-1gBp102_8Xk=.5ee93112-bdee-4886-9cff-d2ecf5f1360f@github.com>

On Wed, 10 Jan 2024 09:12:50 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that adds that makes it possible to enable an "integrity check" for the `/integrate` and `/sponsor` commands. The integrity check will be run before a commit is pushed and ensures that the most recent commit on the target branch was integrated by the bots.
> 
> The integrity check is implemented by utilizing an additional repository that for each repository and branch combination for a forge stores the two most recent commits pushed by the bots. This is information is stored in a text file called `heads.txt`, the first list line being the full hash of the most recent commit and the second line being the full hash of the next to most recent commit. The hashes of the two most recent commits are needed for the scenario when a bot throws an exception _after_ the file `heads.txt` in the integrity repo has been updated but _before_ the actual commit has been pushed to the target branch of the pull request. The `IntegrityVerifier` will recognize this case the next time a commit is verified (via a call to `verifyBranch`) and automatically correct the data in the integrity repository.
> 
> I also added a couple of new unit tests as well as two larger unit tests for the `/integrate` and `/sponsor` commands.
> 
> Thanks,
> Erik

We discussed this offline already but summarizing here for the record.

I think the integrity repo should be handled more similar to how we handle for example the notifier tracking repos. In those repos, the default is just a top level file in the master branch for each tracked repository. It's also possible to override the base filename. Having similar patterns makes it easier for administrators when the data needs to be inspected or possibly manually modified. In this case we would still need a separate file for each repo/branch combination. If you want to make part of that file path a directory, I'm fine with that.

I also think that we should use the `HostedRepository.writeFileContents` API instead of cloning/fetching/pushing through a local repository. It will be way more efficient in the long run as validating and fetching a book keeping repository has been shown to be extremely costly as it grows over time.

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

PR Review: https://git.openjdk.org/skara/pull/1596#pullrequestreview-1814144141

From zsong at openjdk.org  Wed Jan 10 22:51:35 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 10 Jan 2024 22:51:35 GMT
Subject: RFR: 2138: Backport instructions should include suggested PR comment
Message-ID: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>

In this patch, if user use the backport command to create a backport, regardless the backport can be created automatically or not, the user will get a suggestion for the pull request body.

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

Commit messages:
 - SKARA-2138

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

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

From erikj at openjdk.org  Wed Jan 10 23:28:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 Jan 2024 23:28:54 GMT
Subject: RFR: 2138: Backport instructions should include suggested PR
 comment
In-Reply-To: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
References: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
Message-ID: <Xx8ooJCDHGhOfCMNMuK_EVFrl0ds9sc7chWn5cU2yqY=.79cdfefa-9fbb-4fc4-9f20-c77d92e9e762@github.com>

On Wed, 10 Jan 2024 21:34:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this patch, if user use the backport command to create a backport, regardless the backport can be created automatically or not, the user will get a suggestion for the pull request body.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1597#pullrequestreview-1814378938

From zsong at openjdk.org  Wed Jan 10 23:51:40 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 10 Jan 2024 23:51:40 GMT
Subject: RFR: 2138: Backport instructions should include suggested PR
 comment
In-Reply-To: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
References: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
Message-ID: <VdWInDu7C_KSDFeAEzbtxRVWBDLWTQKiOhUaDxjBB5c=.9e1cf8d9-1e68-499d-beca-3ac7a5de0f89@github.com>

On Wed, 10 Jan 2024 21:34:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this patch, if user use the backport command to create a backport, regardless the backport can be created automatically or not, the user will get a suggestion for the pull request body.

Thanks!

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

PR Comment: https://git.openjdk.org/skara/pull/1597#issuecomment-1885936630

From zsong at openjdk.org  Wed Jan 10 23:51:40 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 10 Jan 2024 23:51:40 GMT
Subject: Integrated: 2138: Backport instructions should include suggested PR
 comment
In-Reply-To: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
References: <FDFUgLLY7N731tABUOPCsWxAP68TEc8UIy3RxQzq5Qc=.041d346b-a4f8-46c5-b10f-88d9f8b2c2b9@github.com>
Message-ID: <CKNQ_g0iP_5yNcfmo6FS_kXxAOx6EnJGxiVBzxfJa1M=.2bd4f76a-ba69-45b8-affc-27a6921c8213@github.com>

On Wed, 10 Jan 2024 21:34:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In this patch, if user use the backport command to create a backport, regardless the backport can be created automatically or not, the user will get a suggestion for the pull request body.

This pull request has now been integrated.

Changeset: b258994d
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/b258994d4dc72f805e035865b757314673a29563
Stats:     72 lines in 3 files changed: 38 ins; 33 del; 1 mod

2138: Backport instructions should include suggested PR comment

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Thu Jan 11 00:13:29 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Jan 2024 00:13:29 GMT
Subject: RFR: 2137: Add integrity check to integrate and sponsor commands
In-Reply-To: <rTkum7HRbPasVlZ6CN-Wm_Ss_cL3zPu0hS4gOIvZcQY=.a72d2aca-76d4-487e-9c4c-3206b40cb7f7@github.com>
References: <rTkum7HRbPasVlZ6CN-Wm_Ss_cL3zPu0hS4gOIvZcQY=.a72d2aca-76d4-487e-9c4c-3206b40cb7f7@github.com>
Message-ID: <n02_TiAmxSslxhGfr7yjCrg961E1ISMyES97rD_VEWU=.9db2d2f3-727c-44be-a916-5ca6b990e9b2@github.com>

On Wed, 10 Jan 2024 09:12:50 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that adds that makes it possible to enable an "integrity check" for the `/integrate` and `/sponsor` commands. The integrity check will be run before a commit is pushed and ensures that the most recent commit on the target branch was integrated by the bots.
> 
> The integrity check is implemented by utilizing an additional repository that for each repository and branch combination for a forge stores the two most recent commits pushed by the bots. This is information is stored in a text file called `heads.txt`, the first list line being the full hash of the most recent commit and the second line being the full hash of the next to most recent commit. The hashes of the two most recent commits are needed for the scenario when a bot throws an exception _after_ the file `heads.txt` in the integrity repo has been updated but _before_ the actual commit has been pushed to the target branch of the pull request. The `IntegrityVerifier` will recognize this case the next time a commit is verified (via a call to `verifyBranch`) and automatically correct the data in the integrity repository.
> 
> I also added a couple of new unit tests as well as two larger unit tests for the `/integrate` and `/sponsor` commands.
> 
> Thanks,
> Erik

May I know why do we need this integrity check?

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

PR Comment: https://git.openjdk.org/skara/pull/1596#issuecomment-1885962880

From zsong at openjdk.org  Thu Jan 11 21:23:03 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Jan 2024 21:23:03 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in /backport
 command reply
Message-ID: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>

After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

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

Commit messages:
 - SKARA-2141

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

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

From zsong at openjdk.org  Thu Jan 11 21:23:03 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Jan 2024 21:23:03 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply
In-Reply-To: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
Message-ID: <0WhjirRecQg1IVSA4I_kAX5i-E8cLdtUs493U0KvfkU=.edee5568-1bc0-48cb-aca8-4cc2d26db269@github.com>

On Thu, 11 Jan 2024 20:30:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

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

> 414:                 reply.print("@");
> 415:                 reply.print(realUser.username());
> 416:                 reply.print(" ");

If the backport command was used in a pull request, in the beginning of the reply message, the bot will @`the author of the pull request` and @`the command issuer`. 
To be clear, I would like to @`the command issuer` again before the reminder.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1598#discussion_r1449366891

From erikj at openjdk.org  Thu Jan 11 22:51:06 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Jan 2024 22:51:06 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply
In-Reply-To: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
Message-ID: <sYSlOp1NyJpKiu6lwydG7XY0ykZSQr6WEUP46EAXwU0=.536dc191-4005-4308-8b48-32b79840c87d@github.com>

On Thu, 11 Jan 2024 20:30:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

I just realized that we have the `fork.canPush` check further up. We could make this comment conditional on that as well. If the user already has push permission, we don't need to remind them of this.

In this case, we should change the message a bit.

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

PR Review: https://git.openjdk.org/skara/pull/1598#pullrequestreview-1816962348

From zsong at openjdk.org  Thu Jan 11 22:54:20 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Jan 2024 22:54:20 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply
In-Reply-To: <sYSlOp1NyJpKiu6lwydG7XY0ykZSQr6WEUP46EAXwU0=.536dc191-4005-4308-8b48-32b79840c87d@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
 <sYSlOp1NyJpKiu6lwydG7XY0ykZSQr6WEUP46EAXwU0=.536dc191-4005-4308-8b48-32b79840c87d@github.com>
Message-ID: <aXmLHxcIbEYrInaAehlKkIFucsad8XrxH1eC71hffu8=.bba0655d-6837-4a19-b045-f10e50bf39b0@github.com>

On Thu, 11 Jan 2024 22:48:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I just realized that we have the `fork.canPush` check further up. We could make this comment conditional on that as well. If the user already has push permission, we don't need to remind them of this.
> 
> In this case, we should change the message a bit.

Ah, right! I will change it.

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

PR Comment: https://git.openjdk.org/skara/pull/1598#issuecomment-1888094087

From erikj at openjdk.org  Thu Jan 11 22:54:21 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Jan 2024 22:54:21 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply
In-Reply-To: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
Message-ID: <mWMAuZNZyskyHxHb86lbqbr_YIjw1D6d4hZuNA9y864=.8e48e1ff-12ab-4d97-9c5a-022c6ff2d7bc@github.com>

On Thu, 11 Jan 2024 20:30:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

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

> 416:                 reply.print(" ");
> 417:                 reply.print("If this is the first time you are using the /backport command for this particular target repository, " +
> 418:                         "a `collaborator` invite will be sent out for my fork [" + fork.name() + "](" + fork.url() + "). You will need to accept this invite before you can proceed.\n");

If we only print this when the user doesn't have push permission, the message should be something like this instead:

"You are not yet a collaborator in my fork (name). An invite will be sent out and you need to accept it before you can proceed."

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

PR Review Comment: https://git.openjdk.org/skara/pull/1598#discussion_r1449490575

From zsong at openjdk.org  Thu Jan 11 23:13:41 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Jan 2024 23:13:41 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply [v2]
In-Reply-To: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
Message-ID: <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>

> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

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

 - update
 - only send the reminder when user doesn't have the push access

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1598/files
  - new: https://git.openjdk.org/skara/pull/1598/files/1ac34cb5..d4df3bb3

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

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

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

From erikj at openjdk.org  Fri Jan 12 00:43:04 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Jan 2024 00:43:04 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply [v2]
In-Reply-To: <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
 <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
Message-ID: <M-ISsKIXdqwxLKap23dpmCDRkjgB9a6u7ZVcSW6rIso=.b16a82f0-a4c9-425c-a2e1-244e36042c65@github.com>

On Thu, 11 Jan 2024 23:13:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - only send the reminder when user doesn't have the push access

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1598#pullrequestreview-1817074285

From goetz at openjdk.org  Fri Jan 12 06:43:44 2024
From: goetz at openjdk.org (Goetz Lindenmaier)
Date: Fri, 12 Jan 2024 06:43:44 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply [v2]
In-Reply-To: <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
 <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
Message-ID: <FgM5InbRgXCaJ50fXCwB42lIYgTPPSy1B62QmLqtxRg=.48606dc4-a69c-4e34-8643-d95be36fe90b@github.com>

On Thu, 11 Jan 2024 23:13:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - only send the reminder when user doesn't have the push access

Thanks for this nice improvement!

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

PR Comment: https://git.openjdk.org/skara/pull/1598#issuecomment-1888515569

From ehelin at openjdk.org  Fri Jan 12 14:01:53 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 12 Jan 2024 14:01:53 GMT
Subject: RFR: 2144: Bot image is only built for Linux x64
Message-ID: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>

Hi all,

please review this small patch that fixes the `bots` target in `build.gradle`. The problem is that the `bots` target in `build.gradle` tries to unpack a `.zip` file named after the local operating system and architecture, but we only ever build the bot jimage for Linux x64. The `bots` target should therefore only try to extract a `linux-x64` image.

### Testing
- [x] Tested locally on macOS aarch64

Thanks,
Erik

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

Commit messages:
 - 2144

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

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

From erikj at openjdk.org  Fri Jan 12 14:06:31 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 12 Jan 2024 14:06:31 GMT
Subject: RFR: 2144: Bot image is only built for Linux x64
In-Reply-To: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>
References: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>
Message-ID: <ETp1PRy_5QvdLWlE-Wy4fIkujZAIzK_JyOmoPiCcrZ0=.a13a286a-56ab-49f3-8ae1-8f63dea95f26@github.com>

On Fri, 12 Jan 2024 13:58:42 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this small patch that fixes the `bots` target in `build.gradle`. The problem is that the `bots` target in `build.gradle` tries to unpack a `.zip` file named after the local operating system and architecture, but we only ever build the bot jimage for Linux x64. The `bots` target should therefore only try to extract a `linux-x64` image.
> 
> ### Testing
> - [x] Tested locally on macOS aarch64
> 
> Thanks,
> Erik

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1599#pullrequestreview-1818334403

From zsong at openjdk.org  Fri Jan 12 18:00:19 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 12 Jan 2024 18:00:19 GMT
Subject: RFR: 2141: Inform user about accepting fork repo invite in
 /backport command reply [v2]
In-Reply-To: <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
 <qwyiNYkODmKTRUCquF1S55S1p72Teu7DCOu7WoqGRL8=.c52adec1-58a3-4563-881d-7228186bf4d9@github.com>
Message-ID: <UuVPTcKhq07j-X1cm-Xl_y0u4nfT3hV3FDgpXkcuhF0=.6ae49c25-06e1-45d1-a693-fec49dfb32c4@github.com>

On Thu, 11 Jan 2024 23:13:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - only send the reminder when user doesn't have the push access

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1598#issuecomment-1889727826

From zsong at openjdk.org  Fri Jan 12 18:00:19 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 12 Jan 2024 18:00:19 GMT
Subject: Integrated: 2141: Inform user about accepting fork repo invite in
 /backport command reply
In-Reply-To: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
References: <awHwnVEdlklELxY7cJyBBNstSJACwCoE6l-8-QNibuI=.8399d678-aa3e-4987-991a-a3efcdbd935c@github.com>
Message-ID: <GjfG-sG_AVXa88wOQc3TY6KxCqJkQ4CIAcimMHVrhYs=.2ba26d70-99c9-4464-a599-a362829d74cc@github.com>

On Thu, 11 Jan 2024 20:30:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After users issued /backport command to create backport PRs in GitHub, skara bot will invite the users to be collaborators of the bot's fork. Sometimes, the users will ignore the invitation and later when they are trying to update the backport branch, they will find they don't have the access. This patch is trying to add a comment to remind the user to accept the invitation.

This pull request has now been integrated.

Changeset: 60084467
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/60084467124bf9f2e5a337d86775654697e301e2
Stats:     9 lines in 1 file changed: 7 ins; 0 del; 2 mod

2141: Inform user about accepting fork repo invite in /backport command reply

Reviewed-by: erikj

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

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

From ehelin at openjdk.org  Fri Jan 12 19:36:11 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 12 Jan 2024 19:36:11 GMT
Subject: RFR: 2144: Bot image is only built for Linux x64
In-Reply-To: <ETp1PRy_5QvdLWlE-Wy4fIkujZAIzK_JyOmoPiCcrZ0=.a13a286a-56ab-49f3-8ae1-8f63dea95f26@github.com>
References: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>
 <ETp1PRy_5QvdLWlE-Wy4fIkujZAIzK_JyOmoPiCcrZ0=.a13a286a-56ab-49f3-8ae1-8f63dea95f26@github.com>
Message-ID: <jwxmMlY-3q7VMO8rmBOpUSUXDmvVq72lxlp6BZnPYzI=.62dd3286-32c0-4b98-b828-e29d99da8529@github.com>

On Fri, 12 Jan 2024 14:04:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all,
>> 
>> please review this small patch that fixes the `bots` target in `build.gradle`. The problem is that the `bots` target in `build.gradle` tries to unpack a `.zip` file named after the local operating system and architecture, but we only ever build the bot jimage for Linux x64. The `bots` target should therefore only try to extract a `linux-x64` image.
>> 
>> ### Testing
>> - [x] Tested locally on macOS aarch64
>> 
>> Thanks,
>> Erik
>
> Marked as reviewed by erikj (Lead).

Thanks @erikj79 for reviewing!

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

PR Comment: https://git.openjdk.org/skara/pull/1599#issuecomment-1889843649

From ehelin at openjdk.org  Fri Jan 12 19:36:11 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 12 Jan 2024 19:36:11 GMT
Subject: Integrated: 2144: Bot image is only built for Linux x64
In-Reply-To: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>
References: <rhq_Sy8gF2por-BkBjhZj6fX5_70X4cRgZ0ANrZ4zEQ=.9c3d13c5-d38d-48f9-a691-4e1d3c92895d@github.com>
Message-ID: <OGmPVx9-tOfMxuzo95TO4UiMOgwocvPMT08iQ6IU6L8=.f708722d-82a7-4a25-b16b-ab5ca91a634d@github.com>

On Fri, 12 Jan 2024 13:58:42 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this small patch that fixes the `bots` target in `build.gradle`. The problem is that the `bots` target in `build.gradle` tries to unpack a `.zip` file named after the local operating system and architecture, but we only ever build the bot jimage for Linux x64. The `bots` target should therefore only try to extract a `linux-x64` image.
> 
> ### Testing
> - [x] Tested locally on macOS aarch64
> 
> Thanks,
> Erik

This pull request has now been integrated.

Changeset: 2054fbf1
Author:    Erik Duveblad <ehelin at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/2054fbf142b9275b19bde9b905b383e89abd5453
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

2144: Bot image is only built for Linux x64

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Tue Jan 16 23:41:09 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Jan 2024 23:41:09 GMT
Subject: RFR: 2143: Support selective tags mirroring
Message-ID: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>

We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have

"branches": Is either a string of one branch pattern or an array of multiple branch patterns
"tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set

Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.

When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.

We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.

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

Commit messages:
 - SKARA-2143

Changes: https://git.openjdk.org/skara/pull/1600/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1600&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2143
  Stats: 281 lines in 7 files changed: 257 ins; 10 del; 14 mod
  Patch: https://git.openjdk.org/skara/pull/1600.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1600/head:pull/1600

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

From ihse at openjdk.org  Wed Jan 17 08:37:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Jan 2024 08:37:47 GMT
Subject: RFR: 2143: Support selective tags mirroring
In-Reply-To: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
Message-ID: <LDW5CZj041yZZtFnV_ANvE6CKx2vcTQqY_ZIKusBZ7g=.8004015c-5063-46f5-b990-992b3f520a31@github.com>

On Tue, 16 Jan 2024 23:36:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
> 
> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
> 
> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
> 
> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
> 
> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.

Looks good as far as I can tell.

vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 654:

> 652:     @Override
> 653:     public void push(String refspec, URI uri, boolean force) throws IOException {
> 654:         if (force && !refspec.equals("+")) {

Are you sure you did not mean 
Suggestion:

        if (force && !refspec.beginsWith("+")) {

?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1600#pullrequestreview-1826753300
PR Review Comment: https://git.openjdk.org/skara/pull/1600#discussion_r1454945960

From ehelin at openjdk.org  Wed Jan 17 13:31:19 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Wed, 17 Jan 2024 13:31:19 GMT
Subject: RFR: 2143: Support selective tags mirroring
In-Reply-To: <LDW5CZj041yZZtFnV_ANvE6CKx2vcTQqY_ZIKusBZ7g=.8004015c-5063-46f5-b990-992b3f520a31@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
 <LDW5CZj041yZZtFnV_ANvE6CKx2vcTQqY_ZIKusBZ7g=.8004015c-5063-46f5-b990-992b3f520a31@github.com>
Message-ID: <5SJ-oJ4qSzn_4Tfm2dSdQbY04VxAbzNCYsXX24tcFUQ=.07aa6259-1c73-4271-84a9-d9004caa2112@github.com>

On Wed, 17 Jan 2024 08:35:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
>> 
>> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
>> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
>> 
>> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
>> 
>> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
>> 
>> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.
>
> vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 654:
> 
>> 652:     @Override
>> 653:     public void push(String refspec, URI uri, boolean force) throws IOException {
>> 654:         if (force && !refspec.equals("+")) {
> 
> Are you sure you did not mean 
> Suggestion:
> 
>         if (force && !refspec.beginsWith("+")) {
> 
> ?

I would have opted to just skip the `boolean force` parameter. If we are already entrusting the user to supply a correct refspec then they will probably know that they should prefix the refspec with a `+` if they want to force push.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1600#discussion_r1455565650

From erikj at openjdk.org  Wed Jan 17 19:27:46 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 19:27:46 GMT
Subject: RFR: 2143: Support selective tags mirroring [v2]
In-Reply-To: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
Message-ID: <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>

> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
> 
> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
> 
> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
> 
> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
> 
> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.

Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove force

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1600/files
  - new: https://git.openjdk.org/skara/pull/1600/files/27f9e5d5..e1addb69

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

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

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

From erikj at openjdk.org  Wed Jan 17 19:27:47 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 19:27:47 GMT
Subject: RFR: 2143: Support selective tags mirroring [v2]
In-Reply-To: <5SJ-oJ4qSzn_4Tfm2dSdQbY04VxAbzNCYsXX24tcFUQ=.07aa6259-1c73-4271-84a9-d9004caa2112@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
 <LDW5CZj041yZZtFnV_ANvE6CKx2vcTQqY_ZIKusBZ7g=.8004015c-5063-46f5-b990-992b3f520a31@github.com>
 <5SJ-oJ4qSzn_4Tfm2dSdQbY04VxAbzNCYsXX24tcFUQ=.07aa6259-1c73-4271-84a9-d9004caa2112@github.com>
Message-ID: <Xrhem3bNOOIbYrGeazu6ixmsMCkoZCh4C8YSGpKuShE=.008c878b-1293-498a-ad71-495400e35d2f@github.com>

On Wed, 17 Jan 2024 13:29:06 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

>> vcs/src/main/java/org/openjdk/skara/vcs/git/GitRepository.java line 654:
>> 
>>> 652:     @Override
>>> 653:     public void push(String refspec, URI uri, boolean force) throws IOException {
>>> 654:         if (force && !refspec.equals("+")) {
>> 
>> Are you sure you did not mean 
>> Suggestion:
>> 
>>         if (force && !refspec.beginsWith("+")) {
>> 
>> ?
>
> I would have opted to just skip the `boolean force` parameter. If we are already entrusting the user to supply a correct refspec then they will probably know that they should prefix the refspec with a `+` if they want to force push.

You are right, I meant beginsWith. But having thought about it, I think Erik has a point. We shouldn't modify the refspec given by the user.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1600#discussion_r1456362486

From zsong at openjdk.org  Wed Jan 17 21:27:48 2024
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 17 Jan 2024 21:27:48 GMT
Subject: RFR: 2143: Support selective tags mirroring [v2]
In-Reply-To: <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
 <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
Message-ID: <-7Il_hdhhq8hrg7ly6d3YN96m6XSrW04N-YU2puN4uw=.562159b0-f0d6-4cf5-a25d-cdab05da0fab@github.com>

On Wed, 17 Jan 2024 19:27:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
>> 
>> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
>> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
>> 
>> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
>> 
>> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
>> 
>> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove force

LGTM

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

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1600#pullrequestreview-1828216723

From erikj at openjdk.org  Wed Jan 17 23:11:48 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Jan 2024 23:11:48 GMT
Subject: RFR: 2143: Support selective tags mirroring [v2]
In-Reply-To: <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
 <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
Message-ID: <jr7F04tyjNY9YdEH_zYqvDDzOf0-6T-EWPpOMto0a8E=.00cf35df-7626-4120-af0f-d87a548b9619@github.com>

On Wed, 17 Jan 2024 19:27:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
>> 
>> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
>> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
>> 
>> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
>> 
>> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
>> 
>> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove force

Test comment.

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

PR Comment: https://git.openjdk.org/skara/pull/1600#issuecomment-1897352161

From ihse at openjdk.org  Thu Jan 18 07:42:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Jan 2024 07:42:20 GMT
Subject: RFR: 2143: Support selective tags mirroring [v2]
In-Reply-To: <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
 <N6-iWjuYR2uU8XyDgaV9uJQasPwMNHdkHYuBGMf9_b8=.36c72d83-308c-43c8-a8ff-77ca2d39a544@github.com>
Message-ID: <nZ7P94VZ85U1KqbjlXsjkVuysfq2X9MkpIYH85LHZME=.fce7ace5-abe8-4627-bc14-b07493cbca22@github.com>

On Wed, 17 Jan 2024 19:27:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
>> 
>> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
>> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
>> 
>> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
>> 
>> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
>> 
>> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove force

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1600#pullrequestreview-1829040603

From ehelin at openjdk.org  Thu Jan 18 09:23:59 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Thu, 18 Jan 2024 09:23:59 GMT
Subject: RFR: 2149: Allow multiple query parameters with the same key
Message-ID: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>

Hi all.

please review this patch that makes `RestRequest` support multiple query parameters with the same key. This idiom is sometimes used in REST APIs (for example GitLab's REST API). The query parameters should always be kept in program order, since some REST APIs (e.g. GitLab) care about the order of the query parameters.

I also added a new `build` method on `RestRequest` to ease unit testing.

### Testing
- [x] Added a bunch of unit tests

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

Commit messages:
 - 2149

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

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

From ehelin at openjdk.org  Thu Jan 18 13:21:59 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Thu, 18 Jan 2024 13:21:59 GMT
Subject: RFR: 2150: Allow pull requests to have the title "Merge"
Message-ID: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>

Hi all,

please review this patch that allow "merge style" pull requests to have just the title "Merge". If the title is just "Merge" then the bots will rewrite the title to `Merge <HEAD>` where `<HEAD>` is the HEAD of the pull request source branch. This is useful if the integrator knows that they want the HEAD of the pull request source branch as the second parent for the resulting merge commit (this removes the need to manually specify the HEAD hash in the PR title).

### Testing
- [x] Added a new unit test

Thanks,
Erik

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

Commit messages:
 - Fix whitespace
 - 2150

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

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

From erikj at openjdk.org  Thu Jan 18 14:23:42 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Jan 2024 14:23:42 GMT
Subject: Integrated: 2143: Support selective tags mirroring
In-Reply-To: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
References: <vUam2vk9f2Z9BiE0HGbuFGt1mF_-SErDiQ7NuXcIshk=.bc1ede2d-84db-42e6-a09f-e5fbdcfdecd3@github.com>
Message-ID: <pth5driwySkJqNxCaa9V4F8fGx6J-1WgFyLBdaFqJHk=.12d0d6af-3eb8-4073-ae4f-f161e090dcc6@github.com>

On Tue, 16 Jan 2024 23:36:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> We need a way to mirror tags selectively. Here is how I think I want to solve this. We currently have
> 
> "branches": Is either a string of one branch pattern or an array of multiple branch patterns
> "tags": Takes either "include" or "only", if value is "only", "branches" cannot also be set
> 
> Instead of trying to somehow bend the "tags" parameter into taking some kind of patterns, I want to introduce a new parameter "refspecs". The value is an array (or a single string for convenience). Each string constitutes a single refspec that will be given unmodified to a "git push" command (with a + for force if not already present). The configuration becomes a bit more verbose by using this format, but it's also much more powerful. It makes it possible to express more complex mappings using the mirror bot, which may very well be needed when we start using branches more actively.
> 
> When setting "refspecs", we do not accept either "branches" or "tags" in the same configuration.
> 
> We still pull everything to the local repository in the bot. The refspec is only applied to the push command. Keeping the local repo the same as the source repo reduced the risk of bot configs interfering with each other through conflicting configurations.

This pull request has now been integrated.

Changeset: 88c014cb
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/88c014cb29acb59cd26c88769fefeb3e820554b1
Stats:     278 lines in 7 files changed: 254 ins; 10 del; 14 mod

2143: Support selective tags mirroring

Reviewed-by: ihse, zsong

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

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

From erikj at openjdk.org  Thu Jan 18 18:51:53 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Jan 2024 18:51:53 GMT
Subject: RFR: 2149: Allow multiple query parameters with the same key
In-Reply-To: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
References: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
Message-ID: <Yho0ARwr0PBF37L3CMmy8KZWdQBp_W2frkbGMZ0vRgU=.b2de23f5-55fd-4f22-bc47-c675a478bfd7@github.com>

On Thu, 18 Jan 2024 09:19:32 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all.
> 
> please review this patch that makes `RestRequest` support multiple query parameters with the same key. This idiom is sometimes used in REST APIs (for example GitLab's REST API). The query parameters should always be kept in program order, since some REST APIs (e.g. GitLab) care about the order of the query parameters.
> 
> I also added a new `build` method on `RestRequest` to ease unit testing.
> 
> ### Testing
> - [x] Added a bunch of unit tests

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1601#pullrequestreview-1830360170

From erikj at openjdk.org  Thu Jan 18 18:56:42 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Jan 2024 18:56:42 GMT
Subject: RFR: 2150: Allow pull requests to have the title "Merge"
In-Reply-To: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
References: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
Message-ID: <pWsD-eOEpWaKQ9jk6VDjZUlK8zavVyIPF7OKzcOtZcQ=.f81322b7-9540-4d90-b5b2-de133670fbb2@github.com>

On Thu, 18 Jan 2024 09:26:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that allow "merge style" pull requests to have just the title "Merge". If the title is just "Merge" then the bots will rewrite the title to `Merge <HEAD>` where `<HEAD>` is the HEAD of the pull request source branch. This is useful if the integrator knows that they want the HEAD of the pull request source branch as the second parent for the resulting merge commit (this removes the need to manually specify the HEAD hash in the PR title).
> 
> ### Testing
> - [x] Added a new unit test
> 
> Thanks,
> Erik

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1602#pullrequestreview-1830367012

From zsong at openjdk.org  Thu Jan 18 21:46:38 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Jan 2024 21:46:38 GMT
Subject: RFR: 2150: Allow pull requests to have the title "Merge"
In-Reply-To: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
References: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
Message-ID: <HWsdsfiZRbPbTRbSSsaJE3p_YGPc-qax7WOoABCxlQM=.e6fe9272-694f-4537-9ad5-7d1ceef5d135@github.com>

On Thu, 18 Jan 2024 09:26:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that allow "merge style" pull requests to have just the title "Merge". If the title is just "Merge" then the bots will rewrite the title to `Merge <HEAD>` where `<HEAD>` is the HEAD of the pull request source branch. This is useful if the integrator knows that they want the HEAD of the pull request source branch as the second parent for the resulting merge commit (this removes the need to manually specify the HEAD hash in the PR title).
> 
> ### Testing
> - [x] Added a new unit test
> 
> Thanks,
> Erik

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1602#pullrequestreview-1830606259

From zsong at openjdk.org  Thu Jan 18 22:50:32 2024
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Jan 2024 22:50:32 GMT
Subject: RFR: 2149: Allow multiple query parameters with the same key
In-Reply-To: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
References: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
Message-ID: <GSf6hDGBQVsjgvV41OVxGq8L3sDYWxMWpBpZnIM47MI=.2967816e-b0c8-4f8a-a448-7b2ad42b11ea@github.com>

On Thu, 18 Jan 2024 09:19:32 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all.
> 
> please review this patch that makes `RestRequest` support multiple query parameters with the same key. This idiom is sometimes used in REST APIs (for example GitLab's REST API). The query parameters should always be kept in program order, since some REST APIs (e.g. GitLab) care about the order of the query parameters.
> 
> I also added a new `build` method on `RestRequest` to ease unit testing.
> 
> ### Testing
> - [x] Added a bunch of unit tests

LGTM

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

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1601#pullrequestreview-1830681373

From ehelin at openjdk.org  Fri Jan 19 09:55:34 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 19 Jan 2024 09:55:34 GMT
Subject: RFR: 2149: Allow multiple query parameters with the same key
In-Reply-To: <Yho0ARwr0PBF37L3CMmy8KZWdQBp_W2frkbGMZ0vRgU=.b2de23f5-55fd-4f22-bc47-c675a478bfd7@github.com>
References: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
 <Yho0ARwr0PBF37L3CMmy8KZWdQBp_W2frkbGMZ0vRgU=.b2de23f5-55fd-4f22-bc47-c675a478bfd7@github.com>
Message-ID: <sSKwHwhtBTRG0YGaLDsBNpSuxR8dN48WXYJF9d6DWeo=.67eed837-7ef2-4fa8-a8d3-8b1217d700ff@github.com>

On Thu, 18 Jan 2024 18:49:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all.
>> 
>> please review this patch that makes `RestRequest` support multiple query parameters with the same key. This idiom is sometimes used in REST APIs (for example GitLab's REST API). The query parameters should always be kept in program order, since some REST APIs (e.g. GitLab) care about the order of the query parameters.
>> 
>> I also added a new `build` method on `RestRequest` to ease unit testing.
>> 
>> ### Testing
>> - [x] Added a bunch of unit tests
>
> Marked as reviewed by erikj (Lead).

Thanks @erikj79 and @zhaosongzs for reviewing!

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

PR Comment: https://git.openjdk.org/skara/pull/1601#issuecomment-1900089055

From ehelin at openjdk.org  Fri Jan 19 09:55:28 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 19 Jan 2024 09:55:28 GMT
Subject: RFR: 2150: Allow pull requests to have the title "Merge"
In-Reply-To: <pWsD-eOEpWaKQ9jk6VDjZUlK8zavVyIPF7OKzcOtZcQ=.f81322b7-9540-4d90-b5b2-de133670fbb2@github.com>
References: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
 <pWsD-eOEpWaKQ9jk6VDjZUlK8zavVyIPF7OKzcOtZcQ=.f81322b7-9540-4d90-b5b2-de133670fbb2@github.com>
Message-ID: <Tg27fZ-H5xQoI5O_8Zj94seM-PfKzauAjhXpyzszCl0=.bebfaacd-82a3-4094-abac-cb72d9148121@github.com>

On Thu, 18 Jan 2024 18:54:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all,
>> 
>> please review this patch that allow "merge style" pull requests to have just the title "Merge". If the title is just "Merge" then the bots will rewrite the title to `Merge <HEAD>` where `<HEAD>` is the HEAD of the pull request source branch. This is useful if the integrator knows that they want the HEAD of the pull request source branch as the second parent for the resulting merge commit (this removes the need to manually specify the HEAD hash in the PR title).
>> 
>> ### Testing
>> - [x] Added a new unit test
>> 
>> Thanks,
>> Erik
>
> Marked as reviewed by erikj (Lead).

Thanks @erikj79 and @zhaosongzs for reviewing!

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

PR Comment: https://git.openjdk.org/skara/pull/1602#issuecomment-1900088600

From ehelin at openjdk.org  Fri Jan 19 09:55:28 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 19 Jan 2024 09:55:28 GMT
Subject: Integrated: 2150: Allow pull requests to have the title "Merge"
In-Reply-To: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
References: <2V49HjGHxYR1UpFn8xiJMq-SJuXyAp0vOL3tBpruuB4=.2afb3e01-117d-4b91-aaef-6af6e6e67163@github.com>
Message-ID: <ozlLg5QCgz3poYYrO3Ut7aTAPJaGPFTb8l_nE8W80jE=.f995f39b-d63e-4870-bb08-b23320f70860@github.com>

On Thu, 18 Jan 2024 09:26:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that allow "merge style" pull requests to have just the title "Merge". If the title is just "Merge" then the bots will rewrite the title to `Merge <HEAD>` where `<HEAD>` is the HEAD of the pull request source branch. This is useful if the integrator knows that they want the HEAD of the pull request source branch as the second parent for the resulting merge commit (this removes the need to manually specify the HEAD hash in the PR title).
> 
> ### Testing
> - [x] Added a new unit test
> 
> Thanks,
> Erik

This pull request has now been integrated.

Changeset: 512311b1
Author:    Erik Duveblad <ehelin at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/512311b1f148c09bfb63155c9e9c226d55a38427
Stats:     70 lines in 2 files changed: 70 ins; 0 del; 0 mod

2150: Allow pull requests to have the title "Merge"

Reviewed-by: erikj, zsong

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

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

From ehelin at openjdk.org  Fri Jan 19 09:55:35 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 19 Jan 2024 09:55:35 GMT
Subject: Integrated: 2149: Allow multiple query parameters with the same key
In-Reply-To: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
References: <_38j_c2yDFH8CzLHEMDCPYJ3aUvwlG51pwavYaUd9Kw=.3439977a-dbf4-49b7-a4aa-4bf0cdc485c6@github.com>
Message-ID: <OYtIoRvI5G_v9sVmH-pb9VtAuHa2D1i71u4CjavMluU=.aaa4f7f1-b039-4653-8fa8-40e2bb38b77d@github.com>

On Thu, 18 Jan 2024 09:19:32 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all.
> 
> please review this patch that makes `RestRequest` support multiple query parameters with the same key. This idiom is sometimes used in REST APIs (for example GitLab's REST API). The query parameters should always be kept in program order, since some REST APIs (e.g. GitLab) care about the order of the query parameters.
> 
> I also added a new `build` method on `RestRequest` to ease unit testing.
> 
> ### Testing
> - [x] Added a bunch of unit tests

This pull request has now been integrated.

Changeset: 778b09b1
Author:    Erik Duveblad <ehelin at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/778b09b1adddf19de26caf40c82225d10b3b4c35
Stats:     88 lines in 6 files changed: 76 ins; 1 del; 11 mod

2149: Allow multiple query parameters with the same key

Reviewed-by: erikj, zsong

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

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

From ehelin at openjdk.org  Fri Jan 19 10:28:02 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Fri, 19 Jan 2024 10:28:02 GMT
Subject: RFR: 2152: Use full name for tags if possible
Message-ID: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>

Hi all,

please review this patch that makes the `/tag` commit command use the user's full name (if possible) for the author and committer name field for the Git tag it creates. This is the same convention we use for the author/committer name and e-mail metadata in the commits (it was just a mistake on my part that `contributor.username()` was used in the original code for the `/tag` commit command).

### Testing
- [x] Added a new unit tests that fails without this patch but passes with it

Thanks,
Erik

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

Commit messages:
 - 2152

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

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

From erikj at openjdk.org  Fri Jan 19 14:07:37 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 Jan 2024 14:07:37 GMT
Subject: RFR: 2152: Use full name for tags if possible
In-Reply-To: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
References: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
Message-ID: <SJ48x02G0K-Dj2q-X3IShxjAQeha5zlUIcgl2zqFM74=.cc8b41a0-db9e-49b5-9de9-895ff602dd19@github.com>

On Fri, 19 Jan 2024 10:24:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that makes the `/tag` commit command use the user's full name (if possible) for the author and committer name field for the Git tag it creates. This is the same convention we use for the author/committer name and e-mail metadata in the commits (it was just a mistake on my part that `contributor.username()` was used in the original code for the `/tag` commit command).
> 
> ### Testing
> - [x] Added a new unit tests that fails without this patch but passes with it
> 
> Thanks,
> Erik

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1603#pullrequestreview-1832758551

From zsong at openjdk.org  Fri Jan 19 18:34:19 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 19 Jan 2024 18:34:19 GMT
Subject: RFR: 2152: Use full name for tags if possible
In-Reply-To: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
References: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
Message-ID: <niD2txYmh1cQvrQ7CukN1nDuJFii0J7-0GfHu-2H4FU=.15302424-0941-4a4b-9ec6-976e55f9b9e7@github.com>

On Fri, 19 Jan 2024 10:24:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that makes the `/tag` commit command use the user's full name (if possible) for the author and committer name field for the Git tag it creates. This is the same convention we use for the author/committer name and e-mail metadata in the commits (it was just a mistake on my part that `contributor.username()` was used in the original code for the `/tag` commit command).
> 
> ### Testing
> - [x] Added a new unit tests that fails without this patch but passes with it
> 
> Thanks,
> Erik

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1603#pullrequestreview-1833441409

From ehelin at openjdk.org  Mon Jan 22 08:57:57 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Mon, 22 Jan 2024 08:57:57 GMT
Subject: RFR: 2152: Use full name for tags if possible
In-Reply-To: <SJ48x02G0K-Dj2q-X3IShxjAQeha5zlUIcgl2zqFM74=.cc8b41a0-db9e-49b5-9de9-895ff602dd19@github.com>
References: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
 <SJ48x02G0K-Dj2q-X3IShxjAQeha5zlUIcgl2zqFM74=.cc8b41a0-db9e-49b5-9de9-895ff602dd19@github.com>
Message-ID: <6YYYp_PEOLCPXlyfhXbGfUfQcGoa69oJVML31pQqIuY=.f71a5191-5fcd-4d8f-be2b-812ae847c76f@github.com>

On Fri, 19 Jan 2024 14:05:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all,
>> 
>> please review this patch that makes the `/tag` commit command use the user's full name (if possible) for the author and committer name field for the Git tag it creates. This is the same convention we use for the author/committer name and e-mail metadata in the commits (it was just a mistake on my part that `contributor.username()` was used in the original code for the `/tag` commit command).
>> 
>> ### Testing
>> - [x] Added a new unit tests that fails without this patch but passes with it
>> 
>> Thanks,
>> Erik
>
> Marked as reviewed by erikj (Lead).

Thanks @erikj79 and @zhaosongzs for reviewing!

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

PR Comment: https://git.openjdk.org/skara/pull/1603#issuecomment-1903524443

From ehelin at openjdk.org  Mon Jan 22 08:57:57 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Mon, 22 Jan 2024 08:57:57 GMT
Subject: Integrated: 2152: Use full name for tags if possible
In-Reply-To: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
References: <536P1_qXIBZpzxTArmFoZULhLL8uJbWugsacEkWcuKQ=.fb72402d-c99f-435e-abfc-7bda643380d0@github.com>
Message-ID: <HF_1IfdcjLjKdr8-XgJKyVtC7Y3eXYM-4SIVjKcVyBc=.6526df04-ced7-4aa7-8e58-2491612a8e4c@github.com>

On Fri, 19 Jan 2024 10:24:14 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that makes the `/tag` commit command use the user's full name (if possible) for the author and committer name field for the Git tag it creates. This is the same convention we use for the author/committer name and e-mail metadata in the commits (it was just a mistake on my part that `contributor.username()` was used in the original code for the `/tag` commit command).
> 
> ### Testing
> - [x] Added a new unit tests that fails without this patch but passes with it
> 
> Thanks,
> Erik

This pull request has now been integrated.

Changeset: 63018e97
Author:    Erik Duveblad <ehelin at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/63018e97b0e72d78a52fdcfad98ee7fb0c28a38d
Stats:     52 lines in 2 files changed: 51 ins; 0 del; 1 mod

2152: Use full name for tags if possible

Reviewed-by: erikj, zsong

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

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

From lgxbslgx at gmail.com  Fri Jan 26 07:59:39 2024
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Fri, 26 Jan 2024 15:59:39 +0800
Subject: Missing double quote in bot's comment
Message-ID: <CAPSsVqhMZ1X6oOMe4zmVveQMn5hLOUXpde7pA+9ieGGuONXW_g@mail.gmail.com>

Hi all,

When new developers post comments in Github, the bot will override the
comments and remind the new developers to sign the OpenJDK terms of use[1].
Among the bot's comments, the following statement misses a closed double
quote.

> Please Use "Add GitHub user hboehm for the summary.

It should be:

> Please Use "Add GitHub user hboehm" for the summary.

And I searched the skara code in order to solve this issue. But I can't
find any code about it. Did I miss anything? The related code seems not
open source?

[1] https://github.com/openjdk/jdk/pull/16644#discussion_r1406857727

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20240126/8629f4b3/attachment-0001.htm>

From zhao.song at oracle.com  Fri Jan 26 17:25:01 2024
From: zhao.song at oracle.com (Zhao Song)
Date: Fri, 26 Jan 2024 17:25:01 +0000
Subject: Missing double quote in bot's comment
In-Reply-To: <CAPSsVqhMZ1X6oOMe4zmVveQMn5hLOUXpde7pA+9ieGGuONXW_g@mail.gmail.com>
References: <CAPSsVqhMZ1X6oOMe4zmVveQMn5hLOUXpde7pA+9ieGGuONXW_g@mail.gmail.com>
Message-ID: <DS7PR10MB49735AEA1918EB67FEA5EC2C84792@DS7PR10MB4973.namprd10.prod.outlook.com>

Hi Guoxiong,

Thanks for reporting this bug. And you?re right, the code is not open source. We will fix it later.

Best,
Zhao

From: skara-dev <skara-dev-retn at openjdk.org> on behalf of Guoxiong Li <lgxbslgx at gmail.com>
Date: Friday, January 26, 2024 at 00:00
To: skara-dev at openjdk.org <skara-dev at openjdk.org>
Subject: Missing double quote in bot's comment
Hi all,

When new developers post comments in Github, the bot will override the comments and remind the new developers to sign the OpenJDK terms of use[1]. Among the bot's comments, the following statement misses a closed double quote.

> Please Use "Add GitHub user hboehm for the summary.

It should be:

> Please Use "Add GitHub user hboehm" for the summary.

And I searched the skara code in order to solve this issue. But I can't find any code about it. Did I miss anything? The related code seems not open source?

[1] https://github.com/openjdk/jdk/pull/16644#discussion_r1406857727

Best Regards,
-- Guoxiong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20240126/3ac48608/attachment.htm>

From zsong at openjdk.org  Fri Jan 26 19:25:35 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 19:25:35 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation
Message-ID: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>

As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.

To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.

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

Commit messages:
 - update
 - test

Changes: https://git.openjdk.org/skara/pull/1605/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1605&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2159
  Stats: 73 lines in 11 files changed: 40 ins; 4 del; 29 mod
  Patch: https://git.openjdk.org/skara/pull/1605.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1605/head:pull/1605

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

From erikj at openjdk.org  Fri Jan 26 21:13:38 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 26 Jan 2024 21:13:38 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation
In-Reply-To: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
Message-ID: <HB6bKTaX6Y1VoIl_GFUUrZ7r8fmV1-RlbHPK2DOTNSk=.53f7b0f2-5995-41df-b33c-569e12cb396f@github.com>

On Fri, 26 Jan 2024 19:01:00 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
> 
> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.

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

> 485:         if (repo.isEmpty()) {
> 486:             throw new IllegalStateException("Backport comment for PR " + pr.id() + " contains bad repo name: " + repoName);
> 487:         }

I think we need a fallback for all the existing PRs that currently don't have the repo stored in the comment.

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

> 528:                 var repoName = forge.search(hash);
> 529:                 if (repoName.isPresent()) {
> 530:                     var metadata = forge.repository(repoName.get()).flatMap(repository -> repository.commit(hash));

I find the naming of this variable confusing. Can we just call it `commit`?

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

PR Review Comment: https://git.openjdk.org/skara/pull/1605#discussion_r1468141425
PR Review Comment: https://git.openjdk.org/skara/pull/1605#discussion_r1468143332

From zsong at openjdk.org  Fri Jan 26 21:13:38 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 21:13:38 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation
In-Reply-To: <HB6bKTaX6Y1VoIl_GFUUrZ7r8fmV1-RlbHPK2DOTNSk=.53f7b0f2-5995-41df-b33c-569e12cb396f@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
 <HB6bKTaX6Y1VoIl_GFUUrZ7r8fmV1-RlbHPK2DOTNSk=.53f7b0f2-5995-41df-b33c-569e12cb396f@github.com>
Message-ID: <tg614BaJDScnQ6EXNG0CCHCmme-5gBWWLpDlSwA-3Mk=.20e32af8-af3f-456f-a1f8-78370d09da38@github.com>

On Fri, 26 Jan 2024 20:59:44 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
>> 
>> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 487:
> 
>> 485:         if (repo.isEmpty()) {
>> 486:             throw new IllegalStateException("Backport comment for PR " + pr.id() + " contains bad repo name: " + repoName);
>> 487:         }
> 
> I think we need a fallback for all the existing PRs that currently don't have the repo stored in the comment.

Ah, right. That's very important. Thanks for reminding me!

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 530:
> 
>> 528:                 var repoName = forge.search(hash);
>> 529:                 if (repoName.isPresent()) {
>> 530:                     var metadata = forge.repository(repoName.get()).flatMap(repository -> repository.commit(hash));
> 
> I find the naming of this variable confusing. Can we just call it `commit`?

Sure

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

PR Review Comment: https://git.openjdk.org/skara/pull/1605#discussion_r1468149709
PR Review Comment: https://git.openjdk.org/skara/pull/1605#discussion_r1468149782

From zsong at openjdk.org  Fri Jan 26 21:25:21 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 21:25:21 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation [v2]
In-Reply-To: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
Message-ID: <HaLVREtsOm2Q5oabBHT00B_uhcAy0TOEOwoUoEDrAfk=.b868058d-1807-4b34-b7cc-47fab32827da@github.com>

> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
> 
> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.

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

  review comment

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1605/files
  - new: https://git.openjdk.org/skara/pull/1605/files/6611eec2..a752c865

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

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

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

From zsong at openjdk.org  Fri Jan 26 22:05:54 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 22:05:54 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
Message-ID: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>

In [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), we introduced /approval command and at the same time, we let the bot post ApprovalNeededComment when the pull request is reviewed.

As Kevin Rushforth suggested, the bot shouldn't post ApprovalNeededComment if the user already applied for at least one of the issues.

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

Commit messages:
 - update
 - SKARA-2039

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

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

From kcr at openjdk.org  Fri Jan 26 22:16:20 2024
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 26 Jan 2024 22:16:20 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
In-Reply-To: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
Message-ID: <CIyATaadvD8eskGpoCt9Nh6x3PT1U3Y5xdCaVCEXdmg=.48d436c0-c9c5-4322-998b-d0b7bdd5da0a@github.com>

On Fri, 26 Jan 2024 20:06:33 GMT, Zhao Song <zsong at openjdk.org> wrote:

> the bot shouldn't post ApprovalNeededComment if the user already applied for at least one of the issues.

For multiple issues, should the `ApprovalNeededComment` be posted if one (or more) of the issues is missing the approval request? In that case you would only skip posting the message if _all_ of the issues have the approval request.

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

PR Comment: https://git.openjdk.org/skara/pull/1606#issuecomment-1912765116

From zsong at openjdk.org  Fri Jan 26 22:39:40 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 22:39:40 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
In-Reply-To: <CIyATaadvD8eskGpoCt9Nh6x3PT1U3Y5xdCaVCEXdmg=.48d436c0-c9c5-4322-998b-d0b7bdd5da0a@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
 <CIyATaadvD8eskGpoCt9Nh6x3PT1U3Y5xdCaVCEXdmg=.48d436c0-c9c5-4322-998b-d0b7bdd5da0a@github.com>
Message-ID: <Xkgo6G6TWoqp3UteF8YtrsM3Ap7gzVtRy58w2rXZVTM=.d1cb0b28-9754-4300-8eac-6296416edb2b@github.com>

On Fri, 26 Jan 2024 22:14:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> > the bot shouldn't post ApprovalNeededComment if the user already applied for at least one of the issues.
> 
> For multiple issues, should the `ApprovalNeededComment` be posted if one (or more) of the issues is missing the approval request? In that case you would only skip posting the message if _all_ of the issues have the approval request.

I was thinking post` ApprovalNeededComment` only when all the issues have the request, but later, I think that if there is one issue contains the request, then it means the user knows how to make the request. So no need to post the comment.

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

PR Comment: https://git.openjdk.org/skara/pull/1606#issuecomment-1912787260

From erikj at openjdk.org  Fri Jan 26 23:36:42 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 26 Jan 2024 23:36:42 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation [v2]
In-Reply-To: <HaLVREtsOm2Q5oabBHT00B_uhcAy0TOEOwoUoEDrAfk=.b868058d-1807-4b34-b7cc-47fab32827da@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
 <HaLVREtsOm2Q5oabBHT00B_uhcAy0TOEOwoUoEDrAfk=.b868058d-1807-4b34-b7cc-47fab32827da@github.com>
Message-ID: <kFS2KRpvkS-KJoF4X_tKiltjAvJuPAs5EvukjF9s4jo=.9e74bf83-41c5-4a58-94da-9badaf322978@github.com>

On Fri, 26 Jan 2024 21:25:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
>> 
>> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1605#pullrequestreview-1846726851

From erikj at openjdk.org  Fri Jan 26 23:38:51 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 26 Jan 2024 23:38:51 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
In-Reply-To: <Xkgo6G6TWoqp3UteF8YtrsM3Ap7gzVtRy58w2rXZVTM=.d1cb0b28-9754-4300-8eac-6296416edb2b@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
 <CIyATaadvD8eskGpoCt9Nh6x3PT1U3Y5xdCaVCEXdmg=.48d436c0-c9c5-4322-998b-d0b7bdd5da0a@github.com>
 <Xkgo6G6TWoqp3UteF8YtrsM3Ap7gzVtRy58w2rXZVTM=.d1cb0b28-9754-4300-8eac-6296416edb2b@github.com>
Message-ID: <YFZv44jpNFaQvBIluVwF7cs85NhfzUO57SfQ5Gry1Mo=.14510060-bdd2-4c1c-9a4b-841f2932e74e@github.com>

On Fri, 26 Jan 2024 22:37:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > > the bot shouldn't post ApprovalNeededComment if the user already applied for at least one of the issues.
> > 
> > 
> > For multiple issues, should the `ApprovalNeededComment` be posted if one (or more) of the issues is missing the approval request? In that case you would only skip posting the message if _all_ of the issues have the approval request.
> 
> I was thinking post` ApprovalNeededComment` only when all the issues have the request, but later, I think that if there is one issue contains the request, then it means the user knows how to make the request. So no need to post the comment.

I think I agree with Kevin. If any issue is missing the approval request, post the reminder. The user may have missed one unintentionally.

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

PR Comment: https://git.openjdk.org/skara/pull/1606#issuecomment-1912829453

From zsong at openjdk.org  Fri Jan 26 23:43:15 2024
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Jan 2024 23:43:15 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
In-Reply-To: <YFZv44jpNFaQvBIluVwF7cs85NhfzUO57SfQ5Gry1Mo=.14510060-bdd2-4c1c-9a4b-841f2932e74e@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
 <CIyATaadvD8eskGpoCt9Nh6x3PT1U3Y5xdCaVCEXdmg=.48d436c0-c9c5-4322-998b-d0b7bdd5da0a@github.com>
 <Xkgo6G6TWoqp3UteF8YtrsM3Ap7gzVtRy58w2rXZVTM=.d1cb0b28-9754-4300-8eac-6296416edb2b@github.com>
 <YFZv44jpNFaQvBIluVwF7cs85NhfzUO57SfQ5Gry1Mo=.14510060-bdd2-4c1c-9a4b-841f2932e74e@github.com>
Message-ID: <uULzKeScnWJVkaIF-eJK7yaJkDGZz6nYmH2TtaNl-KA=.42c88afe-94ce-49f1-a1c8-0869f658c339@github.com>

On Fri, 26 Jan 2024 23:36:47 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > > > the bot shouldn't post ApprovalNeededComment if the user already applied for at least one of the issues.
> > > 
> > > 
> > > For multiple issues, should the `ApprovalNeededComment` be posted if one (or more) of the issues is missing the approval request? In that case you would only skip posting the message if _all_ of the issues have the approval request.
> > 
> > 
> > I was thinking post` ApprovalNeededComment` only when all the issues have the request, but later, I think that if there is one issue contains the request, then it means the user knows how to make the request. So no need to post the comment.
> 
> I think I agree with Kevin. If any issue is missing the approval request, post the reminder. The user may have missed one unintentionally.

OK,  I will fix it.

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

PR Comment: https://git.openjdk.org/skara/pull/1606#issuecomment-1912832470

From ehelin at openjdk.org  Mon Jan 29 14:31:15 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Mon, 29 Jan 2024 14:31:15 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes"
Message-ID: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>

Hi all,

please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 

I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.

Also added a couple of unit tests.

Thanks,
Erik

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

Commit messages:
 - 2163

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

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

From ehelin at openjdk.org  Mon Jan 29 14:39:56 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Mon, 29 Jan 2024 14:39:56 GMT
Subject: RFR: 2164: Add git notes notifier
Message-ID: <3pd0BnGk8UTr4mAKxa6J4_7auq4uib1doqLyKLQmrg8=.44bbc5e0-dad4-4979-9c45-2982cec86d88@github.com>

Hi all,

please review this patch that adds a new notifier that records the link to a commit, the link to the review and ev. links to issues in a [git note](https://git-scm.com/docs/git-notes). This will make it possible to view this information using e.g. `git log` or `git show` _without_ having these URLs in the commit message itself. Git notes are also modifiable (they are just blobs referred to by a ref), so they can be updated if ever change the scheme or domain for these links.

I also added two unit tests for testing the new notifier.

Thanks,
Erik

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

Commit messages:
 - 2164

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

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

From erikj at openjdk.org  Mon Jan 29 15:07:57 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 29 Jan 2024 15:07:57 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes"
In-Reply-To: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
References: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
Message-ID: <TAhzLY8EvjH0Agg0W0Z1ru4LQ2FQ--tMjNMuVjFD0TQ=.9e23cc66-b9b1-49bf-8af6-cb4ba560c704@github.com>

On Mon, 29 Jan 2024 14:28:06 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 
> 
> I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.
> 
> Also added a couple of unit tests.
> 
> Thanks,
> Erik

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1607#pullrequestreview-1848904174

From erikj at openjdk.org  Mon Jan 29 15:07:44 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 29 Jan 2024 15:07:44 GMT
Subject: RFR: 2164: Add git notes notifier
In-Reply-To: <3pd0BnGk8UTr4mAKxa6J4_7auq4uib1doqLyKLQmrg8=.44bbc5e0-dad4-4979-9c45-2982cec86d88@github.com>
References: <3pd0BnGk8UTr4mAKxa6J4_7auq4uib1doqLyKLQmrg8=.44bbc5e0-dad4-4979-9c45-2982cec86d88@github.com>
Message-ID: <Q79hOt4Wr4nCNZ3ZD4_rFfwywZ-EV4GZCMV_JaAnWmw=.43c60160-8cfb-4202-8960-203c08c66c2f@github.com>

On Mon, 29 Jan 2024 14:35:37 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that adds a new notifier that records the link to a commit, the link to the review and ev. links to issues in a [git note](https://git-scm.com/docs/git-notes). This will make it possible to view this information using e.g. `git log` or `git show` _without_ having these URLs in the commit message itself. Git notes are also modifiable (they are just blobs referred to by a ref), so they can be updated if ever change the scheme or domain for these links.
> 
> I also added two unit tests for testing the new notifier.
> 
> Thanks,
> Erik

Could you add one of these to a test in NotifierBotFactoryTest? It's not complicated, but I like have example configurations in those tests as they also kind of serve as documentation.

forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java line 587:

> 585:         var url = URI.create(o.get("html_url").asString());
> 586:         var webUrl = gitHubHost.getWebURI(url.getPath());
> 587:         return Optional.of(new HostedCommit(metadata, diffs, url, webUrl));

Should we provide an implementation for GitLab as well?

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

PR Review: https://git.openjdk.org/skara/pull/1608#pullrequestreview-1848897451
PR Review Comment: https://git.openjdk.org/skara/pull/1608#discussion_r1469727437

From zsong at openjdk.org  Mon Jan 29 17:32:37 2024
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 29 Jan 2024 17:32:37 GMT
Subject: RFR: 2159: CheckRun repeats search for backport commit on each
 evaluation [v2]
In-Reply-To: <HaLVREtsOm2Q5oabBHT00B_uhcAy0TOEOwoUoEDrAfk=.b868058d-1807-4b34-b7cc-47fab32827da@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
 <HaLVREtsOm2Q5oabBHT00B_uhcAy0TOEOwoUoEDrAfk=.b868058d-1807-4b34-b7cc-47fab32827da@github.com>
Message-ID: <NoboUYu33Df18SG8FGrZSNna2xyC2wXVufNwA_cKqIc=.0d7eb3bd-82e9-42da-859d-b28c9761fc9d@github.com>

On Fri, 26 Jan 2024 21:25:21 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
>> 
>> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1605#issuecomment-1915228259

From zsong at openjdk.org  Mon Jan 29 17:32:37 2024
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 29 Jan 2024 17:32:37 GMT
Subject: Integrated: 2159: CheckRun repeats search for backport commit on each
 evaluation
In-Reply-To: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
References: <Ie1QlZ7-3zi7eDPOmGOkerohglFov1VQVv-us1Yufr4=.a632ad80-b764-4bfd-956b-26cc74714407@github.com>
Message-ID: <mM5THhi_3bAgIx0lk2VpwkWbsLV77oqYsM29MAE6E84=.c680a1c2-7e98-43c4-8711-3a5b565a5808@github.com>

On Fri, 26 Jan 2024 19:01:00 GMT, Zhao Song <zsong at openjdk.org> wrote:

> As Erik said in the issue description, when skara bot is searching for the original commit for a backport port, it's very inefficient for GitLab because GitLab doesn't provide the good rest api as GitHub for the bot to search for a commit by hash. So Skara have no choice but go through all the repositories and it's very slow right now.
> 
> To fix it, we could store the repository name together with the commit hash in the comment, therefore the bot will only need to run the search once.

This pull request has now been integrated.

Changeset: f300ab2b
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/f300ab2be083c3f87bf7119c879d7d6c728a8dbe
Stats:     74 lines in 11 files changed: 40 ins; 4 del; 30 mod

2159: CheckRun repeats search for backport commit on each evaluation

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Mon Jan 29 22:03:36 2024
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 29 Jan 2024 22:03:36 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues [v2]
In-Reply-To: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
Message-ID: <h10C8vAqOnx8mlYdFv5GDizEmSB_LlkVX83xUskubfo=.73b4d318-bf59-4551-8009-bc088c358e5b@github.com>

> In [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), we introduced /approval command and at the same time, we let the bot post ApprovalNeededComment when the pull request is reviewed.
> 
> As Kevin Rushforth suggested, the bot shouldn't post ApprovalNeededComment if the user already applied for all the issues.

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

 - rename
 - update

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1606/files
  - new: https://git.openjdk.org/skara/pull/1606/files/39046995..3291a323

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

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

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

From zsong at openjdk.org  Tue Jan 30 00:08:35 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 00:08:35 GMT
Subject: RFR: 2160: Update GHA versions
Message-ID: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>

This patch is trying to update the GHA versions, only `actions/checkout` and `actions/github-script` are used in GitHub Actions for skara. As `actions/checkout` is already the latest version, I only bumped the version of `actions/github-script`.

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

Commit messages:
 - SKARA-2160

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

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

From zsong at openjdk.org  Tue Jan 30 00:18:19 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 00:18:19 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes"
In-Reply-To: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
References: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
Message-ID: <ny8iq8PVA2SMAzRYNJ31HQGj4JQCSJsu9KSh5nBUD_c=.b5b69518-48df-4195-8191-0e22af5fa106@github.com>

On Mon, 29 Jan 2024 14:28:06 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 
> 
> I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.
> 
> Also added a couple of unit tests.
> 
> Thanks,
> Erik

Looks good!

vcs/src/main/java/org/openjdk/skara/vcs/Repository.java line 195:

> 193: 
> 194:     void addNote(Hash hash,
> 195:                  List<String> note,

Just out of curiosity, is there a specific reason for using `List<String>` in the interface and then concatenating the list? Why not use `String` directly?

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

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1607#pullrequestreview-1850009497
PR Review Comment: https://git.openjdk.org/skara/pull/1607#discussion_r1470402135

From ehelin at openjdk.org  Tue Jan 30 12:59:44 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Tue, 30 Jan 2024 12:59:44 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes"
In-Reply-To: <ny8iq8PVA2SMAzRYNJ31HQGj4JQCSJsu9KSh5nBUD_c=.b5b69518-48df-4195-8191-0e22af5fa106@github.com>
References: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
 <ny8iq8PVA2SMAzRYNJ31HQGj4JQCSJsu9KSh5nBUD_c=.b5b69518-48df-4195-8191-0e22af5fa106@github.com>
Message-ID: <iTFzYm8UaGLBr248BlLljVD3csVxikAyhurqSFUX_nA=.6dda277d-f9df-447f-9616-9eecca57b58e@github.com>

On Tue, 30 Jan 2024 00:15:47 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Hi all,
>> 
>> please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 
>> 
>> I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.
>> 
>> Also added a couple of unit tests.
>> 
>> Thanks,
>> Erik
>
> vcs/src/main/java/org/openjdk/skara/vcs/Repository.java line 195:
> 
>> 193: 
>> 194:     void addNote(Hash hash,
>> 195:                  List<String> note,
> 
> Just out of curiosity, is there a specific reason for using `List<String>` in the interface and then concatenating the list? Why not use `String` directly?

I just think it is more clear for a user of the API how lines are handled. If the method accepts `String hash` then it is (to me) harder to know if the API supports a single line or multiple lines (and the caller is responsible for inserting `\n` characters). With `List<String>` it is to me more clear, although I could have named the parameter `lines` to make it obvious ?

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

PR Review Comment: https://git.openjdk.org/skara/pull/1607#discussion_r1471164109

From ehelin at openjdk.org  Tue Jan 30 13:03:26 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Tue, 30 Jan 2024 13:03:26 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes" [v2]
In-Reply-To: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
References: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
Message-ID: <zjG8hvTPATGDe0TI3MCb5cilbLgjaVpGWsFjAEviaBg=.4ac2d72e-1526-42fe-ac08-87fec54fb88f@github.com>

> Hi all,
> 
> please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 
> 
> I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.
> 
> Also added a couple of unit tests.
> 
> Thanks,
> Erik

Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision:

  note -> lines

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1607/files
  - new: https://git.openjdk.org/skara/pull/1607/files/b6aabbda..214ff2b5

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

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

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

From ihse at openjdk.org  Tue Jan 30 13:31:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 30 Jan 2024 13:31:47 GMT
Subject: RFR: 2160: Update GHA versions
In-Reply-To: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
References: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
Message-ID: <ctkUUgsIteDeeULL9JJ7Fkm3DyGPfG_gceFiaXfpc8o=.d7b8ef7b-a688-4016-b38a-76490a8ba25e@github.com>

On Mon, 29 Jan 2024 22:30:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to update the GHA versions, only `actions/checkout` and `actions/github-script` are used in GitHub Actions for skara. As `actions/checkout` is already the latest version, I only bumped the version of `actions/github-script`.

LGTM

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1609#pullrequestreview-1851272647

From ehelin at openjdk.org  Tue Jan 30 13:50:19 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Tue, 30 Jan 2024 13:50:19 GMT
Subject: RFR: 2167: Unify search methods in IssueProject
Message-ID: <Mv-i06QIk_f10B7r_d6dWVHcpvdeBmVI0aQT6DLr9ko=.5e74fc33-8621-4f23-892a-2b88f3a5d493@github.com>

Hi all,

this patch unifies the various ways of searching that exist within `JiraProejct`. I also chose to expose the `search` method in the `IssueProject` since I will make use of it in later patches. This is the first patch of _many_ that will extract the JBS specific parts from `JiraProject` so that `JiraProject` will be about JIRA and JBS specific functionality will be moved elsewhere. This refactoring is needed to allow other parts of the Skara to use JBS functionality with only an `IssueProject` instance (without turning `JiraProject` into effectively `JbsProject`).

Thanks,
Erik

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

Commit messages:
 - 2167

Changes: https://git.openjdk.org/skara/pull/1610/files
 Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1610&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2167
  Stats: 59 lines in 3 files changed: 20 ins; 24 del; 15 mod
  Patch: https://git.openjdk.org/skara/pull/1610.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1610/head:pull/1610

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

From erikj at openjdk.org  Tue Jan 30 13:56:51 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 30 Jan 2024 13:56:51 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues [v2]
In-Reply-To: <h10C8vAqOnx8mlYdFv5GDizEmSB_LlkVX83xUskubfo=.73b4d318-bf59-4551-8009-bc088c358e5b@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
 <h10C8vAqOnx8mlYdFv5GDizEmSB_LlkVX83xUskubfo=.73b4d318-bf59-4551-8009-bc088c358e5b@github.com>
Message-ID: <4CfdMHpCJhv57sbUBUAQ6XciLfDMUGT6cBCcgVY0guI=.01c1cd8c-5004-4887-a248-67b22f07ef87@github.com>

On Mon, 29 Jan 2024 22:03:36 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), we introduced /approval command and at the same time, we let the bot post ApprovalNeededComment when the pull request is reviewed.
>> 
>> As Kevin Rushforth suggested, the bot shouldn't post ApprovalNeededComment if the user already applied for all the issues.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename
>  - update

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1606#pullrequestreview-1851341203

From erikj at openjdk.org  Tue Jan 30 13:59:54 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 30 Jan 2024 13:59:54 GMT
Subject: RFR: 2160: Update GHA versions
In-Reply-To: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
References: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
Message-ID: <WA14Q-vA90qiXo9_xeLorxB5EO4-wVL3ryM0raaYq-A=.d356bd02-166b-440a-9a28-b304df02b1bc@github.com>

On Mon, 29 Jan 2024 22:30:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to update the GHA versions, only `actions/checkout` and `actions/github-script` are used in GitHub Actions for skara. As `actions/checkout` is already the latest version, I only bumped the version of `actions/github-script`.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1609#pullrequestreview-1851348722

From erikj at openjdk.org  Tue Jan 30 14:21:20 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 30 Jan 2024 14:21:20 GMT
Subject: RFR: 2167: Unify search methods in IssueProject
In-Reply-To: <Mv-i06QIk_f10B7r_d6dWVHcpvdeBmVI0aQT6DLr9ko=.5e74fc33-8621-4f23-892a-2b88f3a5d493@github.com>
References: <Mv-i06QIk_f10B7r_d6dWVHcpvdeBmVI0aQT6DLr9ko=.5e74fc33-8621-4f23-892a-2b88f3a5d493@github.com>
Message-ID: <x7HXJdjEuGWaOO-ciPi30oNq0lxOeN2VEsOgE1fWOzQ=.8525723c-152b-4d1b-9a06-779a3e9815c4@github.com>

On Tue, 30 Jan 2024 13:47:34 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

> Hi all,
> 
> this patch unifies the various ways of searching that exist within `JiraProejct`. I also chose to expose the `search` method in the `IssueProject` since I will make use of it in later patches. This is the first patch of _many_ that will extract the JBS specific parts from `JiraProject` so that `JiraProject` will be about JIRA and JBS specific functionality will be moved elsewhere. This refactoring is needed to allow other parts of the Skara to use JBS functionality with only an `IssueProject` instance (without turning `JiraProject` into effectively `JbsProject`).
> 
> Thanks,
> Erik

issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 508:

> 506: 
> 507:             if (count < issues.get("total").asInt()) {
> 508:                 startAt += issues.get("issues").asArray().size();

Aren't `count` and `startAt` basically equivalent at this point? Seems a bit weird to have two values for basically the same thing but calculated differently.

issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 513:

> 511:                              .param("startAt", String.valueOf(startAt));
> 512:                 if (limit > 0) {
> 513:                     req = req.param("maxResults", Integer.toString(limit));

Is the limit supposed to be the total limit or max size per page (would be great with javadoc specifying this btw)? The `maxResults` parameter is results returned per page. I would think a global limit to be more useful.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1610#discussion_r1471302051
PR Review Comment: https://git.openjdk.org/skara/pull/1610#discussion_r1471307898

From ehelin at openjdk.org  Tue Jan 30 16:17:12 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Tue, 30 Jan 2024 16:17:12 GMT
Subject: RFR: 2167: Unify search methods in IssueProject
In-Reply-To: <x7HXJdjEuGWaOO-ciPi30oNq0lxOeN2VEsOgE1fWOzQ=.8525723c-152b-4d1b-9a06-779a3e9815c4@github.com>
References: <Mv-i06QIk_f10B7r_d6dWVHcpvdeBmVI0aQT6DLr9ko=.5e74fc33-8621-4f23-892a-2b88f3a5d493@github.com>
 <x7HXJdjEuGWaOO-ciPi30oNq0lxOeN2VEsOgE1fWOzQ=.8525723c-152b-4d1b-9a06-779a3e9815c4@github.com>
Message-ID: <38rRTK8vxzhQCIyzj5GLAq_Fic3eA0pTIivL0Hl-xPM=.915e9213-d90e-4cd2-8462-e9d416d0e52b@github.com>

On Tue, 30 Jan 2024 14:16:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Hi all,
>> 
>> this patch unifies the various ways of searching that exist within `JiraProejct`. I also chose to expose the `search` method in the `IssueProject` since I will make use of it in later patches. This is the first patch of _many_ that will extract the JBS specific parts from `JiraProject` so that `JiraProject` will be about JIRA and JBS specific functionality will be moved elsewhere. This refactoring is needed to allow other parts of the Skara to use JBS functionality with only an `IssueProject` instance (without turning `JiraProject` into effectively `JbsProject`).
>> 
>> Thanks,
>> Erik
>
> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 508:
> 
>> 506: 
>> 507:             if (count < issues.get("total").asInt()) {
>> 508:                 startAt += issues.get("issues").asArray().size();
> 
> Aren't `count` and `startAt` basically equivalent at this point? Seems a bit weird to have two values for basically the same thing but calculated differently.

Yes, I just tried to change the existing code as little as possible to try to keep the patch about refactoring. Since I will be touch this a bit more based on your other comment then I can clean this up as well.

> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraProject.java line 513:
> 
>> 511:                              .param("startAt", String.valueOf(startAt));
>> 512:                 if (limit > 0) {
>> 513:                     req = req.param("maxResults", Integer.toString(limit));
> 
> Is the limit supposed to be the total limit or max size per page (would be great with javadoc specifying this btw)? The `maxResults` parameter is results returned per page. I would think a global limit to be more useful.

Yeah, it was meant to be a global limit (we only have one caller currently passing a limit other than -1, and that caller passes 1, so it would have worked, but I agree that the current code is wrong). Will update!

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

PR Review Comment: https://git.openjdk.org/skara/pull/1610#discussion_r1471408460
PR Review Comment: https://git.openjdk.org/skara/pull/1610#discussion_r1471407563

From ehelin at openjdk.org  Tue Jan 30 16:17:12 2024
From: ehelin at openjdk.org (Erik Duveblad)
Date: Tue, 30 Jan 2024 16:17:12 GMT
Subject: RFR: 2164: Add git notes notifier
In-Reply-To: <Q79hOt4Wr4nCNZ3ZD4_rFfwywZ-EV4GZCMV_JaAnWmw=.43c60160-8cfb-4202-8960-203c08c66c2f@github.com>
References: <3pd0BnGk8UTr4mAKxa6J4_7auq4uib1doqLyKLQmrg8=.44bbc5e0-dad4-4979-9c45-2982cec86d88@github.com>
 <Q79hOt4Wr4nCNZ3ZD4_rFfwywZ-EV4GZCMV_JaAnWmw=.43c60160-8cfb-4202-8960-203c08c66c2f@github.com>
Message-ID: <Wr1Jrqf0Y02Qv0L6dTD_ZtGiZBDIIH-xByFikhZPDt8=.b951bf30-ddc4-4e6e-9c24-3b3c28aca723@github.com>

On Mon, 29 Jan 2024 15:05:36 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Could you add one of these to a test in NotifierBotFactoryTest? It's not complicated, but I like have example configurations in those tests as they also kind of serve as documentation.

Sure, will do!

> forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java line 587:
> 
>> 585:         var url = URI.create(o.get("html_url").asString());
>> 586:         var webUrl = gitHubHost.getWebURI(url.getPath());
>> 587:         return Optional.of(new HostedCommit(metadata, diffs, url, webUrl));
> 
> Should we provide an implementation for GitLab as well?

No I don't think so as we currently don't have a need to rewrite any GitLab URLs. We rewrite `github.com` to `git.openjdk.org` so that links stored in OpenJDK infrastructure (like JBS, mailing lists, etc.) aren't tried to GitHub (if we ever change forge then we can implement a re-direct service). For GitLab we currently don't have that need.

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

PR Comment: https://git.openjdk.org/skara/pull/1608#issuecomment-1917090262
PR Review Comment: https://git.openjdk.org/skara/pull/1608#discussion_r1471392150

From zsong at openjdk.org  Tue Jan 30 17:26:54 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 17:26:54 GMT
Subject: RFR: 2163: Add API to Repository for working "git notes" [v2]
In-Reply-To: <zjG8hvTPATGDe0TI3MCb5cilbLgjaVpGWsFjAEviaBg=.4ac2d72e-1526-42fe-ac08-87fec54fb88f@github.com>
References: <91jqh9fj5GU7K6-hwqlq5alhz5MDdznFLTXuv98Ap6Y=.6f6e0686-2876-48b1-852f-59d915c87c47@github.com>
 <zjG8hvTPATGDe0TI3MCb5cilbLgjaVpGWsFjAEviaBg=.4ac2d72e-1526-42fe-ac08-87fec54fb88f@github.com>
Message-ID: <7qBpGyt5oaRZri0mXTEt6N0oMbnBDwbVRjHNs8duzzo=.44140011-6630-4772-bdaf-4bd94ed419b0@github.com>

On Tue, 30 Jan 2024 13:03:26 GMT, Erik Duveblad <ehelin at openjdk.org> wrote:

>> Hi all,
>> 
>> please review this patch that adds the methods `addNote`. `notes` and `pushNotes` to `Repository.java` to allow Skara code to work with [git notes](https://git-scm.com/docs/git-notes). This will be used in another patch to implement a "git note"-notifier (see https://bugs.openjdk.org/browse/SKARA-2164). 
>> 
>> I opted for a fairly minimal API here even though the `git notes` command exposes many more features. I also decided to add the `pushNotes` method although callers could use the `push(String refspec, URI uri)` variant because I don't like the notes refspec to "leak" out into other parts of the code.
>> 
>> Also added a couple of unit tests.
>> 
>> Thanks,
>> Erik
>
> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   note -> lines

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1607#pullrequestreview-1851930172

From zsong at openjdk.org  Tue Jan 30 17:59:15 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 17:59:15 GMT
Subject: RFR: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues [v2]
In-Reply-To: <h10C8vAqOnx8mlYdFv5GDizEmSB_LlkVX83xUskubfo=.73b4d318-bf59-4551-8009-bc088c358e5b@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
 <h10C8vAqOnx8mlYdFv5GDizEmSB_LlkVX83xUskubfo=.73b4d318-bf59-4551-8009-bc088c358e5b@github.com>
Message-ID: <ayzPzHYGyUVcRxXYgzDNFkWXqUOlwzpMj7pacg1HBsg=.45152af4-9fe0-425a-8448-cf0d85b3772c@github.com>

On Mon, 29 Jan 2024 22:03:36 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), we introduced /approval command and at the same time, we let the bot post ApprovalNeededComment when the pull request is reviewed.
>> 
>> As Kevin Rushforth suggested, the bot shouldn't post ApprovalNeededComment if the user already applied for all the issues.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - rename
>  - update

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1606#issuecomment-1917590725

From zsong at openjdk.org  Tue Jan 30 17:59:50 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 17:59:50 GMT
Subject: RFR: 2160: Update GHA versions
In-Reply-To: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
References: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
Message-ID: <nXe3qgAutmbZz2eBayyNBQPDzAwXR7hBdgACvu8Mf4Y=.6926a84c-ad00-4ce6-bc90-65ef33017a35@github.com>

On Mon, 29 Jan 2024 22:30:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to update the GHA versions, only `actions/checkout` and `actions/github-script` are used in GitHub Actions for skara. As `actions/checkout` is already the latest version, I only bumped the version of `actions/github-script`.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1609#issuecomment-1917590247

From zsong at openjdk.org  Tue Jan 30 17:59:50 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 17:59:50 GMT
Subject: Integrated: 2160: Update GHA versions
In-Reply-To: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
References: <ieeEDHPIQHvDBs9q18ymmnbRvKFiQHSZoEsOro_K3HA=.95e6c7c0-2e17-4b7c-b1a6-ac344337d972@github.com>
Message-ID: <uIhVM-jxsWGgsqPx7OP6SXko_yNpRiJ3YtK8VcUzpqg=.ef57d0a4-49c3-4f67-bbfe-0987a813f330@github.com>

On Mon, 29 Jan 2024 22:30:54 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to update the GHA versions, only `actions/checkout` and `actions/github-script` are used in GitHub Actions for skara. As `actions/checkout` is already the latest version, I only bumped the version of `actions/github-script`.

This pull request has now been integrated.

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

2160: Update GHA versions

Reviewed-by: ihse, erikj

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

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

From zsong at openjdk.org  Tue Jan 30 18:49:28 2024
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 30 Jan 2024 18:49:28 GMT
Subject: Integrated: 2039: Only post ApprovalNeededComment when the user hasn't
 applied for maintainer approval for all the issues
In-Reply-To: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
References: <uuh8F0Ze5YE1Dcdb4f28cw4PeKZuFM7HUOfPLiyUE5M=.b8fb143e-7ae2-45d4-b9aa-304667e7229f@github.com>
Message-ID: <ktUqRxswG1KfOIP3nT_nGJixB7xz-k9PSUSQwA0oNyc=.39b1117e-4fbe-41ca-8414-e12a178a540a@github.com>

On Fri, 26 Jan 2024 20:06:33 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1949](https://bugs.openjdk.org/browse/SKARA-1949), we introduced /approval command and at the same time, we let the bot post ApprovalNeededComment when the pull request is reviewed.
> 
> As Kevin Rushforth suggested, the bot shouldn't post ApprovalNeededComment if the user already applied for all the issues.

This pull request has now been integrated.

Changeset: 4e9dad2b
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/4e9dad2b03fa963f4a302c1e82b77e9d347330f2
Stats:     45 lines in 3 files changed: 28 ins; 13 del; 4 mod

2039: Only post ApprovalNeededComment when the user hasn't applied for maintainer approval for all the issues

Reviewed-by: erikj

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

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