From erikj at openjdk.org  Fri Aug  1 19:37:18 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 1 Aug 2025 19:37:18 GMT
Subject: RFR: 2510: Bug closed due to inactivity even though there was
 "activity"
In-Reply-To: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
References: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
Message-ID: <Xk29J_iFCiGmXeYlh-OxPUA_2C96Ez2p_PBNPnCLzHs=.8e305dde-042b-4f5b-887c-44374dd3be52@github.com>

On Wed, 2 Jul 2025 18:26:03 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the PullRequestPrunerBot considers only comments, reviews, and review comments as activity. Therefore, it can sometimes mistakenly close a user's pull request.
> 
> In this patch, I am trying to let PullRequestPrunerBot counts commits, pr state changes as valid activities.

Looks good!

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

Marked as reviewed by erikj (Lead).

PR Review: https://git.openjdk.org/skara/pull/1723#pullrequestreview-3080364953

From zsong at openjdk.org  Fri Aug  1 19:53:24 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Aug 2025 19:53:24 GMT
Subject: RFR: 2408: Require at least one component/area label before a PR can
 be integrated
Message-ID: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>

This patch is trying to improve the bot by ensuring that if the repo has the label configuration, then any pull request in this repo should only be marked as "rfr" when at least one component is associated with the pr.

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

Commit messages:
 - update
 - SKARA-2048

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

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

From zsong at openjdk.org  Fri Aug  1 19:53:35 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 1 Aug 2025 19:53:35 GMT
Subject: RFR: 2527: Sponsored commits may get wrong author
Message-ID: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>

When determining the author of a commit, if the author of pr doesn't have OpenJDK Id, the bot falls back to use the author from the last commit of the pr, in this way, the bot may give credit to the wrong person. 
In this patch, if the author of pr doesn't have OpenJDK Id, the bot will try to parse full name and email from the forge first, if it fails, then it will fall back to use the author of the last commit.

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

Commit messages:
 - SKARA-2527

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

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

From zsong at openjdk.org  Mon Aug  4 17:53:41 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 4 Aug 2025 17:53:41 GMT
Subject: RFR: 2510: Bug closed due to inactivity even though there was
 "activity"
In-Reply-To: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
References: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
Message-ID: <VKdiiGfptdBgUAwz8yedbu2geg93GjQ2d-2jeKFOzAo=.2668690a-4f93-4eff-8546-6f9c7e2b1964@github.com>

On Wed, 2 Jul 2025 18:26:03 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the PullRequestPrunerBot considers only comments, reviews, and review comments as activity. Therefore, it can sometimes mistakenly close a user's pull request.
> 
> In this patch, I am trying to let PullRequestPrunerBot counts commits, pr state changes as valid activities.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1723#issuecomment-3151812575

From zsong at openjdk.org  Mon Aug  4 17:53:41 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 4 Aug 2025 17:53:41 GMT
Subject: Integrated: 2510: Bug closed due to inactivity even though there was
 "activity"
In-Reply-To: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
References: <8ASTfNy1jJJjaRe8EfR_OzYDfYgDGy-2MyNFz9ZlBtU=.9e166f5c-4d10-44e8-8f80-461e326544b9@github.com>
Message-ID: <uD7HcPNrj8BTmCaW3wPX3BvfCDog8PrJEkWA19Upzj0=.4fff1c30-fdad-4c4e-b9ed-e161ffb453c6@github.com>

On Wed, 2 Jul 2025 18:26:03 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the PullRequestPrunerBot considers only comments, reviews, and review comments as activity. Therefore, it can sometimes mistakenly close a user's pull request.
> 
> In this patch, I am trying to let PullRequestPrunerBot counts commits, pr state changes as valid activities.

This pull request has now been integrated.

Changeset: 374f7551
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/374f7551161810e97bb6331c8598f342e529e4d3
Stats:     135 lines in 12 files changed: 123 ins; 0 del; 12 mod

2510: Bug closed due to inactivity even though there was "activity"

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Tue Aug  5 12:08:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Aug 2025 12:08:39 GMT
Subject: RFR: 2408: Require at least one component/area label before a PR
 can be integrated
In-Reply-To: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
References: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
Message-ID: <pctxbFIqxnPsK9kYE2E7M5rBvF6t1Yg2Yf6qvZF3Q5s=.760c32cb-c93b-4805-921f-08e2b2f59056@github.com>

On Thu, 31 Jul 2025 21:46:26 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to improve the bot by ensuring that if the repo has the label configuration, then any pull request in this repo should only be marked as "rfr" when at least one component is associated with the pr.

That was simpler than I thought it would be. Looks good!

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

Marked as reviewed by erikj (Lead).

PR Review: https://git.openjdk.org/skara/pull/1727#pullrequestreview-3087999243

From erikj at openjdk.org  Tue Aug  5 12:10:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 5 Aug 2025 12:10:13 GMT
Subject: RFR: 2527: Sponsored commits may get wrong author
In-Reply-To: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
References: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
Message-ID: <HT9SV2QqaJ7pB8tasb0lcKFg0Pe3iGk5L6BdDEoF5RE=.91735b40-3b40-4754-a1c4-bbb71a2640b5@github.com>

On Thu, 17 Jul 2025 21:11:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When determining the author of a commit, if the author of pr doesn't have OpenJDK Id, the bot falls back to use the author from the last commit of the pr, in this way, the bot may give credit to the wrong person. 
> In this patch, if the author of pr doesn't have OpenJDK Id, the bot will try to parse full name and email from the forge first, if it fails, then it will fall back to use the author of the last commit.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1726#pullrequestreview-3088004245

From zsong at openjdk.org  Tue Aug  5 16:41:27 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 5 Aug 2025 16:41:27 GMT
Subject: RFR: 2527: Sponsored commits may get wrong author
In-Reply-To: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
References: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
Message-ID: <2NHpen8doPtMD_kVBjSvVG5CJwtY6cr_hrKg6jAJD44=.cf25dd98-6758-4732-bca0-f6445e65bd45@github.com>

On Thu, 17 Jul 2025 21:11:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When determining the author of a commit, if the author of pr doesn't have OpenJDK Id, the bot falls back to use the author from the last commit of the pr, in this way, the bot may give credit to the wrong person. 
> In this patch, if the author of pr doesn't have OpenJDK Id, the bot will try to parse full name and email from the forge first, if it fails, then it will fall back to use the author of the last commit.

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1726#issuecomment-3155855176

From zsong at openjdk.org  Tue Aug  5 16:41:27 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 5 Aug 2025 16:41:27 GMT
Subject: Integrated: 2527: Sponsored commits may get wrong author
In-Reply-To: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
References: <yzLfOx4lwM8lIzl59nf-ykZ_Tc535VdJvq3H3lpB_Ew=.7d3b3a12-e4d7-416f-8f9e-4258e6c79457@github.com>
Message-ID: <NxC9I-TLTbgfRiQ78-1YmVSIZemJEeoFEbTLCcYfaYc=.0d3e386c-609c-4a13-ad36-a95e0c7cd436@github.com>

On Thu, 17 Jul 2025 21:11:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When determining the author of a commit, if the author of pr doesn't have OpenJDK Id, the bot falls back to use the author from the last commit of the pr, in this way, the bot may give credit to the wrong person. 
> In this patch, if the author of pr doesn't have OpenJDK Id, the bot will try to parse full name and email from the forge first, if it fails, then it will fall back to use the author of the last commit.

This pull request has now been integrated.

Changeset: 5400a26c
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/5400a26c577b08ff958e62134edaca01a532deed
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

2527: Sponsored commits may get wrong author

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Tue Aug  5 16:47:13 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 5 Aug 2025 16:47:13 GMT
Subject: RFR: 2408: Require at least one component/area label before a PR
 can be integrated
In-Reply-To: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
References: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
Message-ID: <ogew9yTnYl846TQ60maZxK9a6zkTtdtbc6ksN_N1T-M=.64e266d4-bc16-4613-ae4c-493871f3ace2@github.com>

On Thu, 31 Jul 2025 21:46:26 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to improve the bot by ensuring that if the repo has the label configuration, then any pull request in this repo should only be marked as "rfr" when at least one component is associated with the pr.

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1727#issuecomment-3155870958

From zsong at openjdk.org  Tue Aug  5 16:47:13 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 5 Aug 2025 16:47:13 GMT
Subject: Integrated: 2408: Require at least one component/area label before a
 PR can be integrated
In-Reply-To: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
References: <mPn0h64gk7o-InA0xnTbGfR3JkAMtZwiVziLIa8NAVE=.44f5b289-5c82-467f-a2b3-14d9d4a2acbb@github.com>
Message-ID: <nkqj3RNBMUHfvGbCYwSvanbstGQhzEyVudHxIfqy3HU=.20aace13-f27e-42bd-9418-ab18bd458bb8@github.com>

On Thu, 31 Jul 2025 21:46:26 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to improve the bot by ensuring that if the repo has the label configuration, then any pull request in this repo should only be marked as "rfr" when at least one component is associated with the pr.

This pull request has now been integrated.

Changeset: f8e06d95
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/f8e06d95bdec0634dd3d4b0f471e26be86da8d4f
Stats:     14 lines in 2 files changed: 11 ins; 0 del; 3 mod

2408: Require at least one component/area label before a PR can be integrated

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Tue Aug  5 21:08:46 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 5 Aug 2025 21:08:46 GMT
Subject: RFR: 2552: Followup of SKARA-2408
Message-ID: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>

[SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) is not working as expected since the first CheckWorkItem is processed before LabelerWorkItem. Therefore, the logic I added in [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) won't stop the bot from adding "rfr" label in the firstCheckWorkItem.

Currently, If a pr is not associated with any component, the bot will
1. Add "rfr" label in the first CheckWorkItem
2. Execute the LabelerWorkItem
3. In the next CheckWorkItem, it will remove the "rfr" label

