From zsong at openjdk.org  Mon Mar  3 17:54:49 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 3 Mar 2025 17:54:49 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to empty
 response from api
Message-ID: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>

A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.

When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.

I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
`{"expand":"transitions","transitions":[]}.`

Due to this empty response, the Skara bot did not attempt to transition the bug to any state.

In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.

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

Commit messages:
 - SKARA-2451

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

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

From zsong at openjdk.org  Mon Mar  3 17:59:11 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 3 Mar 2025 17:59:11 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api
In-Reply-To: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
Message-ID: <fOkErG_cWdAJirYreHen1Oo1Db2HUFdAjZytEUPjwXY=.6d817611-1ddd-43c3-928d-3ba2809ff4cf@github.com>

On Mon, 3 Mar 2025 17:50:10 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
> 
> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
> 
> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
> `{"expand":"transitions","transitions":[]}.`
> 
> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
> 
> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.

issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 268:

> 266:                 } else {
> 267:                     // The issue is most likely closed - skip transitioning
> 268:                     log.warning("Can't transition the issue to Resolved or Open");

@erikj79 You suggested that 

> The else clause should at the very least log something so we know that is what happened. we should also verify that the state is either closed or resolved and throw RuntimeException if not. 

I thought about it, then I realized that the Skara bot should have already verified the state before calling Issue.setState(Issue.State.RESOLVED) like [this](https://github.com/openjdk/skara/blob/b8a99e211aae1cec3ae5b6477e9c0c91c0761284/bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java#L211).

Also, it's will be a little hard to verify the Issue state since we need to change the interface of Issue.setState.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1706#discussion_r1977941676

From zsong at openjdk.org  Mon Mar  3 18:56:35 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 3 Mar 2025 18:56:35 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api [v2]
In-Reply-To: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
Message-ID: <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>

> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
> 
> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
> 
> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
> `{"expand":"transitions","transitions":[]}.`
> 
> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
> 
> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.

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

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

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1706/files
  - new: https://git.openjdk.org/skara/pull/1706/files/51fbf716..4a6b183a

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

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

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

From erikj at openjdk.org  Mon Mar  3 18:56:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Mar 2025 18:56:36 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api [v2]
In-Reply-To: <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
 <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
Message-ID: <fLQmq5zZQT-TBwcjb1rOhjyHi4oSA3Ckr36LbyCQPOA=.d888051c-5517-4cb5-9258-78ab6f3faba9@github.com>

On Mon, 3 Mar 2025 18:54:10 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
>> 
>> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
>> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
>> 
>> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
>> `{"expand":"transitions","transitions":[]}.`
>> 
>> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
>> 
>> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 254:

> 252: 
> 253:         if (availableTransitions.isEmpty()) {
> 254:             throw new RuntimeException("Available transition states are empty");

Suggestion:

            throw new RuntimeException("Available transition states is empty");

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

PR Review Comment: https://git.openjdk.org/skara/pull/1706#discussion_r1978015262

From erikj at openjdk.org  Mon Mar  3 18:56:36 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Mar 2025 18:56:36 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api [v2]
In-Reply-To: <fOkErG_cWdAJirYreHen1Oo1Db2HUFdAjZytEUPjwXY=.6d817611-1ddd-43c3-928d-3ba2809ff4cf@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
 <fOkErG_cWdAJirYreHen1Oo1Db2HUFdAjZytEUPjwXY=.6d817611-1ddd-43c3-928d-3ba2809ff4cf@github.com>
Message-ID: <pZ_lkgmwWJmiIfQuaVaZ0nz2VQALjP4cxo7e-iXvDuc=.5456cc9d-c0f4-4513-a37d-dca36b12a205@github.com>

On Mon, 3 Mar 2025 17:56:58 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java
>>   
>>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 268:
> 
>> 266:                 } else {
>> 267:                     // The issue is most likely closed - skip transitioning
>> 268:                     log.warning("Can't transition the issue to Resolved or Open");
> 
> @erikj79 You suggested that 
> 
>> The else clause should at the very least log something so we know that is what happened. we should also verify that the state is either closed or resolved and throw RuntimeException if not. 
> 
> I thought about it, then I realized that the Skara bot should have already verified the state before calling Issue.setState(Issue.State.RESOLVED) like [this](https://github.com/openjdk/skara/blob/b8a99e211aae1cec3ae5b6477e9c0c91c0761284/bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/IssueNotifier.java#L211).
> 
> Also, it's will be a little hard to verify the Issue state since we need to change the interface of Issue.setState.

I think logging is good enough for now.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1706#discussion_r1978020087

From erikj at openjdk.org  Mon Mar  3 20:53:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Mar 2025 20:53:11 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api [v2]
In-Reply-To: <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
 <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
Message-ID: <kSsiMgpCE7bjWCgNbU2Q75Dxo3fnaEGWlb7fD537a0A=.1a4a860f-c291-4b91-8cce-89e050e774ba@github.com>

On Mon, 3 Mar 2025 18:56:35 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
>> 
>> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
>> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
>> 
>> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
>> `{"expand":"transitions","transitions":[]}.`
>> 
>> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
>> 
>> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1706#pullrequestreview-2655259401

From zsong at openjdk.org  Mon Mar  3 20:56:07 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 3 Mar 2025 20:56:07 GMT
Subject: RFR: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api [v2]
In-Reply-To: <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
 <Z-KCR_wSPBQ0Lp259RY7-e9WubSynK1Kr_aPHTFftaU=.67a79b05-4bd7-42cb-a6c6-7bb20ade13c2@github.com>
Message-ID: <Q0GvASSbi73hCOcFMWc-j2mceLui-BI0HLhXOsb34nA=.a86282f3-e14f-4830-bfbd-0ea34c80f5cb@github.com>

On Mon, 3 Mar 2025 18:56:35 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
>> 
>> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
>> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
>> 
>> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
>> `{"expand":"transitions","transitions":[]}.`
>> 
>> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
>> 
>> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1706#issuecomment-2695511501

From zsong at openjdk.org  Mon Mar  3 20:56:07 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 3 Mar 2025 20:56:07 GMT
Subject: Integrated: 2451: Skara bot fails to transition bug to Resolved due to
 empty response from api
In-Reply-To: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
References: <1rJY92MUpfSO9gdgfi8orTfdf3MtIfhIp740jj3KKfw=.8ce4228d-69c4-4f9f-bc38-eb4557e38fe7@github.com>
Message-ID: <EFuGq89oIw61o9os_ruQn_XuiDiQzSUP3H1jyyk8ux8=.e827c67c-d13e-428e-898b-ac3b7797c2c3@github.com>

On Mon, 3 Mar 2025 17:50:10 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that one backport issue was not automatically resolved by the Skara bot. From the logs, Erik found that the bot didn't actually send the request to transition the bug to resolved and he noticed that around that time, the bot was renewing the access token for jbs.
> 
> When updating the state of an issue, the Skara bot first attempts to fetch the available transitions for that issue by calling this API:
> https://bugs.openjdk.org/rest/api/2/issue/issue_id/transitions.
> 
> I called the API without authentication, I was expecting a 401 Unauthorized response. However, I received an empty response:
> `{"expand":"transitions","transitions":[]}.`
> 
> Due to this empty response, the Skara bot did not attempt to transition the bug to any state.
> 
> In my opinion, availableTransitions would be empty only when requesting the API without authentication,  so skara bot would throw an exception in this case.

This pull request has now been integrated.

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

2451: Skara bot fails to transition bug to Resolved due to empty response from api

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Mon Mar  3 23:30:24 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 3 Mar 2025 23:30:24 GMT
Subject: RFR: 2452: Client CLI build fails on Windows
Message-ID: <Rub5pYZ3N3ZbqB4XI5Yxq4wrVpEBpS6L3XDXBlhtExk=.ad25c344-11a3-4697-bade-185dcee64045@github.com>

Building the default target "local" fails on Windows with the error message below. I think this started happening when we upgraded the Gradle version last. This is the target that the automatic CLI build/installation runs.


* What went wrong:
Execution failed for task ':local'.
> Cannot access a file in the destination directory. Copying to a directory which contains unreadable content is not supported. Declare the task as untracked by using Task.doNotTrackState(). For more information, please refer to https://docs.gradle.org/8.5/userguide/incremental_build.html#disable-state-tracking in the Gradle documentation.
 > Failed to create MD5 hash for file content.


I'm working around/fixing it by moving the output dir of the `local` task to its own subdir in the project build dir. I'm also adding the target `local` explicitly to the GHA tasks so that this kind of problem gets caught there. I intentionally did this in a separate commit to demonstrate that it would fail for this branch/PR.

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

Commit messages:
 - Empty
 - Unpack cli into subdir of build
 - Add 'local' build target to GHA

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

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

From ihse at openjdk.org  Tue Mar  4 10:26:27 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 4 Mar 2025 10:26:27 GMT
Subject: RFR: 2452: Client CLI build fails on Windows
In-Reply-To: <Rub5pYZ3N3ZbqB4XI5Yxq4wrVpEBpS6L3XDXBlhtExk=.ad25c344-11a3-4697-bade-185dcee64045@github.com>
References: <Rub5pYZ3N3ZbqB4XI5Yxq4wrVpEBpS6L3XDXBlhtExk=.ad25c344-11a3-4697-bade-185dcee64045@github.com>
Message-ID: <yASG_tnzJVlKQpzKwBUQlRHTMd-j9CarXlkzhpvFFA4=.6610bbba-2c7f-4361-90c1-15aba84ee957@github.com>

On Mon, 3 Mar 2025 23:27:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Building the default target "local" fails on Windows with the error message below. I think this started happening when we upgraded the Gradle version last. This is the target that the automatic CLI build/installation runs.
> 
> 
> * What went wrong:
> Execution failed for task ':local'.
>> Cannot access a file in the destination directory. Copying to a directory which contains unreadable content is not supported. Declare the task as untracked by using Task.doNotTrackState(). For more information, please refer to https://docs.gradle.org/8.5/userguide/incremental_build.html#disable-state-tracking in the Gradle documentation.
>  > Failed to create MD5 hash for file content.
> 
> 
> I'm working around/fixing it by moving the output dir of the `local` task to its own subdir in the project build dir. I'm also adding the target `local` explicitly to the GHA tasks so that this kind of problem gets caught there. I intentionally did this in a separate commit to demonstrate that it would fail for this branch/PR.

LGTM

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1707#pullrequestreview-2656831758

From erikj at openjdk.org  Tue Mar  4 13:59:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 4 Mar 2025 13:59:46 GMT
Subject: Integrated: 2452: Client CLI build fails on Windows
In-Reply-To: <Rub5pYZ3N3ZbqB4XI5Yxq4wrVpEBpS6L3XDXBlhtExk=.ad25c344-11a3-4697-bade-185dcee64045@github.com>
References: <Rub5pYZ3N3ZbqB4XI5Yxq4wrVpEBpS6L3XDXBlhtExk=.ad25c344-11a3-4697-bade-185dcee64045@github.com>
Message-ID: <ws5VjfS9yx_v7IzGIWYwJYa4sw9ESeKQk-wnocOBbtc=.d7d84362-2424-48ef-948f-c508dfb03065@github.com>

On Mon, 3 Mar 2025 23:27:00 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Building the default target "local" fails on Windows with the error message below. I think this started happening when we upgraded the Gradle version last. This is the target that the automatic CLI build/installation runs.
> 
> 
> * What went wrong:
> Execution failed for task ':local'.
>> Cannot access a file in the destination directory. Copying to a directory which contains unreadable content is not supported. Declare the task as untracked by using Task.doNotTrackState(). For more information, please refer to https://docs.gradle.org/8.5/userguide/incremental_build.html#disable-state-tracking in the Gradle documentation.
>  > Failed to create MD5 hash for file content.
> 
> 
> I'm working around/fixing it by moving the output dir of the `local` task to its own subdir in the project build dir. I'm also adding the target `local` explicitly to the GHA tasks so that this kind of problem gets caught there. I intentionally did this in a separate commit to demonstrate that it would fail for this branch/PR.

This pull request has now been integrated.

Changeset: 64188c3d
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/64188c3d97a8ca1f2b9b47ac9af2a3adc0cd8780
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

2452: Client CLI build fails on Windows

Reviewed-by: ihse

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

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

From zsong at openjdk.org  Fri Mar  7 22:36:50 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 7 Mar 2025 22:36:50 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
Message-ID: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>

A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.

In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

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

Commit messages:
 - update
 - update copyright
 - SKARA-2454

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

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

From zsong at openjdk.org  Fri Mar  7 22:39:22 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 7 Mar 2025 22:39:22 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v2]
In-Reply-To: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
Message-ID: <d2I6nvs8jL0dfNemMYVGL_bjbIy6m2uoqGE6B498a-Q=.3cfc76c4-a9aa-4d84-8e52-881669e238fa@github.com>

> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
> 
> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

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

  rename method

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1708/files
  - new: https://git.openjdk.org/skara/pull/1708/files/73fcf900..502f5534

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

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

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

From erikj at openjdk.org  Mon Mar 10 14:19:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 10 Mar 2025 14:19:13 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v2]
In-Reply-To: <d2I6nvs8jL0dfNemMYVGL_bjbIy6m2uoqGE6B498a-Q=.3cfc76c4-a9aa-4d84-8e52-881669e238fa@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <d2I6nvs8jL0dfNemMYVGL_bjbIy6m2uoqGE6B498a-Q=.3cfc76c4-a9aa-4d84-8e52-881669e238fa@github.com>
Message-ID: <-c0NqbmXe-Jl4LtFmH3XyRjADDhABXXbc95czrAW8JY=.d547cc89-cb19-4a70-b650-6e42da873acf@github.com>

On Fri, 7 Mar 2025 22:39:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename method

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

> 1278:         var message = "??  @" + pr.author().username() +
> 1279:                 " This backport pull request is too large for skara bot to get the entire diff from the remote repository. " +
> 1280:                 "Therefore, skara bot can't evaluate whether this backport is clean or not." +

The current language style used by the bot does not have it refer to itself as "skara bot".
Suggestion:

                " This backport pull request is too large to be automatically evaluated as clean." +

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

> 46: 
> 47:     private List<Label> labels = null;
> 48:     private Optional<Boolean> diffLimited = Optional.empty();

We should not use `Optional` in fields. If we need a tri-state for this boolean, then it's better to use `Boolean` and check for null.

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

> 835:         }
> 836:         return diffLimited.get();
> 837:     }

I think it would be better to add a boolean field `complete` to `Diff`, instead of having this be a property of a PullRequest. Then we avoid this awkward requirement for ordering calls on PullRequest.

test/src/main/java/org/openjdk/skara/test/TestPullRequest.java line 357:

> 355:     public boolean diffLimited() {
> 356:         return false;
> 357:     }

You could write an automatic test for PullRequestBot if you give the test the ability to control if the diff returned from TestPullRequest is limited or not.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987378357
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987350620
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987362236
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987368500

From zsong at openjdk.org  Mon Mar 10 16:35:42 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 10 Mar 2025 16:35:42 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v2]
In-Reply-To: <-c0NqbmXe-Jl4LtFmH3XyRjADDhABXXbc95czrAW8JY=.d547cc89-cb19-4a70-b650-6e42da873acf@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <d2I6nvs8jL0dfNemMYVGL_bjbIy6m2uoqGE6B498a-Q=.3cfc76c4-a9aa-4d84-8e52-881669e238fa@github.com>
 <-c0NqbmXe-Jl4LtFmH3XyRjADDhABXXbc95czrAW8JY=.d547cc89-cb19-4a70-b650-6e42da873acf@github.com>
Message-ID: <2dZvT6-2iut3bTqcKogop8rAucsK7w4iBz_w0BvloiA=.1a047145-39bd-45a9-ae08-4e22023de87b@github.com>