This will cause a race between mlbridgeBot and prBot.

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

Commit messages:
 - update
 - update
 - SKARA-2552

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

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

From erikj at openjdk.org  Wed Aug  6 12:36:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 12:36:53 GMT
Subject: RFR: 2552: Followup of SKARA-2408
In-Reply-To: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
References: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
Message-ID: <aYg1QlbGIbecBxmP6amEwtwvjaUNUqXvOSXUiNxbgd4=.d0e2a6a3-b27f-45c2-880b-3d6885590de1@github.com>

On Tue, 5 Aug 2025 17:56:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) is not working as expected since the first CheckWorkItem is processed before LabelerWorkItem. Therefore, the logic I added in [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) won't stop the bot from adding "rfr" label in the firstCheckWorkItem.
> 
> Currently, If a pr is not associated with any component, the bot will
> 1. Add "rfr" label in the first CheckWorkItem
> 2. Execute the LabelerWorkItem
> 3. In the next CheckWorkItem, it will remove the "rfr" label
> 
> This will cause a race between mlbridgeBot and prBot.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1728#pullrequestreview-3092340142

From zsong at openjdk.org  Wed Aug  6 16:47:53 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Aug 2025 16:47:53 GMT
Subject: RFR: 2552: Followup of SKARA-2408
In-Reply-To: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
References: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
Message-ID: <xOyWdzGJ1M-htawEZpnEt-AFn_Qhk88lWVQyKexcw7Y=.3d9672a8-b099-44c7-abb9-2e678c58a902@github.com>

On Tue, 5 Aug 2025 17:56:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) is not working as expected since the first CheckWorkItem is processed before LabelerWorkItem. Therefore, the logic I added in [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) won't stop the bot from adding "rfr" label in the firstCheckWorkItem.
> 
> Currently, If a pr is not associated with any component, the bot will
> 1. Add "rfr" label in the first CheckWorkItem
> 2. Execute the LabelerWorkItem
> 3. In the next CheckWorkItem, it will remove the "rfr" label
> 
> This will cause a race between mlbridgeBot and prBot.

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1728#issuecomment-3160868244

From zsong at openjdk.org  Wed Aug  6 16:47:53 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Aug 2025 16:47:53 GMT
Subject: Integrated: 2552: Followup of SKARA-2408
In-Reply-To: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
References: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
Message-ID: <kwlZfFK4JRasCUcO7WDw1K2MCuJfx9cqPgvBKUcMjRU=.cbb70a6b-975e-489f-8c5d-b74e0ce50752@github.com>

On Tue, 5 Aug 2025 17:56:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) is not working as expected since the first CheckWorkItem is processed before LabelerWorkItem. Therefore, the logic I added in [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) won't stop the bot from adding "rfr" label in the firstCheckWorkItem.
> 
> Currently, If a pr is not associated with any component, the bot will
> 1. Add "rfr" label in the first CheckWorkItem
> 2. Execute the LabelerWorkItem
> 3. In the next CheckWorkItem, it will remove the "rfr" label
> 
> This will cause a race between mlbridgeBot and prBot.

This pull request has now been integrated.

Changeset: 44525446
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/44525446bd352876b031fced51048295e5d8b1a4
Stats:     35 lines in 5 files changed: 21 ins; 0 del; 14 mod

2552: Followup of SKARA-2408

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Wed Aug  6 21:40:52 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Aug 2025 21:40:52 GMT
Subject: RFR: 2556: LablerWorkItem adds unnecessary overhead when the bot
 restarts
Message-ID: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>

In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.

Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.

Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.

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

Commit messages:
 - update
 - update
 - SKARA-2556

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

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

From erikj at openjdk.org  Wed Aug  6 21:41:24 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 21:41:24 GMT
Subject: RFR: 2552: Followup of SKARA-2408
In-Reply-To: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
References: <RgmJST9VzcwcwFJVinhf0CLk2B7EzH45P2iiBLIvQbY=.47aad42c-d8f1-4178-8c11-9d9747c4ce2e@github.com>
Message-ID: <rmZh95DFAkke38RYGQDPUnId1yO4Nz5w0Ttb90yRvLs=.335fb62b-c3e6-4ade-84dc-bb8b9ab2540c@github.com>

On Tue, 5 Aug 2025 17:56:43 GMT, Zhao Song <zsong at openjdk.org> wrote:

> [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) is not working as expected since the first CheckWorkItem is processed before LabelerWorkItem. Therefore, the logic I added in [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) won't stop the bot from adding "rfr" label in the firstCheckWorkItem.
> 
> Currently, If a pr is not associated with any component, the bot will
> 1. Add "rfr" label in the first CheckWorkItem
> 2. Execute the LabelerWorkItem
> 3. In the next CheckWorkItem, it will remove the "rfr" label
> 
> This will cause a race between mlbridgeBot and prBot.

I saw your comment elsewhere that this had a big performance impact. Added some suggestions to alleviate that.

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