On Mon, 10 Mar 2025 14:08:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename method
>
> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 837:
> 
>> 835:         }
>> 836:         return diffLimited.get();
>> 837:     }
> 
> I think it would be better to add a boolean field `complete` to `Diff`, instead of having this be a property of a PullRequest. Then we avoid this awkward requirement for ordering calls on PullRequest.

Yes, this sounds much better. Thank you for the suggestion.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987649282

From zsong at openjdk.org  Wed Mar 12 22:42:04 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Mar 2025 22:42:04 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v3]
In-Reply-To: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
Message-ID: <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>

> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
> 
> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

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

 - fix copyright
 - update

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1708/files
  - new: https://git.openjdk.org/skara/pull/1708/files/502f5534..775e2944

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

  Stats: 199 lines in 13 files changed: 122 ins; 40 del; 37 mod
  Patch: https://git.openjdk.org/skara/pull/1708.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1708/head:pull/1708

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

From zsong at openjdk.org  Wed Mar 12 22:42:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Mar 2025 22:42:05 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v2]
In-Reply-To: <-c0NqbmXe-Jl4LtFmH3XyRjADDhABXXbc95czrAW8JY=.d547cc89-cb19-4a70-b650-6e42da873acf@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <d2I6nvs8jL0dfNemMYVGL_bjbIy6m2uoqGE6B498a-Q=.3cfc76c4-a9aa-4d84-8e52-881669e238fa@github.com>
 <-c0NqbmXe-Jl4LtFmH3XyRjADDhABXXbc95czrAW8JY=.d547cc89-cb19-4a70-b650-6e42da873acf@github.com>
Message-ID: <6y59YJ35bzyfBJOULOu95SULFy51-fUllFEDckEFUO0=.8628fe37-633f-45a7-91a2-03e4dc600cbd@github.com>

On Mon, 10 Mar 2025 14:01:35 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename method
>
> forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java line 48:
> 
>> 46: 
>> 47:     private List<Label> labels = null;
>> 48:     private Optional<Boolean> diffLimited = Optional.empty();
> 
> We should not use `Optional` in fields. If we need a tri-state for this boolean, then it's better to use `Boolean` and check for null.

Will fix it

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1987653844

From zsong at openjdk.org  Wed Mar 12 22:42:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 12 Mar 2025 22:42:05 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v3]
In-Reply-To: <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>
Message-ID: <IrpLle633J2GatL-KpRBm3PxzZeJeCHiJ6pvvLi90t0=.e5380b94-45b8-4ecd-ae8e-a3aa37b3c3c2@github.com>

On Wed, 12 Mar 2025 22:38:57 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix copyright
>  - update

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

> 832:         var changes = request.get("changes").param("access_raw_diffs", "true").execute();
> 833:         boolean diffComplete;
> 834:         if (changes.get("overflow").asBoolean()) {

During my experiment, I found we can't fully trust the "overflow" field returned by GitLab.

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

> 835:             diffComplete = false;
> 836:         } else {
> 837:             diffComplete = !changes.get("changes_count").asString().contains("+");

When overflow happens, GitLab returns the changes_count as "number+".

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

> 756:                 // The diff here is only used to evaluate if a backport PR is clean or not,
> 757:                 // assuming the diff is complete will not introduce any side effect.
> 758:                 diffs = List.of(toDiff(metadata.parents().get(0), hash, diff, true));

I thought the diff is only limited by the count of files. But I was wrong.
The diff is limited by 3 factors. So it's hard for us to know if it's limited or not.
https://docs.gitlab.com/administration/diff_limits/#configure-diff-limits

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992379177
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992381095
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992383526

From erikj at openjdk.org  Wed Mar 12 23:17:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Mar 2025 23:17:17 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v3]
In-Reply-To: <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>
Message-ID: <pqR9zz_mXwwZvFUfJwFkSlqlifVocK4N58uGX-GXty4=.01c05d99-0fc9-4207-aa61-97fb7b6032ba@github.com>

On Wed, 12 Mar 2025 22:42:04 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix copyright
>  - update

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

> 756:         } else {
> 757:             return repository.toDiff(targetHash, headHash(), files, true);
> 758:         }

Suggestion:

        var complete = files.asArray().size() != json.get("changed_files").asInt();
        return repository.toDiff(targetHash, headHash(), files, complete);

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

> 592:             } else {
> 593:                 diffs = List.of(toDiff(metadata.parents().get(0), hash, o.get("files"), false));
> 594:             }

Suggestion:

            var complete = totalAdditions == sumAdditions && totalDeletions == sumDeletions;
            diffs = List.of(toDiff(metadata.parents().get(0), hash, o.get("files"), complete));

vcs/src/main/java/org/openjdk/skara/vcs/Diff.java line 45:

> 43:         this.to = to;
> 44:         this.patches = patches;
> 45:         this.complete = true;

Suggestion:

        this(from, to, patches, true);

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992412968
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992414069
PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992417565

From erikj at openjdk.org  Wed Mar 12 23:17:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 12 Mar 2025 23:17:17 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v3]
In-Reply-To: <IrpLle633J2GatL-KpRBm3PxzZeJeCHiJ6pvvLi90t0=.e5380b94-45b8-4ecd-ae8e-a3aa37b3c3c2@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <V5ktht8YwzXjs5RNbuY_Vc40th53TsTs2zI62FOGZng=.cea76fba-13c5-489a-af23-9509ad40e4c4@github.com>
 <IrpLle633J2GatL-KpRBm3PxzZeJeCHiJ6pvvLi90t0=.e5380b94-45b8-4ecd-ae8e-a3aa37b3c3c2@github.com>
Message-ID: <hADtfhP2kIR0SdmgkSpOg2YOZ-saNGfhG9Gmnza1feM=.e6618ef9-3982-4489-b00c-6be68085f0f0@github.com>

On Wed, 12 Mar 2025 22:30:36 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix copyright
>>  - update
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 758:
> 
>> 756:                 // The diff here is only used to evaluate if a backport PR is clean or not,
>> 757:                 // assuming the diff is complete will not introduce any side effect.
>> 758:                 diffs = List.of(toDiff(metadata.parents().get(0), hash, diff, true));
> 
> I thought the diff is only limited by the count of files. But I was wrong.
> The diff is limited by 3 factors. So it's hard for us to know if it's limited or not.
> https://docs.gitlab.com/administration/diff_limits/#configure-diff-limits

I think this is fine. We could perhaps sum files and patch size and compare to the default values (200KB and 1000 files) and at least get a reasonable chance and flagging incomplete when it is.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1708#discussion_r1992416009

From zsong at openjdk.org  Thu Mar 13 17:20:35 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 13 Mar 2025 17:20:35 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v4]
In-Reply-To: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
Message-ID: <dBenLCIH5NTbG4L1OizmJokUFR_6DUmQ29EWgxy87VE=.14f2b3a0-d01f-41c2-8c0c-9eb408b3dfea@github.com>

> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
> 
> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

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

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

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1708/files
  - new: https://git.openjdk.org/skara/pull/1708/files/775e2944..e71b6bd2

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

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

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

From erikj at openjdk.org  Thu Mar 13 17:32:12 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 13 Mar 2025 17:32:12 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v4]
In-Reply-To: <dBenLCIH5NTbG4L1OizmJokUFR_6DUmQ29EWgxy87VE=.14f2b3a0-d01f-41c2-8c0c-9eb408b3dfea@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <dBenLCIH5NTbG4L1OizmJokUFR_6DUmQ29EWgxy87VE=.14f2b3a0-d01f-41c2-8c0c-9eb408b3dfea@github.com>
Message-ID: <YKlPLrqtRdBbHGI8WHXsgX4ALUiStA2DVWJ7x3_8Dqg=.32b9a020-7161-421b-9ce8-bd6264eed2df@github.com>

On Thu, 13 Mar 2025 17:20:35 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update forge/src/main/java/org/openjdk/skara/forge/github/GitHubRepository.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update vcs/src/main/java/org/openjdk/skara/vcs/Diff.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>  - Update forge/src/main/java/org/openjdk/skara/forge/github/GitHubPullRequest.java
>    
>    Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1708#pullrequestreview-2682860400

From zsong at openjdk.org  Thu Mar 13 17:53:27 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 13 Mar 2025 17:53:27 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v5]
In-Reply-To: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
Message-ID: <-dhq0TOKp2wdmvQEsQ1lK_Ir22jFW3ZARDGZzVQWyko=.91d07166-8fbc-47a6-8de7-d263bd4f9c38@github.com>

> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
> 
> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

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

  fix a typo

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1708/files
  - new: https://git.openjdk.org/skara/pull/1708/files/e71b6bd2..00a69dc2

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

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

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

From zsong at openjdk.org  Thu Mar 13 21:04:20 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 13 Mar 2025 21:04:20 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v5]
In-Reply-To: <-dhq0TOKp2wdmvQEsQ1lK_Ir22jFW3ZARDGZzVQWyko=.91d07166-8fbc-47a6-8de7-d263bd4f9c38@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <-dhq0TOKp2wdmvQEsQ1lK_Ir22jFW3ZARDGZzVQWyko=.91d07166-8fbc-47a6-8de7-d263bd4f9c38@github.com>
Message-ID: <bbql6bXDf7psa3dQP8W8bErpeBy6v-_OB8pcBK5dj20=.2ba790f2-f9d2-4812-924f-8e2fcc6dc182@github.com>

On Thu, 13 Mar 2025 17:53:27 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo

Thank you for the suggestions and review!

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

PR Comment: https://git.openjdk.org/skara/pull/1708#issuecomment-2722683030