> 123:         if (bot.labelConfiguration().allowed().isEmpty()) {
> 124:             bot.setAutoLabelled(pr);
> 125:             return List.of(CheckWorkItem.fromWorkItemWithForceUpdate(bot, prId, errorHandler, triggerUpdatedAt));

We shouldn't need to rerun CheckWorkItem here.

bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 136:

> 134:         if (manuallyAdded.size() > 0 || manuallyRemoved.size() > 0) {
> 135:             bot.setAutoLabelled(pr);
> 136:             return List.of(CheckWorkItem.fromWorkItemWithForceUpdate(bot, prId, errorHandler, triggerUpdatedAt));

For the rest of these, they are only needed if the PR doesn't have `rfr` I think.

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

PR Review: https://git.openjdk.org/skara/pull/1728#pullrequestreview-3094394293
PR Review Comment: https://git.openjdk.org/skara/pull/1728#discussion_r2258368581
PR Review Comment: https://git.openjdk.org/skara/pull/1728#discussion_r2258375062

From erikj at openjdk.org  Wed Aug  6 21:47:13 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 21:47:13 GMT
Subject: RFR: 2556: LablerWorkItem adds unnecessary overhead when the bot
 restarts
In-Reply-To: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
References: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
Message-ID: <BSuuPcTUbtqNFJ_MBU7FnJAH9iw6oF2mVqNMpCgci94=.ffb76e4e-b566-48a3-829c-9505c6b1ae55@github.com>

On Wed, 6 Aug 2025 21:11:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.
> 
> Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.
> 
> Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.

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

> 123: 
> 124:         if (bot.isAutoLabelled(pr) || pr.isClosed()) {
> 125:             return List.of();

Having this check is good, but I think we should also check `!pr.isClosed()` before even creating a `LablerWorkItem` in `PullRequestCommandWorkItem`. That should help alleviate even more startup congestion.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1729#discussion_r2258385903

From zsong at openjdk.org  Wed Aug  6 22:04:36 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 6 Aug 2025 22:04:36 GMT
Subject: RFR: 2556: LablerWorkItem adds unnecessary overhead when the bot
 restarts [v2]
In-Reply-To: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
References: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
Message-ID: <h7pNCPXtuCB4wIZZfGpqpWFM8hx80yM19tj1k_-wXRE=.657cadb2-95d1-4498-94cc-63229785ad3e@github.com>

> In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.
> 
> Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.
> 
> Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.

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/1729/files
  - new: https://git.openjdk.org/skara/pull/1729/files/7d4aa190..072997bf

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

  Stats: 18 lines in 2 files changed: 9 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/skara/pull/1729.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1729/head:pull/1729

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

From erikj at openjdk.org  Wed Aug  6 22:49:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 6 Aug 2025 22:49:17 GMT
Subject: RFR: 2556: LablerWorkItem adds unnecessary overhead when the bot
 restarts [v2]
In-Reply-To: <h7pNCPXtuCB4wIZZfGpqpWFM8hx80yM19tj1k_-wXRE=.657cadb2-95d1-4498-94cc-63229785ad3e@github.com>
References: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
 <h7pNCPXtuCB4wIZZfGpqpWFM8hx80yM19tj1k_-wXRE=.657cadb2-95d1-4498-94cc-63229785ad3e@github.com>
Message-ID: <V49PYeN_7_zAv2OyirvgwLi-WqbLK8RGmSRuJyWgIfo=.d6c70af0-cf44-40d3-9330-7c70eebc24d1@github.com>

On Wed, 6 Aug 2025 22:04:36 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.
>> 
>> Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.
>> 
>> Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.
>
> 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/1729#pullrequestreview-3094529379

From zsong at openjdk.org  Thu Aug  7 16:17:25 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Aug 2025 16:17:25 GMT
Subject: RFR: 2556: LablerWorkItem adds unnecessary overhead when the bot
 restarts [v2]
In-Reply-To: <h7pNCPXtuCB4wIZZfGpqpWFM8hx80yM19tj1k_-wXRE=.657cadb2-95d1-4498-94cc-63229785ad3e@github.com>
References: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
 <h7pNCPXtuCB4wIZZfGpqpWFM8hx80yM19tj1k_-wXRE=.657cadb2-95d1-4498-94cc-63229785ad3e@github.com>
Message-ID: <11TzFnDivfZrCXZtf4bNK3FfX1F0buAugSQBbR4Bjrc=.2b83f865-b370-4c0d-99a3-13a40056c810@github.com>

On Wed, 6 Aug 2025 22:04:36 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.
>> 
>> Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.
>> 
>> Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1729#issuecomment-3164886662

From zsong at openjdk.org  Thu Aug  7 16:17:26 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Aug 2025 16:17:26 GMT
Subject: Integrated: 2556: LablerWorkItem adds unnecessary overhead when the
 bot restarts
In-Reply-To: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
References: <NuSREi1jGbbvk-EdqK1gcH2MVanZIOuAKmYoRQjXr78=.e636ffc5-1bce-4748-8b1f-a2a5e6ce6a2e@github.com>
Message-ID: <CPuYyH_O48BanzDLrQG5gVQj7AMYEnv6zWGXPqRlnsg=.7fc7ae9b-c225-45d1-8751-f4bf8251fbde@github.com>

On Wed, 6 Aug 2025 21:11:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-2408](https://bugs.openjdk.org/browse/SKARA-2408) and [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), I updated the bot to do one more CheckWorkItem with force update after a pr is marked as auto labeled.
> 
> Currently, when the pr bot restarts, the bot would schedule a PullRequestCommandWorkItem for every pr(including closed prs), in the end of PullRequestCommandWorkItem, a LabelerWorkItem will be scheduled for each pr as well. In the LabelerWorkItem, when it finds the bot doesn't have label configuration, the bot will mark the pr as auto labelled and schedule a CheckWorkItem with forceUpdate. This is the issue, the bot shouldn't schedule any CheckWorkItem when the bot doesn't have label configuration. Otherwise, the bot would re-evaluate all the prs with forceUpdate.
> 
> Also, if the pr is already closed, the LabelerWorkItem shouldn't schedule any CheckWorkItem for it.

This pull request has now been integrated.

Changeset: becf9411
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/becf941128bca39facba3e30723f031f700f8ab6
Stats:     15 lines in 2 files changed: 8 ins; 0 del; 7 mod

2556: LablerWorkItem adds unnecessary overhead when the bot restarts

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Thu Aug  7 21:24:37 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Aug 2025 21:24:37 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues
Message-ID: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>

This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

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

Commit messages:
 - SKARA-2557

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

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

From erikj at openjdk.org  Thu Aug  7 21:34:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 7 Aug 2025 21:34:57 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues
In-Reply-To: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
Message-ID: <-3zGRkDSpzfhmsInoUXnXJyXEZnBBvqefuBX5vYSJQo=.28966ccd-2ee6-490e-bd97-62e7de6d4c5d@github.com>

On Thu, 7 Aug 2025 21:18:52 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

I think this change warrants a new manual integration test.

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

> 244:                 .put("transition", JSON.object()
> 245:                         .put("id", id));
> 246:         if (state.equals("RESOLVED")) {

This method is called with `"Resolved"` not `"RESOLVED"`. To avoid relying on string comparisons here, could we make all the calls to this method use constants, or perhaps even an internal enum?

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

PR Review: https://git.openjdk.org/skara/pull/1730#pullrequestreview-3098792848
PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2261449607

From zsong at openjdk.org  Thu Aug  7 21:44:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Aug 2025 21:44:19 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues
In-Reply-To: <-3zGRkDSpzfhmsInoUXnXJyXEZnBBvqefuBX5vYSJQo=.28966ccd-2ee6-490e-bd97-62e7de6d4c5d@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <-3zGRkDSpzfhmsInoUXnXJyXEZnBBvqefuBX5vYSJQo=.28966ccd-2ee6-490e-bd97-62e7de6d4c5d@github.com>
Message-ID: <OwCdng33T9DZdYemObLH_aWPoVDtJwg7TCVrYBID7yY=.6015cc42-cb86-4dc6-af62-531dfb45fbcc@github.com>

On Thu, 7 Aug 2025 21:32:53 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think this change warrants a new manual integration test.

I did it but didn't commit the change, will do.

> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 246:
> 
>> 244:                 .put("transition", JSON.object()
>> 245:                         .put("id", id));
>> 246:         if (state.equals("RESOLVED")) {
> 
> This method is called with `"Resolved"` not `"RESOLVED"`. To avoid relying on string comparisons here, could we make all the calls to this method use constants, or perhaps even an internal enum?

Sure

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

PR Comment: https://git.openjdk.org/skara/pull/1730#issuecomment-3165847337
PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2261475102

From zsong at openjdk.org  Thu Aug  7 21:58:34 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 7 Aug 2025 21:58:34 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v2]
In-Reply-To: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
Message-ID: <N5gQZ-AuXph_wmvF_ph8eDR31Dw0qbNp9lVwTXLHJRQ=.ac7de56c-f154-4a34-afbe-7b3d19e3dd5d@github.com>

> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

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/1730/files
  - new: https://git.openjdk.org/skara/pull/1730/files/1b444e02..0c5a5c79

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

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

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

From zsong at openjdk.org  Fri Aug  8 17:24:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 8 Aug 2025 17:24:19 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
Message-ID: <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>

> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

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

 - update
 - rename method

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1730/files
  - new: https://git.openjdk.org/skara/pull/1730/files/0c5a5c79..c4e635fb

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

  Stats: 32 lines in 3 files changed: 7 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/skara/pull/1730.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1730/head:pull/1730

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

From erikj at openjdk.org  Fri Aug  8 17:24:19 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 8 Aug 2025 17:24:19 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
Message-ID: <Rfi3ged3arHi9vBHh2TaC3HlHwpgR43BUR9F7FWdp48=.431cc9b3-36d6-4e22-9a8d-fde0950a72bc@github.com>

On Fri, 8 Aug 2025 17:21:29 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - rename method

issuetracker/src/main/java/org/openjdk/skara/issuetracker/Issue.java line 126:

> 124:             String name = name().toLowerCase();
> 125:             return name.substring(0, 1).toUpperCase() + name.substring(1);
> 126:         }

The string representation for Jira should probably be handled as a Jira specific thing. I don't think we should pollute the general IssueTracker implementation with Jira specifics. My intention was to create a new enum or set of constants within the Jira package.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2263044412

From zsong at openjdk.org  Fri Aug  8 17:24:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 8 Aug 2025 17:24:19 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <Rfi3ged3arHi9vBHh2TaC3HlHwpgR43BUR9F7FWdp48=.431cc9b3-36d6-4e22-9a8d-fde0950a72bc@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
 <Rfi3ged3arHi9vBHh2TaC3HlHwpgR43BUR9F7FWdp48=.431cc9b3-36d6-4e22-9a8d-fde0950a72bc@github.com>
Message-ID: <1w_SwgNTLWVv7GFQaiPKf9empIs6zKP7VPVLuHWUJ0c=.2ec88448-1c20-4f04-badc-314a94e3d193@github.com>

On Fri, 8 Aug 2025 13:51:46 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - rename method
>
> issuetracker/src/main/java/org/openjdk/skara/issuetracker/Issue.java line 126:
> 
>> 124:             String name = name().toLowerCase();
>> 125:             return name.substring(0, 1).toUpperCase() + name.substring(1);
>> 126:         }
> 
> The string representation for Jira should probably be handled as a Jira specific thing. I don't think we should pollute the general IssueTracker implementation with Jira specifics. My intention was to create a new enum or set of constants within the Jira package.

Will fix it, thanks!

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2263450445

From zsong at openjdk.org  Mon Aug 11 23:08:07 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 11 Aug 2025 23:08:07 GMT
Subject: RFR: 2562: Disable backport command in open pull requests until Github
 allows the bot to create labels
Message-ID: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>

In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot was enhanced to support backport pull request command, but with the implementation, the bot needs to add a customized label to the pull request. Recently, Github did some changes and it no longer allows the bot to create new labels. I need to disable this feature until Github allows the bot to create new labels again.

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

Commit messages:
 - SKARA-2562

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

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

From erikj at openjdk.org  Tue Aug 12 20:01:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 12 Aug 2025 20:01:39 GMT
Subject: RFR: 2562: Disable backport command in open pull requests until
 Github allows the bot to create labels
In-Reply-To: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
References: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
Message-ID: <9EfTXHSu0foLSq4OfkS4Nutz8enwdDZbyG5N5SmMpmw=.1ca4f7a1-2190-4cf5-9d59-4e317a7f869b@github.com>

On Mon, 11 Aug 2025 23:04:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot was enhanced to support backport pull request command, but with the implementation, the bot needs to add a customized label to the pull request. Recently, Github did some changes and it no longer allows the bot to create new labels. I need to disable this feature until Github allows the bot to create new labels again.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1731#pullrequestreview-3112576990

From kcr at openjdk.org  Tue Aug 12 22:17:58 2025
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 12 Aug 2025 22:17:58 GMT
Subject: RFR: 2562: Disable backport command in open pull requests until
 Github allows the bot to create labels
In-Reply-To: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
References: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
Message-ID: <JFfP3axXDBupnsrtPUWgJjYtJGrYHvT_u7v7d1zUk9U=.686cf8c4-7247-4ccc-aaee-bcd3ad8a1ddd@github.com>

On Mon, 11 Aug 2025 23:04:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot was enhanced to support backport pull request command, but with the implementation, the bot needs to add a customized label to the pull request. Recently, Github did some changes and it no longer allows the bot to create new labels. I need to disable this feature until Github allows the bot to create new labels again.

@zhaosongzs As discussed offline, this might no longer be needed. Please check and let me know.

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

PR Comment: https://git.openjdk.org/skara/pull/1731#issuecomment-3181193739

From zsong at openjdk.org  Wed Aug 13 17:52:31 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 13 Aug 2025 17:52:31 GMT
Subject: RFR: 2562: Disable backport command in open pull requests until
 Github allows the bot to create labels
In-Reply-To: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
References: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
Message-ID: <mJAG36xGsvaGjIEYgBg_hFg_igUCv-XSIbdtisNg3H4=.be4f7596-edef-473d-b38b-6759d6407f6d@github.com>

On Mon, 11 Aug 2025 23:04:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot was enhanced to support backport pull request command, but with the implementation, the bot needs to add a customized label to the pull request. Recently, Github did some changes and it no longer allows the bot to create new labels. I need to disable this feature until Github allows the bot to create new labels again.

I have verified that the issue has been resolved and the bot can create new labels.

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

PR Comment: https://git.openjdk.org/skara/pull/1731#issuecomment-3184888253

From zsong at openjdk.org  Wed Aug 13 17:52:31 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 13 Aug 2025 17:52:31 GMT
Subject: Withdrawn: 2562: Disable backport command in open pull requests until
 Github allows the bot to create labels
In-Reply-To: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
References: <aexG_GS8JXk8wgUnWw1YblpFyJTeBn25MnEYkU4QIhQ=.315fd922-156d-4779-bf9d-acfff8a818c4@github.com>
Message-ID: <ghFoYlTmkvk-UnjzK6Cd4dGN032Yid2A9Cfld6Awx0Q=.7eaab807-a0ef-4a69-a098-de914e37e25d@github.com>

On Mon, 11 Aug 2025 23:04:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-1797](https://bugs.openjdk.org/browse/SKARA-1797), the bot was enhanced to support backport pull request command, but with the implementation, the bot needs to add a customized label to the pull request. Recently, Github did some changes and it no longer allows the bot to create new labels. I need to disable this feature until Github allows the bot to create new labels again.

This pull request has been closed without being integrated.

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

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

From erikj at openjdk.org  Fri Aug 15 17:35:37 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 17:35:37 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
Message-ID: <qV1z66K5N1OmEtnXNYtG-CD1KhAAVrZefvTYfZjP2QI=.283e6410-3482-40bc-ac4b-8fc3bdeea2db@github.com>

On Fri, 8 Aug 2025 17:24:19 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.
>
> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update
>  - rename method

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

> 246: 
> 247:     private void performTransition(JiraIssueState state) {
> 248:         var id = availableTransitions.get(state.name());

I think either get both state and transition id as parameters, or supply the availableTransitions map as a parameter. I don't think we should store it as a field.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2279555712

From zsong at openjdk.org  Fri Aug 15 17:40:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 15 Aug 2025 17:40:15 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <qV1z66K5N1OmEtnXNYtG-CD1KhAAVrZefvTYfZjP2QI=.283e6410-3482-40bc-ac4b-8fc3bdeea2db@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
 <qV1z66K5N1OmEtnXNYtG-CD1KhAAVrZefvTYfZjP2QI=.283e6410-3482-40bc-ac4b-8fc3bdeea2db@github.com>
Message-ID: <3Ci3qtpjWdKI5xYZS2OJb5el6yOtb8VUkercfkcw_BQ=.bce14740-dc8b-44f6-84ac-061e8aed9606@github.com>

On Fri, 15 Aug 2025 17:32:31 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update
>>  - rename method
>
> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 248:
> 
>> 246: 
>> 247:     private void performTransition(JiraIssueState state) {
>> 248:         var id = availableTransitions.get(state.name());
> 
> I think either get both state and transition id as parameters, or supply the availableTransitions map as a parameter. I don't think we should store it as a field.

Is there any reason that we can't store it as field?

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2279563546

From erikj at openjdk.org  Fri Aug 15 19:49:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 19:49:39 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <3Ci3qtpjWdKI5xYZS2OJb5el6yOtb8VUkercfkcw_BQ=.bce14740-dc8b-44f6-84ac-061e8aed9606@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
 <qV1z66K5N1OmEtnXNYtG-CD1KhAAVrZefvTYfZjP2QI=.283e6410-3482-40bc-ac4b-8fc3bdeea2db@github.com>
 <3Ci3qtpjWdKI5xYZS2OJb5el6yOtb8VUkercfkcw_BQ=.bce14740-dc8b-44f6-84ac-061e8aed9606@github.com>
Message-ID: <g8dDcBj4S6-IBZdJp88i4MqZmSMaMvx_3COVTMwwY6s=.08c109a3-45b9-47cf-b2ca-fcd6775f3c7b@github.com>

On Fri, 15 Aug 2025 17:37:41 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 248:
>> 
>>> 246: 
>>> 247:     private void performTransition(JiraIssueState state) {
>>> 248:         var id = availableTransitions.get(state.name());
>> 
>> I think either get both state and transition id as parameters, or supply the availableTransitions map as a parameter. I don't think we should store it as a field.
>
> Is there any reason that we can't store it as field?

I agree that in this particular case, a field would work fine, but in general it's a more brittle solution that I would like to avoid when possible. Storing state in an object creates potential opportunities for races, and forces you to have to think about side effects when calling a method that modifies fields.

In this case it could be argued that the field just acts like a cache, but there aren't enough opportunities for hitting the cache that couldn't easily be solved without a field (since the only user would be a private method that is only called from one other method anyway). If we wanted to cache this value, I would be more comfortable if there was a method to call that handled the caching mechanism in a single place. Something like `availableTransitions(boolean useCachedValue)`, but as I said, I think it's overkill here.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2279765811

From zsong at openjdk.org  Fri Aug 15 19:58:53 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 15 Aug 2025 19:58:53 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v3]
In-Reply-To: <g8dDcBj4S6-IBZdJp88i4MqZmSMaMvx_3COVTMwwY6s=.08c109a3-45b9-47cf-b2ca-fcd6775f3c7b@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <tHntzIXdt0fampffDXcyKWWR6EhjZnszPIsMmj72mmw=.60aa8a61-cf69-4128-a022-d4b3e34163c6@github.com>
 <qV1z66K5N1OmEtnXNYtG-CD1KhAAVrZefvTYfZjP2QI=.283e6410-3482-40bc-ac4b-8fc3bdeea2db@github.com>
 <3Ci3qtpjWdKI5xYZS2OJb5el6yOtb8VUkercfkcw_BQ=.bce14740-dc8b-44f6-84ac-061e8aed9606@github.com>
 <g8dDcBj4S6-IBZdJp88i4MqZmSMaMvx_3COVTMwwY6s=.08c109a3-45b9-47cf-b2ca-fcd6775f3c7b@github.com>
Message-ID: <kYEt1R3ygYhAbfkhAp0usFeRpOjVBBdQmJQE_TeWB90=.bc5206d1-7e83-4dd5-adfc-4df066ecb06a@github.com>

On Fri, 15 Aug 2025 19:47:20 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Is there any reason that we can't store it as field?
>
> I agree that in this particular case, a field would work fine, but in general it's a more brittle solution that I would like to avoid when possible. Storing state in an object creates potential opportunities for races, and forces you to have to think about side effects when calling a method that modifies fields.
> 
> In this case it could be argued that the field just acts like a cache, but there aren't enough opportunities for hitting the cache that couldn't easily be solved without a field (since the only user would be a private method that is only called from one other method anyway). If we wanted to cache this value, I would be more comfortable if there was a method to call that handled the caching mechanism in a single place. Something like `availableTransitions(boolean useCachedValue)`, but as I said, I think it's overkill here.

Makes sense to me, Thanks for the explanation. Will change it

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

PR Review Comment: https://git.openjdk.org/skara/pull/1730#discussion_r2279783195

From zsong at openjdk.org  Fri Aug 15 20:53:29 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 15 Aug 2025 20:53:29 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v4]
In-Reply-To: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
Message-ID: <m5OyVO2G1dr-TXT6nux0-DggJDUr7NMho1GN3Bpvqwc=.63cc7276-0f98-4f69-b29f-abae61a77dcc@github.com>

> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

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/1730/files
  - new: https://git.openjdk.org/skara/pull/1730/files/c4e635fb..0cdbae3c

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

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

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

From erikj at openjdk.org  Fri Aug 15 23:12:05 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 15 Aug 2025 23:12:05 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v4]
In-Reply-To: <m5OyVO2G1dr-TXT6nux0-DggJDUr7NMho1GN3Bpvqwc=.63cc7276-0f98-4f69-b29f-abae61a77dcc@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <m5OyVO2G1dr-TXT6nux0-DggJDUr7NMho1GN3Bpvqwc=.63cc7276-0f98-4f69-b29f-abae61a77dcc@github.com>
Message-ID: <AdqmrGZS0Xf3448GHFZpNlnVHq4c-OBwJk0rypCSeko=.d3cb6b56-91e1-4461-b079-9c7d539328be@github.com>

On Fri, 15 Aug 2025 20:53:29 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.
>
> 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/1730#pullrequestreview-3125330973

From zsong at openjdk.org  Mon Aug 18 17:57:13 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 18 Aug 2025 17:57:13 GMT
Subject: RFR: 2557: Set resolution to Fixed when resolving Jira issues [v4]
In-Reply-To: <m5OyVO2G1dr-TXT6nux0-DggJDUr7NMho1GN3Bpvqwc=.63cc7276-0f98-4f69-b29f-abae61a77dcc@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
 <m5OyVO2G1dr-TXT6nux0-DggJDUr7NMho1GN3Bpvqwc=.63cc7276-0f98-4f69-b29f-abae61a77dcc@github.com>
Message-ID: <K_yWyCsYEyOEFM7AZf2uGLAsB7O7rbmlAYRGSJ3q48E=.02c8de3f-bd50-429b-ac9b-5e88f2038a73@github.com>

On Fri, 15 Aug 2025 20:53:29 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thank you for the review and all the suggestions!

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

PR Comment: https://git.openjdk.org/skara/pull/1730#issuecomment-3197883604

From zsong at openjdk.org  Mon Aug 18 17:57:13 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 18 Aug 2025 17:57:13 GMT
Subject: Integrated: 2557: Set resolution to Fixed when resolving Jira issues
In-Reply-To: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
References: <_z1bhc_wS6eSEyAVILrcpnYvZD4-WRs4DEwAx7LaE54=.583b81d2-cda9-493b-9b2b-4055d8d4db7c@github.com>
Message-ID: <IcBouvMHuBwKPaJCz4juYogSyM0pBu2jabQJStM85us=.67447310-9f67-45b3-9bfa-55c2e3a902d5@github.com>

On Thu, 7 Aug 2025 21:18:52 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to let Skara  bot  explicitly set resolution to "Fixed" when resolving Jira issues.

This pull request has now been integrated.

Changeset: 18f9851d
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/18f9851d5d45ce75d100f56277ac826a17ae66ed
Stats:     48 lines in 2 files changed: 26 ins; 3 del; 19 mod

2557: Set resolution to Fixed when resolving Jira issues

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Thu Aug 21 04:23:44 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Aug 2025 04:23:44 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label
Message-ID: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>

I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label

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

Commit messages:
 - update
 - SKARA-2566

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

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

From erikj at openjdk.org  Thu Aug 21 13:08:25 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Aug 2025 13:08:25 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label
In-Reply-To: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
Message-ID: <Oo5QgOP307uhEZ6BM9Mn6-3_6lIlaQCS46eZRqu7mL4=.80c3f03b-fdc7-43e2-a330-8a48af2580d5@github.com>

On Wed, 20 Aug 2025 22:41:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label

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

> 477:         if (rfrPendingOnOtherWorkItems) {
> 478:             log.info("rfr is pending on other workItems for pr: " + pr.id());
> 479:             return newLabels.contains("rfr");

I think there is still a case that needs to be fixed here. If `visitor.isReadyForReview()` returns false, we still want to remove `rfr` even if we are waiting on other work items. Or am I missing something?

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

PR Review Comment: https://git.openjdk.org/skara/pull/1732#discussion_r2291005747

From zsong at openjdk.org  Thu Aug 21 15:37:59 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Aug 2025 15:37:59 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label
In-Reply-To: <Oo5QgOP307uhEZ6BM9Mn6-3_6lIlaQCS46eZRqu7mL4=.80c3f03b-fdc7-43e2-a330-8a48af2580d5@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
 <Oo5QgOP307uhEZ6BM9Mn6-3_6lIlaQCS46eZRqu7mL4=.80c3f03b-fdc7-43e2-a330-8a48af2580d5@github.com>
Message-ID: <G04ksy011d8NlzSe_f4HsLvpf5AQikurbom7S6cV88M=.21baebb9-900e-4fd6-9604-40ae5b79f30c@github.com>

On Thu, 21 Aug 2025 13:06:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 479:
> 
>> 477:         if (rfrPendingOnOtherWorkItems) {
>> 478:             log.info("rfr is pending on other workItems for pr: " + pr.id());
>> 479:             return newLabels.contains("rfr");
> 
> I think there is still a case that needs to be fixed here. If `visitor.isReadyForReview()` returns false, we still want to remove `rfr` even if we are waiting on other work items. Or am I missing something?

You are right. I was just thinking that the bot will remove the rfr label in the next CheckWorkItem, so no bother to remove it early... Now I think it's better to make it consistent with other cases

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

PR Review Comment: https://git.openjdk.org/skara/pull/1732#discussion_r2291439223

From zsong at openjdk.org  Thu Aug 21 16:39:31 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Aug 2025 16:39:31 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label [v2]
In-Reply-To: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
Message-ID: <ctbz7WGOdimzcUZj9YEiFCUNGIP1Kxnju03BftIV-vE=.fec90047-8978-402a-9c3f-06d348110f35@github.com>

> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label

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/1732/files
  - new: https://git.openjdk.org/skara/pull/1732/files/4a79551e..8fb650d8

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

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

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

From erikj at openjdk.org  Thu Aug 21 17:48:20 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 21 Aug 2025 17:48:20 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label [v2]
In-Reply-To: <ctbz7WGOdimzcUZj9YEiFCUNGIP1Kxnju03BftIV-vE=.fec90047-8978-402a-9c3f-06d348110f35@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
 <ctbz7WGOdimzcUZj9YEiFCUNGIP1Kxnju03BftIV-vE=.fec90047-8978-402a-9c3f-06d348110f35@github.com>
Message-ID: <6DTQ3eUyqfrlvRhmf08qLNnrLhaylgnzoH463OF_E4Y=.938d5796-779f-4ec6-a8d0-b417b28e971a@github.com>

On Thu, 21 Aug 2025 16:39:31 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label
>
> 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/1732#pullrequestreview-3141728351

From zsong at openjdk.org  Thu Aug 21 18:01:39 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Aug 2025 18:01:39 GMT
Subject: RFR: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label [v2]
In-Reply-To: <ctbz7WGOdimzcUZj9YEiFCUNGIP1Kxnju03BftIV-vE=.fec90047-8978-402a-9c3f-06d348110f35@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
 <ctbz7WGOdimzcUZj9YEiFCUNGIP1Kxnju03BftIV-vE=.fec90047-8978-402a-9c3f-06d348110f35@github.com>
Message-ID: <FEgKaOn0LFj-01h8icxHP3k5UYj_DG_h31IytoIQhs4=.9bf5917a-003d-4567-9216-74ee65a00f60@github.com>

On Thu, 21 Aug 2025 16:39:31 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thanks!

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

PR Comment: https://git.openjdk.org/skara/pull/1732#issuecomment-3211577608

From zsong at openjdk.org  Thu Aug 21 18:01:39 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 21 Aug 2025 18:01:39 GMT
Subject: Integrated: 2566: When rfr is pending on other workItems,
 the pr bot shouldn't actively remove the label
In-Reply-To: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
References: <cBSi6a0A4y5IABoDYX6odqLGX3AIbMzrxroapCByUAg=.db174ce2-0e15-4166-ad3d-bde29d278ca9@github.com>
Message-ID: <iFNxEgArViDZphDGERrciqw2Inr2tJCy10RxGH4YMgQ=.0b1b1a5d-5796-45ba-a969-0ab7f99586e5@github.com>

On Wed, 20 Aug 2025 22:41:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

> I restarted the pr bot today and a user reported that the pr bot removed 'rfr' label on a pull request. It's the side effect of [SKARA-2552](https://bugs.openjdk.org/browse/SKARA-2552), when the bot was evaluating the pull request, the labelerWorkItem wasn't done, so rfrPendingOnOtherWorkItems was set to true. In this case, the bot should just not add 'rfr' label, but not actively remove the 'rfr' label

This pull request has now been integrated.

Changeset: e290f157
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/e290f1579705b32c87d4e98430f5b517fa15a6c3
Stats:     21 lines in 1 file changed: 10 ins; 10 del; 1 mod

2566: When rfr is pending on other workItems, the pr bot shouldn't actively remove the label

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Fri Aug 22 17:25:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Aug 2025 17:25:15 GMT
Subject: RFR: 2563: NPE when reviewers id changed due to census update
Message-ID: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>

When Skara Bot processes the backport command, it attempts to parse reviewers IDs from the original commit message. It then looks up these reviewers IDs in the current repository census to get the reviewers' full names, and then put the full names in the pull request description for backport.

A corner case may occur if the repository census is updated between the original commit and the backport creation. In this case, the reviewer ID in the original commit may be from a previous census, but later the bot could lookup the ID in the updated census. If the reviewer ID is no longer present in the updated census, this can result in a NPE.

We should fallback to use the id instead of full name.

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

Commit messages:
 - SKARA-2563

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

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

From erikj at openjdk.org  Fri Aug 22 18:13:39 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Aug 2025 18:13:39 GMT
Subject: RFR: 2563: NPE when reviewers id changed due to census update
In-Reply-To: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
References: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
Message-ID: <w-8ZWSkJjsxoLLuA8hdvoWCK1pZLvFrV4oVInZbsi-s=.0732d75f-3cb4-4600-91bc-4e850b0a0e5b@github.com>

On Fri, 22 Aug 2025 17:19:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When Skara Bot processes the backport command, it attempts to parse reviewers IDs from the original commit message. It then looks up these reviewers IDs in the current repository census to get the reviewers' full names, and then put the full names in the pull request description for backport.
> 
> A corner case may occur if the repository census is updated between the original commit and the backport creation. In this case, the reviewer ID in the original commit may be from a previous census, but later the bot could lookup the ID in the updated census. If the reviewer ID is no longer present in the updated census, this can result in a NPE.
> 
> We should fallback to use the id instead of full name.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1733#pullrequestreview-3145409852

From zsong at openjdk.org  Fri Aug 22 18:41:48 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Aug 2025 18:41:48 GMT
Subject: RFR: 2563: NPE when reviewers id changed due to census update
In-Reply-To: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
References: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
Message-ID: <A303HvJJSdh0S_Fc2f-1V7RnHjaCpIE3HibpplREw0I=.4e98e16b-8fc8-4aca-83be-b0def2e78b07@github.com>

On Fri, 22 Aug 2025 17:19:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When Skara Bot processes the backport command, it attempts to parse reviewers IDs from the original commit message. It then looks up these reviewers IDs in the current repository census to get the reviewers' full names, and then put the full names in the pull request description for backport.
> 
> A corner case may occur if the repository census is updated between the original commit and the backport creation. In this case, the reviewer ID in the original commit may be from a previous census, but later the bot could lookup the ID in the updated census. If the reviewer ID is no longer present in the updated census, this can result in a NPE.
> 
> We should fallback to use the id instead of full name.

Thanks for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1733#issuecomment-3215275222

From zsong at openjdk.org  Fri Aug 22 18:41:48 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Aug 2025 18:41:48 GMT
Subject: Integrated: 2563: NPE when reviewers id changed due to census update
In-Reply-To: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
References: <2XtYLcNhut4YwvV_ULw_XYXfFBqcbgwp3Oasbyucv7Y=.5c1017b8-714a-4391-930c-ad2068b3ba68@github.com>
Message-ID: <YEahUaU_IV0fDJZSyiPuLD5KY4OiXWgZyukGUe8YQyI=.ff8a132b-2347-49d5-9c3c-6d651ebabfe0@github.com>

On Fri, 22 Aug 2025 17:19:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When Skara Bot processes the backport command, it attempts to parse reviewers IDs from the original commit message. It then looks up these reviewers IDs in the current repository census to get the reviewers' full names, and then put the full names in the pull request description for backport.
> 
> A corner case may occur if the repository census is updated between the original commit and the backport creation. In this case, the reviewer ID in the original commit may be from a previous census, but later the bot could lookup the ID in the updated census. If the reviewer ID is no longer present in the updated census, this can result in a NPE.
> 
> We should fallback to use the id instead of full name.

This pull request has now been integrated.

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

2563: NPE when reviewers id changed due to census update

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Fri Aug 22 21:28:50 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 22 Aug 2025 21:28:50 GMT
Subject: RFR: 2568: Add more loggings to investigate SKARA-2544
Message-ID: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>

To investigate [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544), add more logging in pullRequestPoller

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

Commit messages:
 - update
 - SKARA-2568

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

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

From erikj at openjdk.org  Fri Aug 22 21:56:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 22 Aug 2025 21:56:07 GMT
Subject: RFR: 2568: Add more loggings to investigate SKARA-2544
In-Reply-To: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
References: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
Message-ID: <_WcInt9Ggbe1rR1k4WjUAVxpQtgCLJUG61WswZlqk8A=.7299cf00-2df8-4706-9141-956157ec41e4@github.com>

On Fri, 22 Aug 2025 21:23:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> To investigate [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544), add more logging in pullRequestPoller

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1734#pullrequestreview-3146294077

From zsong at openjdk.org  Mon Aug 25 16:05:08 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Aug 2025 16:05:08 GMT
Subject: RFR: 2568: Add more loggings to investigate SKARA-2544
In-Reply-To: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
References: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
Message-ID: <p5vVxp7oK4fWpGolCuPvqL1D-AxduBhqKy0WeR7IznY=.26e48b4c-4d67-4e8c-9548-6916583d2c83@github.com>

On Fri, 22 Aug 2025 21:23:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> To investigate [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544), add more logging in pullRequestPoller

Thank you for the review!

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

PR Comment: https://git.openjdk.org/skara/pull/1734#issuecomment-3220848089

From zsong at openjdk.org  Mon Aug 25 16:05:08 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 25 Aug 2025 16:05:08 GMT
Subject: Integrated: 2568: Add more loggings to investigate SKARA-2544
In-Reply-To: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
References: <5OPy61wbl-xCGCO5D2jrFVQbDCikEOVfjC6igl1OLZQ=.67b5d21c-4caa-49b9-9795-d25b0fdfb3fb@github.com>
Message-ID: <Pkxn9tAPFNKsKEwKmUCssbhWxEvXGJX-h7yqGATQZ84=.0d146b3e-0b40-4843-8366-923a773aa8d9@github.com>

On Fri, 22 Aug 2025 21:23:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

> To investigate [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544), add more logging in pullRequestPoller

This pull request has now been integrated.

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

2568: Add more loggings to investigate SKARA-2544

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Wed Aug 27 19:24:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Aug 2025 19:24:15 GMT
Subject: RFR: 2065: Update PR labels when new files are touched
Message-ID: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>

This patch is trying to make the pr bot be able to update PR labels when new files are touched.
The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.

Later, when the user pushes new commits to the PR, the CheckWorkItem will be responsible for updating the labels based on the diff between headHash and stored Hash. I thought about adding the logic of updating labels in LabelerWorkItem, but later I realized that it will require another round of CheckWorkItem, so I choose to let CheckWorkItem update the labels.

With this patch, here are some new behaviors of the bot:
(1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
(2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
(3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
(4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
(5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.

The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

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

Commit messages:
 - update
 - update
 - fix tests
 - update
 - Merge branch 'master' into SKARA-2065
 - update
 - update
 - test force push
 - test

Changes: https://git.openjdk.org/skara/pull/1735/files
  Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1735&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2065
  Stats: 219 lines in 7 files changed: 147 ins; 12 del; 60 mod
  Patch: https://git.openjdk.org/skara/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1735/head:pull/1735

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

From zsong at openjdk.org  Wed Aug 27 20:20:38 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Aug 2025 20:20:38 GMT
Subject: RFR: 2065: Update PR labels when new files are touched
In-Reply-To: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
Message-ID: <miaPq-qZ73QiGKrzUSfursZn9F_JYD2pOU9y89jSwBU=.91bca5aa-bdc2-4d77-b90b-793e80b34401@github.com>

On Mon, 25 Aug 2025 21:23:12 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
> 
> Later, when the user pushes new commits to the PR, the CheckWorkItem will be responsible for updating the labels based on the diff between headHash and stored Hash. I thought about adding the logic of updating labels in LabelerWorkItem, but later I realized that it will require another round of CheckWorkItem, so I choose to let CheckWorkItem update the labels.
> 
> With this patch, here are some new behaviors of the bot:
> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
> 
> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

Another thing is that for the current pull requests in openjdk/jdk, if the auto labelling was skipped, after this patch is deployed, the bot will add the comment "A manual label command was issued before auto-labeling, so auto-labeling was skipped." to the pull requests as well.

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3229622747

From erikj at openjdk.org  Wed Aug 27 20:53:32 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 27 Aug 2025 20:53:32 GMT
Subject: RFR: 2065: Update PR labels when new files are touched
In-Reply-To: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
Message-ID: <Wn8BrdGOmm-38dKor5Ad-QRaS4Sa7ukXrcpxOxjA9SU=.498d2817-83c4-49e8-9c3f-6846c013ac0f@github.com>

On Mon, 25 Aug 2025 21:23:12 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
> 
> Later, when the user pushes new commits to the PR, the CheckWorkItem will be responsible for updating the labels based on the diff between headHash and stored Hash. I thought about adding the logic of updating labels in LabelerWorkItem, but later I realized that it will require another round of CheckWorkItem, so I choose to let CheckWorkItem update the labels.
> 
> With this patch, here are some new behaviors of the bot:
> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
> 
> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

I understand wanting to optimize for performance by putting this in CheckRun, but it really comes at a cost of maintainability IMO. Having two different WorkItems share the responsibility of adding labels in different situations seems bad. We also have the race situation between labels and comment which isn't easily solved in a nice way within CheckRun. 

Are you sure we would need to spawn another CheckWorkItem after the labeler has run? I can see that it would be forced if `rfr` wasn't set yet and that it would be triggered if we actually added a label, but for most situations where nothing changed, the only thing that would happen is that a comment got updated. That comment would have the bot user as author, and those are filtered out already for the updated check, aren't they? I may be missing something.

If we do this in the LabelerWorkItem, we can more easily control the order of label changes and comment update, to avoid the risk of inconsistent states.

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

> 291:                             "(<!-- PullRequest Bot label commit ')[^']*(' -->)",
> 292:                             "$1" + pr.headHash().toString() + "$2"
> 293:                     ));

This creates a race where if the `WorkItem` is killed after updating the comment, but before applying `newLabels`, a rerun will not actually retry adding those labels.

bots/pr/src/test/java/org/openjdk/skara/bots/pr/LabelTests.java line 598:

> 596: 
> 597: 
> 598: 

That's a lot of empty lines.

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

PR Review: https://git.openjdk.org/skara/pull/1735#pullrequestreview-3161683972
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2305251911
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2305256943

From zsong at openjdk.org  Wed Aug 27 21:04:21 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 27 Aug 2025 21:04:21 GMT
Subject: RFR: 2065: Update PR labels when new files are touched
In-Reply-To: <Wn8BrdGOmm-38dKor5Ad-QRaS4Sa7ukXrcpxOxjA9SU=.498d2817-83c4-49e8-9c3f-6846c013ac0f@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <Wn8BrdGOmm-38dKor5Ad-QRaS4Sa7ukXrcpxOxjA9SU=.498d2817-83c4-49e8-9c3f-6846c013ac0f@github.com>
Message-ID: <UNrBjwyYnxk2Docok3NMcVXBl0ps6HBK4-2payOEGRA=.4f17d7a6-b211-4bdd-8a39-bee2eed698a5@github.com>

On Wed, 27 Aug 2025 20:51:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I understand wanting to optimize for performance by putting this in CheckRun, but it really comes at a cost of maintainability IMO. Having two different WorkItems share the responsibility of adding labels in different situations seems bad. We also have the race situation between labels and comment which isn't easily solved in a nice way within CheckRun.
> 
> Are you sure we would need to spawn another CheckWorkItem after the labeler has run? I can see that it would be forced if `rfr` wasn't set yet and that it would be triggered if we actually added a label, but for most situations where nothing changed, the only thing that would happen is that a comment got updated. That comment would have the bot user as author, and those are filtered out already for the updated check, aren't they? I may be missing something.
> 
> If we do this in the LabelerWorkItem, we can more easily control the order of label changes and comment update, to avoid the risk of inconsistent states.

Yeah, I was thinking the same, we need another run after the label is added, now I am agree with you, seems like it's not that expensive. I will move the logic to LabelerWorkItem. Thanks!

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3229732209

From zsong at openjdk.org  Thu Aug 28 18:15:49 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 18:15:49 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
Message-ID: <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>

> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
> 
> With this patch, here are some new behaviors of the bot:
> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
> 
> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

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

 - update
 - update
 - update
 - update
 - update
 - review comment

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/c7fc5420..bc381516

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

  Stats: 118 lines in 4 files changed: 75 ins; 31 del; 12 mod
  Patch: https://git.openjdk.org/skara/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1735/head:pull/1735

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

From erikj at openjdk.org  Thu Aug 28 21:41:30 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 28 Aug 2025 21:41:30 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
Message-ID: <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>

On Thu, 28 Aug 2025 18:15:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
>> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
>> 
>> With this patch, here are some new behaviors of the bot:
>> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
>> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
>> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
>> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
>> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
>> 
>> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.
>
> Zhao Song has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - update
>  - update
>  - update
>  - update
>  - update
>  - review comment

bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 152:

> 150:                 var seedPath = bot.seedStorage().orElse(scratchArea.getSeeds());
> 151:                 var hostedRepositoryPool = new HostedRepositoryPool(seedPath);
> 152:                 var localRepo = PullRequestUtils.materialize(hostedRepositoryPool, pr, path);

This is repeated further down, maybe worth breaking out into a method `materializeRepo`?

bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 156:

> 154:                 var labelComment = findComment(prComments(), INITIAL_LABEL_MESSAGE);
> 155: 
> 156:                 if (labelComment.isPresent()) {

If labelComment isn't present, something has gone wrong. Could we do something to try to recover or at least log it?

bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 198:

> 196: 
> 197:             if (!pr.isClosed()) {
> 198:                 return List.of(new LabelerWorkItem(bot, prId, errorHandler, triggerUpdatedAt));

At this stage in PullRequestCommandWorkItem, we have already loaded all PR comments, so I think it would be worth checking if there is any need for scheduling a LabelerWorkItem. What I mean is, we can check if the head hash of the PR is different from the last labeler commit marker. This could be implemented in a static method on `LabelereWorkItem` to keep the details in one place.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308594377
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308597665
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308592027

From zsong at openjdk.org  Thu Aug 28 21:45:58 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 21:45:58 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
Message-ID: <MHse9fOSpRxjMcY4GBPkAv_Qds5OBb2c5e1pxwFCOJ4=.afa3d2b6-e713-48c5-a052-d0e930f576bb@github.com>

On Thu, 28 Aug 2025 21:26:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update
>>  - review comment
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 198:
> 
>> 196: 
>> 197:             if (!pr.isClosed()) {
>> 198:                 return List.of(new LabelerWorkItem(bot, prId, errorHandler, triggerUpdatedAt));
> 
> At this stage in PullRequestCommandWorkItem, we have already loaded all PR comments, so I think it would be worth checking if there is any need for scheduling a LabelerWorkItem. What I mean is, we can check if the head hash of the PR is different from the last labeler commit marker. This could be implemented in a static method on `LabelereWorkItem` to keep the details in one place.

When I was working on it, I have the same thought with you, I added the check and did some tests, later I found there is a case which is that the user use the "/label" command to add the label, in this case, we need LabelerWorkItem to check whether the labels can be upgraded to group labels.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308616069

From zsong at openjdk.org  Thu Aug 28 21:49:45 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 21:49:45 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
Message-ID: <ABzdEMSjJVq8Gfg4wuzRLDIviWRiNvnRBUzw9MqV7CQ=.bdc0dadf-ae07-475c-b237-396f31add414@github.com>

On Thu, 28 Aug 2025 21:28:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - update
>>  - review comment
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 152:
> 
>> 150:                 var seedPath = bot.seedStorage().orElse(scratchArea.getSeeds());
>> 151:                 var hostedRepositoryPool = new HostedRepositoryPool(seedPath);
>> 152:                 var localRepo = PullRequestUtils.materialize(hostedRepositoryPool, pr, path);
> 
> This is repeated further down, maybe worth breaking out into a method `materializeRepo`?

Sure, will do.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308622652

From zsong at openjdk.org  Thu Aug 28 21:58:27 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 21:58:27 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v3]
In-Reply-To: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
Message-ID: <Srfvkwj9G4przlTLusDQ6xbqcVx10VxXy4u-GOxhxcI=.e5dca5c1-ef3c-4242-a849-edf033829368@github.com>

> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
> 
> With this patch, here are some new behaviors of the bot:
> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
> 
> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

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/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/bc381516..26e8e243

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

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

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

From zsong at openjdk.org  Thu Aug 28 21:58:27 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 21:58:27 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <ABzdEMSjJVq8Gfg4wuzRLDIviWRiNvnRBUzw9MqV7CQ=.bdc0dadf-ae07-475c-b237-396f31add414@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
 <ABzdEMSjJVq8Gfg4wuzRLDIviWRiNvnRBUzw9MqV7CQ=.bdc0dadf-ae07-475c-b237-396f31add414@github.com>
Message-ID: <TSqWZm5zEItcYZGnlcEJlinq7w9DXM00sQn3Rlm6yRs=.2a291b2a-4db5-475f-b942-3d2f876e4dfb@github.com>

On Thu, 28 Aug 2025 21:47:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 152:
>> 
>>> 150:                 var seedPath = bot.seedStorage().orElse(scratchArea.getSeeds());
>>> 151:                 var hostedRepositoryPool = new HostedRepositoryPool(seedPath);
>>> 152:                 var localRepo = PullRequestUtils.materialize(hostedRepositoryPool, pr, path);
>> 
>> This is repeated further down, maybe worth breaking out into a method `materializeRepo`?
>
> Sure, will do.

I found there is already a method `IntegrateCommand#materializeLocalRepo`

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308632331

From zsong at openjdk.org  Thu Aug 28 22:04:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 22:04:15 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <MHse9fOSpRxjMcY4GBPkAv_Qds5OBb2c5e1pxwFCOJ4=.afa3d2b6-e713-48c5-a052-d0e930f576bb@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
 <MHse9fOSpRxjMcY4GBPkAv_Qds5OBb2c5e1pxwFCOJ4=.afa3d2b6-e713-48c5-a052-d0e930f576bb@github.com>
Message-ID: <Z4Z4BqwJUPZhkoZj6W_5P2SQfpKEYf2_Y3cY7OdZZvM=.7b4670b5-5d49-458d-a960-94bf92a98145@github.com>

On Thu, 28 Aug 2025 21:43:46 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 198:
>> 
>>> 196: 
>>> 197:             if (!pr.isClosed()) {
>>> 198:                 return List.of(new LabelerWorkItem(bot, prId, errorHandler, triggerUpdatedAt));
>> 
>> At this stage in PullRequestCommandWorkItem, we have already loaded all PR comments, so I think it would be worth checking if there is any need for scheduling a LabelerWorkItem. What I mean is, we can check if the head hash of the PR is different from the last labeler commit marker. This could be implemented in a static method on `LabelereWorkItem` to keep the details in one place.
>
> When I was working on it, I have the same thought with you, I added the check and did some tests, later I found there is a case which is that the user use the "/label" command to add the label, in this case, we need LabelerWorkItem to check whether the labels can be upgraded to group labels.

Or there is another Option, we can add the check here. And in pullRequestWorkItem, after processing a label command, we can schedule a LabelerWorkItem

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308645445

From erikj at openjdk.org  Thu Aug 28 22:43:45 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 28 Aug 2025 22:43:45 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <Z4Z4BqwJUPZhkoZj6W_5P2SQfpKEYf2_Y3cY7OdZZvM=.7b4670b5-5d49-458d-a960-94bf92a98145@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
 <MHse9fOSpRxjMcY4GBPkAv_Qds5OBb2c5e1pxwFCOJ4=.afa3d2b6-e713-48c5-a052-d0e930f576bb@github.com>
 <Z4Z4BqwJUPZhkoZj6W_5P2SQfpKEYf2_Y3cY7OdZZvM=.7b4670b5-5d49-458d-a960-94bf92a98145@github.com>
Message-ID: <PKEfrR3JT00qYEOuN0dhSBYfnoLMLMCxT_Z1Cl-gL7I=.4a99a257-1962-4410-b570-5b780d88659c@github.com>

On Thu, 28 Aug 2025 22:02:06 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> When I was working on it, I have the same thought with you, I added the check and did some tests, later I found there is a case which is that the user use the "/label" command to add the label, in this case, we need LabelerWorkItem to check whether the labels can be upgraded to group labels.
>
> Or there is another Option, we can add the check here. And in pullRequestWorkItem, after processing a label command, we can schedule a LabelerWorkItem

Hm, that could work, but it would also mean that we need to schedule an initial LabelerWorkItem when bot is starting up, or rather, we need to let the very first one through regardless of commit hash. This is in case a LabelCommand was issued and handled right before bot was restarted. 

The alternative would be to compare dates on comments. If the label "command handled" comment has a later date than the last update of the auto labeler comment, then we need to run. If we do that, then the labeler needs to always touch the comment to mark when it was last run. Not sure which is best. If we end up spawning a lot of LabelereWorkItems, it could turn into a lot of comment updates.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308699916

From zsong at openjdk.org  Thu Aug 28 22:58:58 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 22:58:58 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v2]
In-Reply-To: <PKEfrR3JT00qYEOuN0dhSBYfnoLMLMCxT_Z1Cl-gL7I=.4a99a257-1962-4410-b570-5b780d88659c@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <YkL4rmNxSNI0HhXgrXSE8ABVxsuATNvUQ2D8itksePA=.209a79e4-7a1e-4078-a10d-1e105ea1a2a8@github.com>
 <CoUOCD0rxe3xX0dkCKZXL3KbPvGKMhk41YOd6curQSo=.ad6c28b1-02fb-4f06-bd82-f62d5d71a55c@github.com>
 <MHse9fOSpRxjMcY4GBPkAv_Qds5OBb2c5e1pxwFCOJ4=.afa3d2b6-e713-48c5-a052-d0e930f576bb@github.com>
 <Z4Z4BqwJUPZhkoZj6W_5P2SQfpKEYf2_Y3cY7OdZZvM=.7b4670b5-5d49-458d-a960-94bf92a98145@github.com>
 <PKEfrR3JT00qYEOuN0dhSBYfnoLMLMCxT_Z1Cl-gL7I=.4a99a257-1962-4410-b570-5b780d88659c@github.com>
Message-ID: <F-jPtpqvXomGSQQcLcQgESWAsvpJpNOkfVNY2FniItM=.866bf8a6-e5d9-44f0-acb6-26449225e889@github.com>

On Thu, 28 Aug 2025 22:41:34 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Or there is another Option, we can add the check here. And in pullRequestWorkItem, after processing a label command, we can schedule a LabelerWorkItem
>
> Hm, that could work, but it would also mean that we need to schedule an initial LabelerWorkItem when bot is starting up, or rather, we need to let the very first one through regardless of commit hash. This is in case a LabelCommand was issued and handled right before bot was restarted. 
> 
> The alternative would be to compare dates on comments. If the label "command handled" comment has a later date than the last update of the auto labeler comment, then we need to run. If we do that, then the labeler needs to always touch the comment to mark when it was last run. Not sure which is best. If we end up spawning a lot of LabelereWorkItems, it could turn into a lot of comment updates.

I think the first one is pretty easy, we just need to check if the pr has been marked as auto labeled or not.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2308715847

From zsong at openjdk.org  Thu Aug 28 23:04:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 28 Aug 2025 23:04:05 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
Message-ID: <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>

> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
> 
> With this patch, here are some new behaviors of the bot:
> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
> 
> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.

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/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/26e8e243..9277cf99

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

  Stats: 61 lines in 2 files changed: 32 ins; 7 del; 22 mod
  Patch: https://git.openjdk.org/skara/pull/1735.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1735/head:pull/1735

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

From ihse at openjdk.org  Fri Aug 29 07:52:29 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 29 Aug 2025 07:52:29 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
Message-ID: <Tb3JYqSrFOfId_L9AkoLoFCiixSb4TL1WAK8JkxhfUU=.765e7a22-4cbd-4e27-83c8-f4102f37e6ac@github.com>

On Thu, 28 Aug 2025 23:04:05 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
>> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
>> 
>> With this patch, here are some new behaviors of the bot:
>> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
>> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
>> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
>> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
>> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
>> 
>> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

I made some comments about this PR in the test bug https://github.com/openjdk/playground/pull/239#issuecomment-3236075737. I realized afterwards that this was kind of a stupid place to put it. :) So here it is again:

> @zhaosongzs A manual label command was issued before auto-labeling, so auto-labeling was skipped.

@zhaosongzs Oh, I'm not so sure about this... If the bots are slow or get stuck, people might give `/label` commands before the bots can do the auto labeling. I don't think that should block auto-labeling. But we could give a warning, showing the diff between the manual labeling and the autolabeling. And if there is no diff, then we can just be quiet, since that might just have been someone getting tired of waiting for the bots. Otherwise we can say like "Manual labels set `build`, `core-libs`. Automatic labelling would not have set `build`, but is keeping it due to manual label. Automatical labelling added `client-libs`, `panama`." (but slightly better phrased).

And also, just to be super clear, giving manual `/label` commands at some point, should not block the automatic label update when new files are added.

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3236084200

From erikj at openjdk.org  Fri Aug 29 13:45:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 29 Aug 2025 13:45:46 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
Message-ID: <dqcAEGUpuKwtODSYbQMxmv30e5X6AxTd1hJ4JI-VvVw=.28f1a0a4-22b3-4a32-bb2f-ca176f35cfa9@github.com>

On Thu, 28 Aug 2025 23:04:05 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
>> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
>> 
>> With this patch, here are some new behaviors of the bot:
>> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
>> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
>> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
>> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
>> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
>> 
>> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

What Magnus said got me thinking. Since we are now redoing auto labeling every time the code changes, I think the concept of having the bot class track which PRs have been auto labeled doesn't make much sense. A PR is either up to date with the labeler, or it isn't. There shouldn't be anything special about the first run really. In CheckRun, to check if the PR has been auto labeled or not, it can check for the existence of an auto label comment. In LabelerWorkItem, I think the code paths could be more unified to make it clear that there isn't a big difference.

I'm thinking that when running the LabelerWorkItem again, due to a new commit, if nothing new is found, we just silently update the commit hash in the existing (last) auto label comment. If however we find that a new label needs to be added, we may want to create a new comment to make it clearer that a new action was taken, without erasing/hiding the history of the previous comment. That would make it easier to incorporate the kind of messaging Magnus is asking for.

For the case of running LabelerWorkItem after executing a LabelCommand, just to collapse groups, I'm starting to think that it would be better to just have the LabelCommand automatically collapse groups for you. The implementation might be shared, but by having it happen through the LabelCommand, we don't need to worry about updating the auto label comments, or racing against bot restarts. In that case the LabelCommand reply would include a message of combining the groups.

I might have missed something, but these are my current thoughts.

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3237094437

From zsong at openjdk.org  Fri Aug 29 16:04:59 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Aug 2025 16:04:59 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <dqcAEGUpuKwtODSYbQMxmv30e5X6AxTd1hJ4JI-VvVw=.28f1a0a4-22b3-4a32-bb2f-ca176f35cfa9@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
 <dqcAEGUpuKwtODSYbQMxmv30e5X6AxTd1hJ4JI-VvVw=.28f1a0a4-22b3-4a32-bb2f-ca176f35cfa9@github.com>
Message-ID: <8YqK0VEid1sUg0vTmd5JlQ7pjWFQsa2D259YSqOGITM=.c900e335-e02b-4bc6-8144-0c4bb62c4382@github.com>

On Fri, 29 Aug 2025 13:43:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> What Magnus said got me thinking. Since we are now redoing auto labeling every time the code changes, I think the concept of having the bot class track which PRs have been auto labeled doesn't make much sense. A PR is either up to date with the labeler, or it isn't. There shouldn't be anything special about the first run really. In CheckRun, to check if the PR has been auto labeled or not, it can check for the existence of an auto label comment. In LabelerWorkItem, I think the code paths could be more unified to make it clear that there isn't a big difference.
> 
> I'm thinking that when running the LabelerWorkItem again, due to a new commit, if nothing new is found, we just silently update the commit hash in the existing (last) auto label comment. If however we find that a new label needs to be added, we may want to create a new comment to make it clearer that a new action was taken, without erasing/hiding the history of the previous comment. That would make it easier to incorporate the kind of messaging Magnus is asking for.
> 
> For the case of running LabelerWorkItem after executing a LabelCommand, just to collapse groups, I'm starting to think that it would be better to just have the LabelCommand automatically collapse groups for you. The implementation might be shared, but by having it happen through the LabelCommand, we don't need to worry about updating the auto label comments, or racing against bot restarts. In that case the LabelCommand reply would include a message of combining the groups.
> 
> I might have missed something, but these are my current thoughts.

Make sense to me. I am thinking about should we introduce a command to let user be able to disable and enable the auto labeling, like `/autolabel off` and `/autolabel on`.

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3237528161

From ihse at openjdk.org  Fri Aug 29 17:27:29 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 29 Aug 2025 17:27:29 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
Message-ID: <CHeCeTSAhACYPc0niGTFzf6NhmfXrhbq3NT3G771eoE=.aa9fcddf-3ebd-4592-9e0e-4a41a22bd33d@github.com>

On Thu, 28 Aug 2025 23:04:05 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This patch is trying to make the pr bot be able to update PR labels when new files are touched.
>> The main idea is from Erik. For a new PR, the bot will run a labelerWorkItem to auto label the PR first, and the commit hash will be stored in a comment.
>> 
>> With this patch, here are some new behaviors of the bot:
>> (1) The user didn't issue manual label command before auto labeling, LabelerWorkItem will do the initial auto labeling and store the commit hash in the comment. 
>> (2) If the user issued manual label command before auto labeling, the initial auto labeling will be skipped, the bot would still post a comment and store the hash in the comment.
>> (3) The user pushes a new commit or few commits to a pr that already auto labeled, the bot will evaluate the diff between stored hash and current head, then add new labels or upgrading labels to group labels, in the end, update the stored hash in the comment.
>> (4) The user force pushes to the pr that already auto labeled, the bot will evaluate the diff between baseHash and current head.
>> (5) The user issues a command to add a label to the pr(or even the user add the label via the forge UI), the bot will check if the labels can be upgraded to group labels.
>> 
>> The side effect of this feature I can imagine is that a user thinks a file is not related to a component and removed it manually, but later, every time when he touches the file, the label will be added back.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

I don't think there is a reason to have a command to disable the autolabeler. It is unlikely that it will work so badly that you want to turn it off for a PR. That would be a situation where you like keep adding files that the labeler keep misclassifying. If that would exceed the annoyance threshold for the users, the autolabeler rules should be fixed instead.

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3237726982

From zsong at openjdk.org  Fri Aug 29 17:46:29 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 29 Aug 2025 17:46:29 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v4]
In-Reply-To: <CHeCeTSAhACYPc0niGTFzf6NhmfXrhbq3NT3G771eoE=.aa9fcddf-3ebd-4592-9e0e-4a41a22bd33d@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <FVCCDdNSPatTOMAsZl5-0Asq7kLaST8D1MLcOgbzqdk=.2c8bd7fc-0308-4922-a20c-366ab327aed1@github.com>
 <CHeCeTSAhACYPc0niGTFzf6NhmfXrhbq3NT3G771eoE=.aa9fcddf-3ebd-4592-9e0e-4a41a22bd33d@github.com>
Message-ID: <pvGDcd5P3hvWH6R83zKQF86Ga0oeLYLC-nMwjPPZow0=.bf39068c-8216-46c7-92be-3e947e9b6759@github.com>

On Fri, 29 Aug 2025 17:25:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I don't think there is a reason to have a command to disable the autolabeler. It is unlikely that it will work so badly that you want to turn it off for a PR. That would be a situation where you like keep adding files that the labeler keep misclassifying. If that would exceed the annoyance threshold for the users, the autolabeler rules should be fixed instead.

OKay, thanks

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

PR Comment: https://git.openjdk.org/skara/pull/1735#issuecomment-3237768105