From zsong at openjdk.org  Thu Mar 13 21:04:20 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 13 Mar 2025 21:04:20 GMT
Subject: Integrated: 2454: Skara mistakenly marked a non-clean backport as
 clean
In-Reply-To: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
Message-ID: <n-dSs9FSB6Ja4Trw5UrF_7nFIxBSLatipv0J2ydY08s=.68b1fd96-0dba-4136-b7cc-8b48361881c7@github.com>

On Fri, 7 Mar 2025 22:33:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
> 
> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.

This pull request has now been integrated.

Changeset: 79fda799
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/79fda7998c04568620f1d4df40ff69e35b101066
Stats:     195 lines in 11 files changed: 166 ins; 3 del; 26 mod

2454: Skara mistakenly marked a non-clean backport as clean

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Thu Mar 13 21:04:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 13 Mar 2025 21:04:20 GMT
Subject: RFR: 2454: Skara mistakenly marked a non-clean backport as clean
 [v5]
In-Reply-To: <-dhq0TOKp2wdmvQEsQ1lK_Ir22jFW3ZARDGZzVQWyko=.91d07166-8fbc-47a6-8de7-d263bd4f9c38@github.com>
References: <ICHCD9TNaooqXTuSZxLTzr7r-WT0V-YWZSgnQy7HGu4=.dab79958-dedd-4cee-8f3e-547183b8ada9@github.com>
 <-dhq0TOKp2wdmvQEsQ1lK_Ir22jFW3ZARDGZzVQWyko=.91d07166-8fbc-47a6-8de7-d263bd4f9c38@github.com>
Message-ID: <tuGJ4HsDb4SjaiFi1XmyhSIEMQKXsWae5K4jYeD2RJU=.8e11810f-b8de-4085-a776-b2c105de5b48@github.com>

On Thu, 13 Mar 2025 17:53:27 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> A user reported that Skara bot mistakenly marked a non-clean backport as clean. After investigation, I found that the PR was too large for the remote host to return the entire diff. The PR contained 8082 changed files, but when Skara bot requested the diff, only 3000 files were returned. Therefore, Skara bot was unable to compare some patches, so mistakenly mark the pr as clean.
>> 
>> In this patch, Skara bot will now check if the PR is too large to evaluate. If it is, Skara bot will not evaluate if this PR is clean and will add a warning comment to the PR instead.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1708#pullrequestreview-2683353590

From thartmann at openjdk.org  Mon Mar 24 10:20:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 10:20:12 GMT
Subject: RFR: 2460: test/hotspot/jtreg/testlibrary_tests/ir_framework and
 compile_framework should be mapped to hotspot-compiler [v2]
In-Reply-To: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
Message-ID: <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>

> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Added generators

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1709/files
  - new: https://git.openjdk.org/skara/pull/1709/files/eb3d409a..3ba4a0ba

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

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

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

From chagedorn at openjdk.org  Mon Mar 24 10:20:13 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 24 Mar 2025 10:20:13 GMT
Subject: RFR: 2460: test/hotspot/jtreg/testlibrary_tests/ir_framework and
 compile_framework should be mapped to hotspot-compiler [v2]
In-Reply-To: <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
Message-ID: <bbxeHcJSb_e65bvbbrRGNBEvjTFGstGcCcQr-Gdam7E=.d8a52b0d-23e7-47d7-9610-a3e38220d2e7@github.com>

On Mon, 24 Mar 2025 10:15:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added generators

Good idea!

config/mailinglist/rules/jdk.json line 276:

> 274:             "test/hotspot/jtreg/testlibrary/jittester/",
> 275:             "test/hotspot/jtreg/testlibrary_tests/compile_framework/",
> 276:             "test/hotspot/jtreg/testlibrary_tests/ir_framework/",

Should we also add [generators/tests](https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/testlibrary_tests/generators/tests)?

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

PR Review: https://git.openjdk.org/skara/pull/1709#pullrequestreview-2709839208
PR Review Comment: https://git.openjdk.org/skara/pull/1709#discussion_r2009868550

From thartmann at openjdk.org  Mon Mar 24 10:20:13 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 10:20:13 GMT
Subject: RFR: 2460: test/hotspot/jtreg/testlibrary_tests/ir_framework and
 compile_framework should be mapped to hotspot-compiler [v2]
In-Reply-To: <bbxeHcJSb_e65bvbbrRGNBEvjTFGstGcCcQr-Gdam7E=.d8a52b0d-23e7-47d7-9610-a3e38220d2e7@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
 <bbxeHcJSb_e65bvbbrRGNBEvjTFGstGcCcQr-Gdam7E=.d8a52b0d-23e7-47d7-9610-a3e38220d2e7@github.com>
Message-ID: <UhFFoxPANqpEe0EroXPRjRzzkEW_FzC-mzvKEmSN3nw=.954ac1f5-b3b1-43db-bbb4-12471e01b1b0@github.com>

On Mon, 24 Mar 2025 10:13:30 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added generators
>
> config/mailinglist/rules/jdk.json line 276:
> 
>> 274:             "test/hotspot/jtreg/testlibrary/jittester/",
>> 275:             "test/hotspot/jtreg/testlibrary_tests/compile_framework/",
>> 276:             "test/hotspot/jtreg/testlibrary_tests/ir_framework/",
> 
> Should we also add [generators/tests](https://github.com/openjdk/jdk/tree/master/test/hotspot/jtreg/testlibrary_tests/generators/tests)?

Good catch, I added it as well.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1709#discussion_r2009872633

From chagedorn at openjdk.org  Mon Mar 24 10:25:40 2025
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Mon, 24 Mar 2025 10:25:40 GMT
Subject: RFR: 2460: test/hotspot/jtreg/testlibrary_tests/ir_framework and
 compile_framework should be mapped to hotspot-compiler [v2]
In-Reply-To: <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
Message-ID: <UGWF-Z5cXHPklDqWyI-LNDIFu6Hk4xw6r21F7dqMEQc=.ec75766f-f232-4bcb-a094-fbcef753a824@github.com>

On Mon, 24 Mar 2025 10:20:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added generators

Looks good, thanks! Maybe you now also want to adjust to title to something like "compiler related folders in test/hotspot/jtreg/testlibrary_tests should be mapped to hotspot-compiler"

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

Marked as reviewed by chagedorn (no project role).

PR Review: https://git.openjdk.org/skara/pull/1709#pullrequestreview-2709868273

From thartmann at openjdk.org  Mon Mar 24 10:27:59 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 10:27:59 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v2]
In-Reply-To: <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <2fGW7RUjSZ-V_TBtYqSzEaaZIpwuCo7kDfgsWVXnqHs=.1dcd3d46-6022-4db2-bffc-fac409956c9a@github.com>
Message-ID: <1X9PkWuAKXG17S4ls1pR2iQxSLY8DIUBUfJZlHgjABY=.5bb1ca10-6372-472c-b3e4-7f1afadccdea@github.com>

On Mon, 24 Mar 2025 10:20:12 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added generators

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1709#issuecomment-2747619007

From thartmann at openjdk.org  Mon Mar 24 11:36:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 11:36:19 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
Message-ID: <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>

> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
> 
> Thanks,
> Tobias

Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:

  Added the verify folder as well

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1709/files
  - new: https://git.openjdk.org/skara/pull/1709/files/3ba4a0ba..9c405419

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

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

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

From epeter at openjdk.org  Mon Mar 24 11:36:19 2025
From: epeter at openjdk.org (Emanuel Peter)
Date: Mon, 24 Mar 2025 11:36:19 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
Message-ID: <lcOzjhHxj5CNKfLfDOFfScPjDSGicU8ja34YBdk8Uz0=.904907cf-6db6-497c-bb53-4689ca5a0534@github.com>

On Mon, 24 Mar 2025 11:33:50 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verify folder as well

Marked as reviewed by epeter (no project role).

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

PR Review: https://git.openjdk.org/skara/pull/1709#pullrequestreview-2710058969

From thartmann at openjdk.org  Mon Mar 24 11:36:19 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 11:36:19 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <lcOzjhHxj5CNKfLfDOFfScPjDSGicU8ja34YBdk8Uz0=.904907cf-6db6-497c-bb53-4689ca5a0534@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
 <lcOzjhHxj5CNKfLfDOFfScPjDSGicU8ja34YBdk8Uz0=.904907cf-6db6-497c-bb53-4689ca5a0534@github.com>
Message-ID: <qM5Vl80pLFqMPIStTxFXnFfJQ694y0-g3LjA0ET03rE=.f994248e-856a-4c83-b053-34e7f97ef6d5@github.com>

On Mon, 24 Mar 2025 11:33:30 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added the verify folder as well
>
> Marked as reviewed by epeter (no project role).

@eme64 noticed that the verify folder is missing as well. Added. Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1709#issuecomment-2747815346

From erikj at openjdk.org  Mon Mar 24 13:02:19 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 24 Mar 2025 13:02:19 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
Message-ID: <c8yxz2_MlGtSd9lqX0j-3d8mjRXpQl-Oa4yVLBdL4Ls=.daeb925e-5adf-45a7-b1c5-1e9b862fd6b5@github.com>

On Mon, 24 Mar 2025 11:36:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verify folder as well

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1709#pullrequestreview-2710301076

From thartmann at openjdk.org  Mon Mar 24 14:02:12 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 24 Mar 2025 14:02:12 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
Message-ID: <xd5d99vZdjbPXEVEgkP5e3VSSkGBwPsBdohkW2Weeng=.21d58a9c-0df8-4789-ac7d-047355643106@github.com>

On Mon, 24 Mar 2025 11:36:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verify folder as well

Thanks for the review, Erik!

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

PR Comment: https://git.openjdk.org/skara/pull/1709#issuecomment-2748231479

From duke at openjdk.org  Tue Mar 25 08:26:34 2025
From: duke at openjdk.org (duke)
Date: Tue, 25 Mar 2025 08:26:34 GMT
Subject: RFR: 2460: Some folders in test/hotspot/jtreg/testlibrary_tests/
 should be mapped to hotspot-compiler [v3]
In-Reply-To: <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
 <iaowakmkZT5LuS3lMG4cU1Im4AEjCF6lsmQglhGRsjw=.26ba093f-6c52-4646-b2c1-7191c23af002@github.com>
Message-ID: <Va_buIfg3ZzMZDjSGn4kUgq8gS-11XDUCK40YJVKFS4=.dfe3d0c2-873c-467e-9f0c-5bbb4130fedd@github.com>

On Mon, 24 Mar 2025 11:36:19 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
>> 
>> Thanks,
>> Tobias
>
> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added the verify folder as well

@TobiHartmann 
Your change (at version 9c405419066dcb55479fdfd4a69b5a87bf12a3a6) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/skara/pull/1709#issuecomment-2750457182

From thartmann at openjdk.org  Tue Mar 25 10:28:18 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 25 Mar 2025 10:28:18 GMT
Subject: Integrated: 2460: Some folders in
 test/hotspot/jtreg/testlibrary_tests/ should be mapped to hotspot-compiler
In-Reply-To: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
References: <09A1cCZBgH-C4dg13ry6dyxWuAS-hdmk_dgMITz5NvA=.21137620-60dd-4b7d-a573-7cc708d270d8@github.com>
Message-ID: <DvSjN0AlNNSfSKyuCPsvUHpWoqgwvs8HiqrP4F-YPR8=.856d1d0c-1038-4797-9491-503fcd88a236@github.com>

On Mon, 24 Mar 2025 09:55:03 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> The IR Test Framework ([JDK-8254129](https://bugs.openjdk.org/browse/JDK-8254129)) and the Compile Framework ([JDK-8337221](https://bugs.openjdk.org/browse/JDK-8337221)) are owned by hotspot-compiler.
> 
> Thanks,
> Tobias

This pull request has now been integrated.

Changeset: e0767b8b
Author:    Tobias Hartmann <thartmann at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/e0767b8b621b18c813ea579161791a836625d540
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

2460: Some folders in test/hotspot/jtreg/testlibrary_tests/ should be mapped to hotspot-compiler

Reviewed-by: epeter, erikj, chagedorn

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

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

From ihse at openjdk.org  Tue Mar 25 16:34:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 25 Mar 2025 16:34:46 GMT
Subject: RFR: 2466: Cut down list of other commits from 10 to 3
Message-ID: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>

Skara prints a list of other commits that has been integrated before a PR is automatically rebased. I think the idea was to put transparency to the rebasing process, but in actuality it only adds noise.

I think it could be removed entirely (in general, I think the Skara bot messages are *waaaay* to chatty), but as a start, it the list could be shortened radically. I chose 3 as the lowest number that is still a "crowd".

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

Commit messages:
 - 2466: Cut down list of other commits from 10 to 3

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

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

From kcr at openjdk.org  Tue Mar 25 16:46:46 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 25 Mar 2025 16:46:46 GMT
Subject: RFR: 2466: Cut down list of other commits from 10 to 3
In-Reply-To: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
References: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
Message-ID: <Jy4RBnMGD0Na2u3K2X-5uX8RKX8fe0LEoCgbMaq1u1E=.fdfbfad9-ed7a-4bbe-b276-6fcf9faa9df7@github.com>

On Tue, 25 Mar 2025 16:29:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think it could be removed entirely (in general, I think the Skara bot messages are waaaay to chatty), but as a start, it the list could be shortened radically. I chose 3 as the lowest number that is still a "crowd".

I think cutting the list down from 10 to 3 is reasonable. I disagree with the idea of ever removing it, since knowing whether or not you are at the tip is very helpful in some cases.

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

PR Comment: https://git.openjdk.org/skara/pull/1710#issuecomment-2751892212

From erikj at openjdk.org  Tue Mar 25 17:32:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Mar 2025 17:32:43 GMT
Subject: RFR: 2466: Cut down list of other commits from 10 to 3
In-Reply-To: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
References: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
Message-ID: <cza_TpMOlLhN9ZLi8q8SHpLDtVbpqrVRkzFquLy0gmM=.94dd95c1-f717-416e-ae1d-e4337da1ffa1@github.com>

On Tue, 25 Mar 2025 16:29:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Skara prints a list of other commits that has been integrated before a PR is automatically rebased. I think the idea was to put transparency to the rebasing process, but in actuality it only adds noise.
> 
> I think it could be removed entirely (in general, I think the Skara bot messages are *waaaay* to chatty), but as a start, it the list could be shortened radically. I chose 3 as the lowest number that is still a "crowd".

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

> 50: class CheckRun {
> 51:     public static final String MSG_EMPTY_BODY = "The pull request body must not be empty.";
> 52:     private static final int COMMIT_LIST_LIMIT = 3;

I think we should share this constant between these two classes.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1710#discussion_r2012595837

From zsong at openjdk.org  Tue Mar 25 19:24:56 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 25 Mar 2025 19:24:56 GMT
Subject: RFR: 2467: Skara bot mistakenly reset the committer when amending
 commit message
Message-ID: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>

Kevin Rushforth reported that this commit(https://github.com/openjdk/skara/commit/e0767b8b621b18c813ea579161791a836625d540) was sponsored by Magnus, so Magnus should be the committer, however, Tobias was set as the committer.

After investigation, I found that there is a stale review in the pr, so the bot amended the commit before pushing it. When amending the commit, the bot should only amend the commit message, however, it also reset the committer.

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

Commit messages:
 - update
 - SKARA-2467

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

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

From erikj at openjdk.org  Tue Mar 25 19:48:03 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Mar 2025 19:48:03 GMT
Subject: RFR: 2467: Skara bot mistakenly reset the committer when amending
 commit message
In-Reply-To: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
References: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
Message-ID: <M2n_fxgpHIs58wcC3kX3maDIBhMQR34s7fz4BtdW7Vc=.4cf88ebb-3f0a-44f7-9886-3f3d7d92c276@github.com>

On Tue, 25 Mar 2025 19:21:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Kevin Rushforth reported that this commit(https://github.com/openjdk/skara/commit/e0767b8b621b18c813ea579161791a836625d540) was sponsored by Magnus, so Magnus should be the committer, however, Tobias was set as the committer.
> 
> After investigation, I found that there is a stale review in the pr, so the bot amended the commit before pushing it. When amending the commit, the bot should only amend the commit message, however, it also reset the committer.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1711#pullrequestreview-2714999175

From zsong at openjdk.org  Tue Mar 25 20:13:10 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 25 Mar 2025 20:13:10 GMT
Subject: RFR: 2467: Skara bot mistakenly reset the committer when amending
 commit message
In-Reply-To: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
References: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
Message-ID: <io0qkfU91446XwoPilfNMsmvy5RHat1v6qH9d4uG0yA=.105b6714-69b9-45e8-8bd2-9604cafbb8f3@github.com>

On Tue, 25 Mar 2025 19:21:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Kevin Rushforth reported that this commit(https://github.com/openjdk/skara/commit/e0767b8b621b18c813ea579161791a836625d540) was sponsored by Magnus, so Magnus should be the committer, however, Tobias was set as the committer.
> 
> After investigation, I found that there is a stale review in the pr, so the bot amended the commit before pushing it. When amending the commit, the bot should only amend the commit message, however, it also reset the committer.

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1711#issuecomment-2752402962

From zsong at openjdk.org  Tue Mar 25 20:13:10 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 25 Mar 2025 20:13:10 GMT
Subject: Integrated: 2467: Skara bot mistakenly reset the committer when
 amending commit message
In-Reply-To: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
References: <DK9Bb63ya61AMCSw_fKNXtW3liuw4xxveot7GurrFNs=.b1799927-a18f-4993-97b2-98b1bc649505@github.com>
Message-ID: <xeYXoZj8YfTy_w3Zn3T7HdyILZ95VmhqHGf4bW-Pe70=.a6d7af96-f3bc-4aa9-a20d-a1b9380a5f0e@github.com>

On Tue, 25 Mar 2025 19:21:34 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Kevin Rushforth reported that this commit(https://github.com/openjdk/skara/commit/e0767b8b621b18c813ea579161791a836625d540) was sponsored by Magnus, so Magnus should be the committer, however, Tobias was set as the committer.
> 
> After investigation, I found that there is a stale review in the pr, so the bot amended the commit before pushing it. When amending the commit, the bot should only amend the commit message, however, it also reset the committer.

This pull request has now been integrated.

Changeset: 6ccf2596
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/6ccf2596d1be2e39a4e9da566a461f1977679d13
Stats:     99 lines in 2 files changed: 92 ins; 0 del; 7 mod

2467: Skara bot mistakenly reset the committer when amending commit message

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Tue Mar 25 22:04:09 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 25 Mar 2025 22:04:09 GMT
Subject: RFR: 2468: PR bot mistakenly stop warning about empty pr body
Message-ID: <vVl7AzNOr5d_36aZhF-eJ-2-mSUHJQRZhuM-7ean5yk=.7a5d6ef1-ca80-4d71-af1f-97b1d96e2f87@github.com>

In a pull request, the user didn't put anything in the pr body. At first, skara bot successfully detected the empty body and showed the error "The pull request body must not be empty." However, after the pull request is updated, the error disappeared.
After investigation, I found that if the pr body is empty, skara bot would add a "EMPTY_PR_BODY_MARKER" to the pr body, and later, skara bot would mistakenly treat it as the body added by user.

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

Commit messages:
 - SKARA-2468

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

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

From erikj at openjdk.org  Tue Mar 25 23:27:38 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 25 Mar 2025 23:27:38 GMT
Subject: RFR: 2468: PR bot mistakenly stop warning about empty pr body
In-Reply-To: <vVl7AzNOr5d_36aZhF-eJ-2-mSUHJQRZhuM-7ean5yk=.7a5d6ef1-ca80-4d71-af1f-97b1d96e2f87@github.com>
References: <vVl7AzNOr5d_36aZhF-eJ-2-mSUHJQRZhuM-7ean5yk=.7a5d6ef1-ca80-4d71-af1f-97b1d96e2f87@github.com>
Message-ID: <CiaDKkIBB7vaZvS8gTraJFcW_smILBvc8Kwst_AlI9I=.2908defe-bcf0-44fc-bc94-7d76350aa3f2@github.com>

On Tue, 25 Mar 2025 22:00:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In a pull request, the user didn't put anything in the pr body. At first, skara bot successfully detected the empty body and showed the error "The pull request body must not be empty." However, after the pull request is updated, the error disappeared.
> After investigation, I found that if the pr body is empty, skara bot would add a "EMPTY_PR_BODY_MARKER" to the pr body, and later, skara bot would mistakenly treat it as the body added by user.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1712#pullrequestreview-2715412912

From ihse at openjdk.org  Wed Mar 26 10:22:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 26 Mar 2025 10:22:03 GMT
Subject: RFR: 2466: Cut down list of other commits from 10 to 3
In-Reply-To: <cza_TpMOlLhN9ZLi8q8SHpLDtVbpqrVRkzFquLy0gmM=.94dd95c1-f717-416e-ae1d-e4337da1ffa1@github.com>
References: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
 <cza_TpMOlLhN9ZLi8q8SHpLDtVbpqrVRkzFquLy0gmM=.94dd95c1-f717-416e-ae1d-e4337da1ffa1@github.com>
Message-ID: <GNdvbt_u1HF_MKpDpTBnSFKM4D4TcTLAFTS21IJfDAg=.0d96ecab-2d2b-459a-a3cd-820a56a52932@github.com>

On Tue, 25 Mar 2025 17:29:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Skara prints a list of other commits that has been integrated before a PR is automatically rebased. I think the idea was to put transparency to the rebasing process, but in actuality it only adds noise.
>> 
>> I think it could be removed entirely (in general, I think the Skara bot messages are *waaaay* to chatty), but as a start, it the list could be shortened radically. I chose 3 as the lowest number that is still a "crowd".
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 52:
> 
>> 50: class CheckRun {
>> 51:     public static final String MSG_EMPTY_BODY = "The pull request body must not be empty.";
>> 52:     private static final int COMMIT_LIST_LIMIT = 3;
> 
> I think we should share this constant between these two classes.

That sounds good. Where should I place it? I did not want to introduce a dependency between the two classes since I did not know how they relate.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1710#discussion_r2013815778

From erikj at openjdk.org  Wed Mar 26 12:46:43 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 26 Mar 2025 12:46:43 GMT
Subject: RFR: 2466: Cut down list of other commits from 10 to 3
In-Reply-To: <GNdvbt_u1HF_MKpDpTBnSFKM4D4TcTLAFTS21IJfDAg=.0d96ecab-2d2b-459a-a3cd-820a56a52932@github.com>
References: <uT7O3Wwm7qagVcfLXJfZq3VtTbyCPpAYxAhhP1OcOEE=.20d53322-e29e-4a6e-b3b9-8d50057f5b6e@github.com>
 <cza_TpMOlLhN9ZLi8q8SHpLDtVbpqrVRkzFquLy0gmM=.94dd95c1-f717-416e-ae1d-e4337da1ffa1@github.com>
 <GNdvbt_u1HF_MKpDpTBnSFKM4D4TcTLAFTS21IJfDAg=.0d96ecab-2d2b-459a-a3cd-820a56a52932@github.com>
Message-ID: <QlkUaluZqEfakgJV4BUt6pg5JknUtN2cFTwW5-X_tLY=.b5c92f97-2167-45d3-9213-291d350d3a77@github.com>

On Wed, 26 Mar 2025 10:19:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 52:
>> 
>>> 50: class CheckRun {
>>> 51:     public static final String MSG_EMPTY_BODY = "The pull request body must not be empty.";
>>> 52:     private static final int COMMIT_LIST_LIMIT = 3;
>> 
>> I think we should share this constant between these two classes.
>
> That sounds good. Where should I place it? I did not want to introduce a dependency between the two classes since I did not know how they relate.

It doesn't matter that much, but `CheckRun` uses `CheckablePullRequest` so maybe a bit better to put it in the latter. It's just a constant and these classes are part of the same package.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1710#discussion_r2014065498

From zsong at openjdk.org  Wed Mar 26 17:48:23 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 26 Mar 2025 17:48:23 GMT
Subject: RFR: 2468: PR bot mistakenly stop warning about empty pr body
In-Reply-To: <vVl7AzNOr5d_36aZhF-eJ-2-mSUHJQRZhuM-7ean5yk=.7a5d6ef1-ca80-4d71-af1f-97b1d96e2f87@github.com>
References: <vVl7AzNOr5d_36aZhF-eJ-2-mSUHJQRZhuM-7ean5yk=.7a5d6ef1-ca80-4d71-af1f-97b1d96e2f87@github.com>
Message-ID: <ni8M6Fb21MwUcWRRl3ydkU7DfEGAsqFwtkO6ndtpqTs=.e7a6b570-2f67-466d-98e5-e7166da2e0cc@github.com>

On Tue, 25 Mar 2025 22:00:32 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In a pull request, the user didn't put anything in the pr body. At first, skara bot successfully detected the empty body and showed the error "The pull request body must not be empty." However, after the pull request is updated, the error disappeared.
> After investigation, I found that if the pr body is empty, skara bot would add a "EMPTY_PR_BODY_MARKER" to the pr body, and later, skara bot would mistakenly treat it as the body added by user.

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1712#issuecomment-2755295839