From zsong at openjdk.org  Thu Sep  4 20:24:01 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 4 Sep 2025 20:24:01 GMT
Subject: RFR: 2544: SKARA bot ignores GitHub comments in some cases
Message-ID: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>

When querying pull requests in GitHub, we should query all the pull requests instead of the first page, otherwise, in some cases, some prs will be ignored.

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

Commit messages:
 - SKARA-2544

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

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

From erikj at openjdk.org  Thu Sep  4 20:33:07 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 4 Sep 2025 20:33:07 GMT
Subject: RFR: 2544: SKARA bot ignores GitHub comments in some cases
In-Reply-To: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
References: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
Message-ID: <irKjDu1bddwIyk35MqXzuGEFU4EFEucY8HEzE7kUyZs=.d2283764-ca12-4e70-b9b4-eede44367a04@github.com>

On Thu, 4 Sep 2025 20:18:00 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When querying pull requests in GitHub, we should query all the pull requests instead of the first page, otherwise, in some cases, some prs will be ignored.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1736#pullrequestreview-3187150414

From zsong at openjdk.org  Thu Sep  4 20:37:35 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 4 Sep 2025 20:37:35 GMT
Subject: RFR: 2544: SKARA bot ignores GitHub comments in some cases
In-Reply-To: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
References: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
Message-ID: <OUBgBgkXmhx6KUtsse_gUmvO1adGVn01QPOi40umHqY=.dc09c665-a0c3-4b46-b28d-6754c9b0c1b6@github.com>

On Thu, 4 Sep 2025 20:18:00 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When querying pull requests in GitHub, we should query all the pull requests instead of the first page, otherwise, in some cases, some prs will be ignored.

Thank you for the quick review!

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

PR Comment: https://git.openjdk.org/skara/pull/1736#issuecomment-3255546458

From zsong at openjdk.org  Thu Sep  4 20:37:35 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 4 Sep 2025 20:37:35 GMT
Subject: Integrated: 2544: SKARA bot ignores GitHub comments in some cases
In-Reply-To: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
References: <4CGEygx0feV7nJrM8GZJ16dQ6DbDL1JnScu1v41OB34=.7a39a3b2-8d75-4e03-bfcf-912a522566a1@github.com>
Message-ID: <7i8LYYBP-Yohhg0NAHZ5CRzK1midDY3NQLOcxZP9dKI=.e3710a2c-cbfa-431a-bfd9-7258db602ec6@github.com>

On Thu, 4 Sep 2025 20:18:00 GMT, Zhao Song <zsong at openjdk.org> wrote:

> When querying pull requests in GitHub, we should query all the pull requests instead of the first page, otherwise, in some cases, some prs will be ignored.

This pull request has now been integrated.

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

2544: SKARA bot ignores GitHub comments in some cases

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Fri Sep  5 20:10:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 20:10:58 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments
Message-ID: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>

The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.

I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

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

Commit messages:
 - New attempt
 - SKARA-2576

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

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

From zsong at openjdk.org  Fri Sep  5 20:14:58 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 5 Sep 2025 20:14:58 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments
In-Reply-To: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
Message-ID: <MEKyS-yd_lUXn1WRTMibYwW9lZig71E_uI9f7bNCQtM=.edd5464b-e335-4761-806a-691560fe289c@github.com>

On Fri, 5 Sep 2025 14:27:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
> 
> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

Looks good!

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

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1737#pullrequestreview-3190657167

From erikj at openjdk.org  Fri Sep  5 21:10:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 21:10:58 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments [v2]
In-Reply-To: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
Message-ID: <rUByyvzte7tCvfuhGnnsB6_cPatW2rPahIe5ks7KypA=.7b53d281-41b4-4ab6-8823-99c8f581327c@github.com>

> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
> 
> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision:

 - More adjustment
 - Adjusted logging

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1737/files
  - new: https://git.openjdk.org/skara/pull/1737/files/82f1cd53..315f40b8

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

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

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

From erikj at openjdk.org  Fri Sep  5 21:10:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 Sep 2025 21:10:58 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments
In-Reply-To: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
Message-ID: <izqzf-2sdlXLErmJ5aOSU6CNzUPs3mxxhZK_TJTSpew=.7802346e-7074-4ce0-8464-dfd579726610@github.com>

On Fri, 5 Sep 2025 14:27:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
> 
> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

Updated the logging a bit after trying this in staging. It looks like it's working correctly now.

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

PR Comment: https://git.openjdk.org/skara/pull/1737#issuecomment-3259747013

From zsong at openjdk.org  Fri Sep  5 21:12:23 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 5 Sep 2025 21:12:23 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments
In-Reply-To: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
Message-ID: <nrlU11W-xY60WEGiKSIx--ziX1q9QCll3eaXzPJpwdo=.50cd779b-931d-47a7-b139-1f95e22f12a8@github.com>

On Fri, 5 Sep 2025 14:27:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
> 
> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

So what was the issue with the previous commit?

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

PR Comment: https://git.openjdk.org/skara/pull/1737#issuecomment-3259757374

From zsong at openjdk.org  Fri Sep  5 21:20:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 5 Sep 2025 21:20:05 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments
In-Reply-To: <nrlU11W-xY60WEGiKSIx--ziX1q9QCll3eaXzPJpwdo=.50cd779b-931d-47a7-b139-1f95e22f12a8@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
 <nrlU11W-xY60WEGiKSIx--ziX1q9QCll3eaXzPJpwdo=.50cd779b-931d-47a7-b139-1f95e22f12a8@github.com>
Message-ID: <r4x3XGmQ8J6wVeinKvMzUwRSMT7H9_8YKwIMvRHrpMo=.11de69cb-d6c6-4243-b372-b6ac4624686c@github.com>

On Fri, 5 Sep 2025 21:10:16 GMT, Zhao Song <zsong at openjdk.org> wrote:

> So what was the issue with the previous commit?

I see, previous one always update previousUpdatedAt

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

PR Comment: https://git.openjdk.org/skara/pull/1737#issuecomment-3259774551

From zsong at openjdk.org  Fri Sep  5 21:25:07 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 5 Sep 2025 21:25:07 GMT
Subject: RFR: 2576: Bots still ignore GitHub comments [v2]
In-Reply-To: <rUByyvzte7tCvfuhGnnsB6_cPatW2rPahIe5ks7KypA=.7b53d281-41b4-4ab6-8823-99c8f581327c@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
 <rUByyvzte7tCvfuhGnnsB6_cPatW2rPahIe5ks7KypA=.7b53d281-41b4-4ab6-8823-99c8f581327c@github.com>
Message-ID: <gP9zU1vFVq7sCV8hKedEBrfELXkOOg9o7xYMiNHE6DU=.b904e483-bfd8-4112-9fcf-ed8cc396b670@github.com>

On Fri, 5 Sep 2025 21:10:58 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
>> 
>> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.
>
> Erik Joelsson has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - More adjustment
>  - Adjusted logging

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1737#pullrequestreview-3190827116

From erikj at openjdk.org  Mon Sep  8 20:28:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 8 Sep 2025 20:28:11 GMT
Subject: Integrated: 2576: Bots still ignore GitHub comments
In-Reply-To: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
References: <ybRZm3oeiZ3MLw_cyXKD-TRW32gZLmb6mOWFZy0h0P4=.861c9d4a-fcc7-4c0d-8e2b-8282eee44287@github.com>
Message-ID: <KRY6VZ3Vv-_wswEh1M3Te5YiOdJnBXcrvEso2QHPyVU=.98894508-fc0d-4d2b-a2b3-5ab2802c3840@github.com>

On Fri, 5 Sep 2025 14:27:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The fix in [SKARA-2544](https://bugs.openjdk.org/browse/SKARA-2544) wasn't right and needs to be backed out. Getting all PRs for a repository is just way too much. My assumption was that the main reason this happened was that we sometimes had users touch more than 30 PRs within one query cycle, but that doesn't seem to be the case. As Zhao showed in the other issue, GitHub sometimes doesn't update the sort order for "updated" when a PR is touched. The "updated_at" field gets updated, but when listing PRs and sorting on "updated" it's stuck in its old sorting position. This makes us miss it in the PullRequestPoller. The only reasonable way I can see us fixing this is to increase the default page size of 30 to 100 (which is max) and potentially add a couple of pages. We need to be careful though as getting more PRs will put more load on the system.
> 
> I'm also adding detection and logging of out of order PRs so that we can observe a change in behavior from GitHub. If we stop getting such log messages in the future we may assume that the issue is resolved on the GitHub side and remove the workaround.

This pull request has now been integrated.

Changeset: 27d36119
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/27d36119d7215af5ce5d4f96dd9b46136f8d9d96
Stats:     25 lines in 1 file changed: 17 ins; 0 del; 8 mod

2576: Bots still ignore GitHub comments

Reviewed-by: zsong

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

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

From zsong at openjdk.org  Thu Sep 11 19:10:24 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Sep 2025 19:10:24 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v5]
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: <tkBu9ZBvXDpU991ZnLeS2VbkJ9cbxis7-_hWZAn8eeo=.62e70d4d-9735-4c0c-bf79-079daca907a7@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - update
 - update
 - update
 - update
 - Merge branch 'master' into SKARA-2065
 - fix test
 - fix tests
 - fix tests
 - version2
 - review comment
 - ... and 16 more: https://git.openjdk.org/skara/compare/6831f219...f704407c

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/9277cf99..f704407c

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

  Stats: 304 lines in 13 files changed: 98 ins; 131 del; 75 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 Sep 11 19:10:24 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Sep 2025 19:10:24 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: <K-SU60tXwFC7J7A2v1vwMgmTA4PnKK6TU7v3hl0Evkc=.4541dfb3-18ee-41d9-9700-7899af934fad@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

While working on this, I found that there is a labels field in TestPullRequest, however, TestPullRequest extends TestIssue, there is already a labels field in TestIssue, so we should remove it in TestPullRequest.

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

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

From erikj at openjdk.org  Thu Sep 11 20:46:29 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Sep 2025 20:46:29 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v5]
In-Reply-To: <tkBu9ZBvXDpU991ZnLeS2VbkJ9cbxis7-_hWZAn8eeo=.62e70d4d-9735-4c0c-bf79-079daca907a7@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <tkBu9ZBvXDpU991ZnLeS2VbkJ9cbxis7-_hWZAn8eeo=.62e70d4d-9735-4c0c-bf79-079daca907a7@github.com>
Message-ID: <3qSSXkH3RIxuhga0WghjuLEqEnENO6iCvRXLEluGeKE=.ba958cd0-8a09-46b7-9f71-9afe9505ff2c@github.com>

On Thu, 11 Sep 2025 19:10:24 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - update
>  - update
>  - update
>  - update
>  - Merge branch 'master' into SKARA-2065
>  - fix test
>  - fix tests
>  - fix tests
>  - version2
>  - review comment
>  - ... and 16 more: https://git.openjdk.org/skara/compare/36a34e12...f704407c

bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 164:

> 162:                     reply.println(LabelTracker.addLabelMarker(label));
> 163:                     reply.println("The `" + groupLabel.get() + "` group label was already applied, so `" + label + "` label will not be added.");
> 164:                 }

I think you forgot to check that the groupLabel (or rather any of the set of potential group labels) are in `currentLabels`.

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

> 65: 
> 66: 
> 67:     private void updateLabelMessage(List<Comment> comments, List<String> newLabels, String commitHash) {

If this is only supposed to be called once, then the method name should be something like `createInitialLabelMessage`.

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

> 124:     @Override
> 125:     public Collection<WorkItem> prRun(ScratchArea scratchArea) {
> 126:         // If no label configuration, return early

It's probably a good idea to also check if the PR is closed. There could be a delay from scheduling the work item to running it.

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

> 134:         Set<String> newLabels = new HashSet<>(pr.labelNames());
> 135: 
> 136:         // If the initial label comment can be found,Updating labels when new files are touched

Suggestion:

        // If the initial label comment can be found, updating labels when new files are touched

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

> 157:                     pr.updateComment(initialLabelComment.get().id(), initialLabelComment.get().body().replaceAll(
> 158:                             "(<!-- PullRequest Bot label commit ')[^']*(' -->)",
> 159:                             "$1" + pr.headHash().toString() + "$2"));

Could this be expressed with the existing constants? Look for the pattern and replace with the formatter string?

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

> 168:             // No need to return CheckWorkItem, if there is any label added, in the next round of CheckWorkItem, it will re-evaluate the pr
> 169:             return List.of();
> 170:         }

I think it would make the code clearer if the remainder of the method was put in an `else` block here.

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

> 199:                     .collect(Collectors.joining(", ")));
> 200:             message.append(labelsAdded.size() == 1 ? " has" : " have");
> 201:             message.append(" been added to this pr based on the files touched in your new commit(s).");

Suggestion:

            message.append(" been added to this pull request based on files touched in new commit(s).");

forge/src/main/java/org/openjdk/skara/forge/LabelConfigurationJson.java line 177:

> 175:             }
> 176:         }
> 177:         return Optional.empty();

This method looks like it assumes that a label can only be part of one group. That is true for current uses of label groups, but I don't think the current implementation is making that assumption. I think it would be better if this method returned a collection, probably a set, of group labels instead of an Optional of a single group label. Also please document what the method does.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342207086
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342245556
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342267339
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342224657
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342252272
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342256006
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342259059
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342203524

From zsong at openjdk.org  Thu Sep 11 22:59:20 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Sep 2025 22:59:20 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v6]
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: <ywku4bWecznp0h4nVum9BSGJXkkbQ4ANWJiKVvR-Pes=.e99c5c81-1866-4291-be24-00f721e43d9c@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 four additional commits since the last revision:

 - update
 - update
 - review comment
 - fix an issue

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/f704407c..f799f8f4

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

  Stats: 84 lines in 7 files changed: 48 ins; 17 del; 19 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 Sep 11 22:59:21 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 11 Sep 2025 22:59:21 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v5]
In-Reply-To: <3qSSXkH3RIxuhga0WghjuLEqEnENO6iCvRXLEluGeKE=.ba958cd0-8a09-46b7-9f71-9afe9505ff2c@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <tkBu9ZBvXDpU991ZnLeS2VbkJ9cbxis7-_hWZAn8eeo=.62e70d4d-9735-4c0c-bf79-079daca907a7@github.com>
 <3qSSXkH3RIxuhga0WghjuLEqEnENO6iCvRXLEluGeKE=.ba958cd0-8a09-46b7-9f71-9afe9505ff2c@github.com>
Message-ID: <yzRlxi79thkCGU1q5gCF5pTkSbMXReBE0fiINSr7AwU=.cda1bb78-b46e-4745-b77e-f2be6fecd3a9@github.com>

On Thu, 11 Sep 2025 20:02:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
>> 
>>  - update
>>  - update
>>  - update
>>  - update
>>  - Merge branch 'master' into SKARA-2065
>>  - fix test
>>  - fix tests
>>  - fix tests
>>  - version2
>>  - review comment
>>  - ... and 16 more: https://git.openjdk.org/skara/compare/8bdeb725...f704407c
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 164:
> 
>> 162:                     reply.println(LabelTracker.addLabelMarker(label));
>> 163:                     reply.println("The `" + groupLabel.get() + "` group label was already applied, so `" + label + "` label will not be added.");
>> 164:                 }
> 
> I think you forgot to check that the groupLabel (or rather any of the set of potential group labels) are in `currentLabels`.

Yes, I realized it and have fixed it.  Thanks

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 67:
> 
>> 65: 
>> 66: 
>> 67:     private void updateLabelMessage(List<Comment> comments, List<String> newLabels, String commitHash) {
> 
> If this is only supposed to be called once, then the method name should be something like `createInitialLabelMessage`.

Sure, will rename it.

> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 126:
> 
>> 124:     @Override
>> 125:     public Collection<WorkItem> prRun(ScratchArea scratchArea) {
>> 126:         // If no label configuration, return early
> 
> It's probably a good idea to also check if the PR is closed. There could be a delay from scheduling the work item to running it.

Sure, will add it.

> forge/src/main/java/org/openjdk/skara/forge/LabelConfigurationJson.java line 177:
> 
>> 175:             }
>> 176:         }
>> 177:         return Optional.empty();
> 
> This method looks like it assumes that a label can only be part of one group. That is true for current uses of label groups, but I don't think the current implementation is making that assumption. I think it would be better if this method returned a collection, probably a set, of group labels instead of an Optional of a single group label. Also please document what the method does.

Makes sense, will change it. Thanks

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

PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342296998
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342302866
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342310714
PR Review Comment: https://git.openjdk.org/skara/pull/1735#discussion_r2342298419

From zsong at openjdk.org  Mon Sep 15 15:58:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 15 Sep 2025 15:58:15 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: <mr4dTZM5qIsolr-mfVk758kTZ-wv5a5hQsv1MWLimJs=.4486fa63-fdb7-4c4e-82e7-fd168f616aaf@github.com>

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

>> 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.

@erikj79  This PR is ready for review again. When you have time, could you please take another look? Thanks!

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

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

From erikj at openjdk.org  Mon Sep 15 17:32:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 15 Sep 2025 17:32:56 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v6]
In-Reply-To: <ywku4bWecznp0h4nVum9BSGJXkkbQ4ANWJiKVvR-Pes=.e99c5c81-1866-4291-be24-00f721e43d9c@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <ywku4bWecznp0h4nVum9BSGJXkkbQ4ANWJiKVvR-Pes=.e99c5c81-1866-4291-be24-00f721e43d9c@github.com>
Message-ID: <acQY9Kksli3AW4QfqjSFponfNzVVk1L4lwzJuCQy8fc=.d6992541-c9e1-4ac1-9466-ae81e5214a5e@github.com>

On Thu, 11 Sep 2025 22:59:20 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 four additional commits since the last revision:
> 
>  - update
>  - update
>  - review comment
>  - fix an issue

bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 153:

> 151:     }
> 152: 
> 153:     private void addLabels(List<String> labelsToAdd, Set<String> currentLabels, PullRequest pr, PrintWriter reply, PullRequestBot bot) {

If this method is updating the argument set of `currentLabels`, then this should be documented as it's likely not what a caller would expect. Same goes for `removeLabels`. 

If we are maintaining a local copy of the current set of labels, shouldn't we reuse that when calling `upgradeLabelsToGroups` as well?

forge/src/main/java/org/openjdk/skara/forge/LabelConfiguration.java line 36:

> 34:      * Returns the set of groups that this label belongs to.
> 35:      */
> 36:     Set<String> groupLabel(String label);

If it returns multiple items, then the noun in the method should be plural.
Suggestion:

    Set<String> groupLabels(String label);

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

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

From zsong at openjdk.org  Mon Sep 15 18:03:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 15 Sep 2025 18:03:19 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v6]
In-Reply-To: <acQY9Kksli3AW4QfqjSFponfNzVVk1L4lwzJuCQy8fc=.d6992541-c9e1-4ac1-9466-ae81e5214a5e@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <ywku4bWecznp0h4nVum9BSGJXkkbQ4ANWJiKVvR-Pes=.e99c5c81-1866-4291-be24-00f721e43d9c@github.com>
 <acQY9Kksli3AW4QfqjSFponfNzVVk1L4lwzJuCQy8fc=.d6992541-c9e1-4ac1-9466-ae81e5214a5e@github.com>
Message-ID: <FFk130YF6L8_auOrkhQWQs-Ge0j7Q0XZK-oFKDWwr_0=.d92252d8-6782-41fd-b915-22daa3b4b111@github.com>

On Mon, 15 Sep 2025 17:25:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Zhao Song has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - update
>>  - update
>>  - review comment
>>  - fix an issue
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelCommand.java line 153:
> 
>> 151:     }
>> 152: 
>> 153:     private void addLabels(List<String> labelsToAdd, Set<String> currentLabels, PullRequest pr, PrintWriter reply, PullRequestBot bot) {
> 
> If this method is updating the argument set of `currentLabels`, then this should be documented as it's likely not what a caller would expect. Same goes for `removeLabels`. 
> 
> If we are maintaining a local copy of the current set of labels, shouldn't we reuse that when calling `upgradeLabelsToGroups` as well?

Yes, will add some documentations.

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

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

From zsong at openjdk.org  Mon Sep 15 18:13:14 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 15 Sep 2025 18:13:14 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v7]
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: <mpqMkuyGgdIwiLGIrQtL8haQ_MCJTsio1IKnt-Ng9II=.ccf91e26-b08a-466a-8a9d-3caa56e6f874@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:

  Add documentations for addLabels and removeLabels

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1735/files
  - new: https://git.openjdk.org/skara/pull/1735/files/f799f8f4..d524ad7b

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

  Stats: 19 lines in 4 files changed: 9 ins; 0 del; 10 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  Mon Sep 15 19:31:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 15 Sep 2025 19:31:54 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v7]
In-Reply-To: <mpqMkuyGgdIwiLGIrQtL8haQ_MCJTsio1IKnt-Ng9II=.ccf91e26-b08a-466a-8a9d-3caa56e6f874@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <mpqMkuyGgdIwiLGIrQtL8haQ_MCJTsio1IKnt-Ng9II=.ccf91e26-b08a-466a-8a9d-3caa56e6f874@github.com>
Message-ID: <IZ-W3iRLEhpn5jpmr6f3zurB_k-7K8TjLhEBTFHlouY=.82ad057d-d203-4d63-ac7e-7ed9d1d0e5b7@github.com>

On Mon, 15 Sep 2025 18:13:14 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:
> 
>   Add documentations for addLabels and removeLabels

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1735#pullrequestreview-3225989306

From zsong at openjdk.org  Mon Sep 15 20:56:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 15 Sep 2025 20:56:05 GMT
Subject: RFR: 2065: Update PR labels when new files are touched [v7]
In-Reply-To: <mpqMkuyGgdIwiLGIrQtL8haQ_MCJTsio1IKnt-Ng9II=.ccf91e26-b08a-466a-8a9d-3caa56e6f874@github.com>
References: <jlmKZaNywT_zjIbb7e7OA0Ay4RQ9dwbiExiC-025xls=.d027f380-3ee7-4ac8-8889-163bfe0275cf@github.com>
 <mpqMkuyGgdIwiLGIrQtL8haQ_MCJTsio1IKnt-Ng9II=.ccf91e26-b08a-466a-8a9d-3caa56e6f874@github.com>
Message-ID: <IBVO4czLamjWjHhhycdOeASFn4YyvZGMYbe1eDmEbIk=.c0f77a35-d5bc-417b-bf2c-fbc0ee6c09f5@github.com>

On Mon, 15 Sep 2025 18:13:14 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:
> 
>   Add documentations for addLabels and removeLabels

Thank you for the review and suggestions!

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

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

From zsong at openjdk.org  Mon Sep 15 20:56:05 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 15 Sep 2025 20:56:05 GMT
Subject: Integrated: 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: <-vtebZZMnrGgwN0QF4QCbnCB1o_aDrgLVwvKkq1zkdU=.dce98152-1c47-443c-a37e-b552e2f9fcb9@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.
> 
> 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.

This pull request has now been integrated.

Changeset: b0ce8b9c
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/b0ce8b9c360222e4f2522a3d80a29bf0a14ee1f7
Stats:     437 lines in 13 files changed: 272 ins; 65 del; 100 mod

2065: Update PR labels when new files are touched

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Tue Sep 16 22:49:42 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 16 Sep 2025 22:49:42 GMT
Subject: RFR: 2586: Support multi fix version mode in IssueNotifier
Message-ID: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>

In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.

In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.

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

Commit messages:
 - Correct spelling
 - SKARA-2586

Changes: https://git.openjdk.org/skara/pull/1738/files
  Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1738&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2586
  Stats: 141 lines in 7 files changed: 107 ins; 5 del; 29 mod
  Patch: https://git.openjdk.org/skara/pull/1738.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1738/head:pull/1738

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

From erikj at openjdk.org  Wed Sep 17 13:29:06 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 13:29:06 GMT
Subject: RFR: 2587: Notify core-libs mailing list for src/jdk.incubator.vector
 changes
Message-ID: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>

Map `src/jdk.incubator.vector` to the core-libs label for the JDK repository.

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

Commit messages:
 - SKARA-2587

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

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

From ihse at openjdk.org  Wed Sep 17 15:12:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Sep 2025 15:12:32 GMT
Subject: RFR: 2587: Notify core-libs mailing list for
 src/jdk.incubator.vector changes
In-Reply-To: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
References: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
Message-ID: <IW4ZJBf8z2E2pbHpaeb9vtnHvATT55oFn6r6RqpaYqE=.ed2d6486-2e37-4409-a322-e11be7ff5210@github.com>

On Wed, 17 Sep 2025 13:23:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Map `src/jdk.incubator.vector` to the core-libs label for the JDK repository.

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1739#pullrequestreview-3234970239

From darcy at openjdk.org  Wed Sep 17 15:51:29 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Sep 2025 15:51:29 GMT
Subject: RFR: 2587: Notify core-libs mailing list for
 src/jdk.incubator.vector changes
In-Reply-To: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
References: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
Message-ID: <jA9oCkuL-8SZf31QxW5Tw1YqWzaZI2-kogAmRRFTH0s=.3922b4ac-a763-43dc-b679-05155ba875fd@github.com>

On Wed, 17 Sep 2025 13:23:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Map `src/jdk.incubator.vector` to the core-libs label for the JDK repository.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1739#pullrequestreview-3235153556

From zsong at openjdk.org  Wed Sep 17 16:16:15 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 17 Sep 2025 16:16:15 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits
Message-ID: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>

Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

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

Commit messages:
 - rename
 - SKARA-2588

Changes: https://git.openjdk.org/skara/pull/1740/files
  Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1740&range=00
  Issue: https://bugs.openjdk.org/browse/SKARA-2588
  Stats: 239 lines in 4 files changed: 157 ins; 65 del; 17 mod
  Patch: https://git.openjdk.org/skara/pull/1740.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1740/head:pull/1740

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

From erikj at openjdk.org  Wed Sep 17 16:27:59 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 16:27:59 GMT
Subject: Integrated: 2587: Notify core-libs mailing list for
 src/jdk.incubator.vector changes
In-Reply-To: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
References: <eZbgCEdLfPdlJT1thUM1YYR2kqXRAdc7TS9VzilKNd8=.dc8c8741-3a13-460a-92b7-c6bd29e05479@github.com>
Message-ID: <IinVJGegqPtNTNBzb9UXJFAebpTAmgfPtb3AneF2KkI=.6db0a960-cea0-4493-b4ec-88ff9d013c05@github.com>

On Wed, 17 Sep 2025 13:23:29 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Map `src/jdk.incubator.vector` to the core-libs label for the JDK repository.

This pull request has now been integrated.

Changeset: 79f0bd99
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/79f0bd99a65e531f39896b2ef817fbe54e8d7b4d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

2587: Notify core-libs mailing list for src/jdk.incubator.vector changes

Reviewed-by: ihse, darcy

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

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

From zsong at openjdk.org  Wed Sep 17 17:16:30 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 17 Sep 2025 17:16:30 GMT
Subject: RFR: 2586: Support multi fix version mode in IssueNotifier
In-Reply-To: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
References: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
Message-ID: <nvWFx2zWrOCDEIjszgJ3jcrxZYtBkw0BCmOtiOT-fik=.09f0f4ed-4ed6-4d20-8c41-34efbf98a20d@github.com>

On Tue, 16 Sep 2025 21:36:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.
> 
> In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.

Looks good

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

Marked as reviewed by zsong (Reviewer).

PR Review: https://git.openjdk.org/skara/pull/1738#pullrequestreview-3235456425

From erikj at openjdk.org  Wed Sep 17 20:10:51 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 20:10:51 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits
In-Reply-To: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
Message-ID: <kGfQLlL425bi4QZ29hDj5Tdyyz54adobPc9OmAfQLN0=.fcf27694-1c0f-4199-8718-a523a237c6ea@github.com>

On Wed, 17 Sep 2025 15:50:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

There are problems with this approach. 

1. Say the user pushes two commits, in the first it touches file A, then realizes it was a mistake and reverts that change in the second commit. If those two commits are pushed together, then before this patch, file A wouldn't appear in the diff, but with this patch it does.
2. I don't think we can make the assumption that the first parent will always be the correct one to follow in a merge commit.

I think I have figured out a better algorithm, but I'm not sure yet:
First find all commits that are ancestors of the PR head, but are not present in the target branch, this is the complete set of PR commits. Then iterate backwards from `to` until you find a merge commit or the `from` commit. Take the diff from all commits passed this way combined and extract changed files. Then if this was a merge commit, pick all parents that are in the complete set we collected earlier and continue this way until reaching the `from` commit.

This will group any consecutive commits between merges to at least alleviate most of the potential issues from 1, but not all, so I'm still unsure if this is good enough. It will guarantee that we only consider commits in the PR and not anything already present in the target branch. 

Maybe for the initial labeling, we can skip this algorithm completely and just diff PR head with mergebase. At that time, that diff is guaranteed to be correct at least.

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

PR Review: https://git.openjdk.org/skara/pull/1740#pullrequestreview-3236106538

From erikj at openjdk.org  Wed Sep 17 20:39:29 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 20:39:29 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits
In-Reply-To: <kGfQLlL425bi4QZ29hDj5Tdyyz54adobPc9OmAfQLN0=.fcf27694-1c0f-4199-8718-a523a237c6ea@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
 <kGfQLlL425bi4QZ29hDj5Tdyyz54adobPc9OmAfQLN0=.fcf27694-1c0f-4199-8718-a523a237c6ea@github.com>
Message-ID: <0EWVA0ww8DgjHmDOSL-SYW2rHMD1U6xtmpP31MnhWWM=.bf4d1a62-5fd3-430a-8542-ae696566f626@github.com>

On Wed, 17 Sep 2025 20:08:33 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think I have figured out a better algorithm, but I'm not sure yet:

I did some more thinking and I think I have a much simpler proposal (as I already shared in person, but writing it here for transparency).

Instead of creating diffs between series of commits in the PR branch, we should always just diff against the merge-base with the target branch. The first auto labeling is the base case, where we just do exactly this and add labels based on the changed files. Then for additional labeling, we first repeat the diff from the previous run, then we create the diff from the current PR head to its merge-base. This gives us two sets of changed files. We subtract the set from the previous labeling from the set from the current PR head and calculate additional labels from that.

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

PR Comment: https://git.openjdk.org/skara/pull/1740#issuecomment-3304492180

From erikj at openjdk.org  Wed Sep 17 20:42:11 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 20:42:11 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits
In-Reply-To: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
Message-ID: <OZHH1gYhhzNYRTJXpDzX-C6Edlv5PSKSNM_o1kUXwGM=.bd16191d-215b-4452-adff-2e31979514f9@github.com>

On Wed, 17 Sep 2025 15:50:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

I think this will require extra care with dependent PRs. Since the target branch of a PR can change (and will for dependent PRs), we will need to record the merge-base we used in addition to the head hash.

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

PR Comment: https://git.openjdk.org/skara/pull/1740#issuecomment-3304498925

From zsong at openjdk.org  Wed Sep 17 22:56:22 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 17 Sep 2025 22:56:22 GMT
Subject: Withdrawn: 2588: Auto Labeling should ignore merge commits
In-Reply-To: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
Message-ID: <PdyX0p5YwuvkmdSjOPMibqIPw1rb2uA_KHv6jmNkpJE=.58c33121-9f15-4a64-81ce-2f6910892fe8@github.com>

On Wed, 17 Sep 2025 15:50:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

This pull request has been closed without being integrated.

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

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

From erikj at openjdk.org  Wed Sep 17 23:15:17 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Sep 2025 23:15:17 GMT
Subject: RFR: 2586: Support multi fix version mode in IssueNotifier
In-Reply-To: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
References: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
Message-ID: <2bmZVcYY8jXejhbTmsfmvbgErj_Av0yd1YRBHL56YwE=.b312fbf5-381d-4f9c-ba16-130dfc5bf7c5@github.com>

On Tue, 16 Sep 2025 21:36:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.
> 
> In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.

Thanks! I've manually verified a full workflow now, but I will hold off on this until the labeling change is under control.

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

PR Comment: https://git.openjdk.org/skara/pull/1738#issuecomment-3304812384

From zsong at openjdk.org  Thu Sep 18 04:23:17 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Sep 2025 04:23:17 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits [v2]
In-Reply-To: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
Message-ID: <PR831YFQh0xcSBPnawqU5-1PSnYIVf9cgPhRETYHMHo=.0cdec128-a4a1-4222-b74a-b492eabb8582@github.com>

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  SKARA-2588

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1740/files
  - new: https://git.openjdk.org/skara/pull/1740/files/288587ea..3880af63

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

  Stats: 38 lines in 2 files changed: 6 ins; 9 del; 23 mod
  Patch: https://git.openjdk.org/skara/pull/1740.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1740/head:pull/1740

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

From erikj at openjdk.org  Thu Sep 18 16:59:46 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 16:59:46 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits [v2]
In-Reply-To: <PR831YFQh0xcSBPnawqU5-1PSnYIVf9cgPhRETYHMHo=.0cdec128-a4a1-4222-b74a-b492eabb8582@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
 <PR831YFQh0xcSBPnawqU5-1PSnYIVf9cgPhRETYHMHo=.0cdec128-a4a1-4222-b74a-b492eabb8582@github.com>
Message-ID: <dsmYKf20OoiPjwv0hW9buyVuVrLZR4fGX_EN7eSS_To=.760e27da-a7de-4461-b555-486ca7f1f908@github.com>

On Thu, 18 Sep 2025 04:23:17 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
>> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.
>
> Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   SKARA-2588

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1740#pullrequestreview-3240988872

From zsong at openjdk.org  Thu Sep 18 17:31:28 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Sep 2025 17:31:28 GMT
Subject: RFR: 2588: Auto Labeling should ignore merge commits [v2]
In-Reply-To: <PR831YFQh0xcSBPnawqU5-1PSnYIVf9cgPhRETYHMHo=.0cdec128-a4a1-4222-b74a-b492eabb8582@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
 <PR831YFQh0xcSBPnawqU5-1PSnYIVf9cgPhRETYHMHo=.0cdec128-a4a1-4222-b74a-b492eabb8582@github.com>
Message-ID: <WmRbCvH5fsP4oBO707bebteawOjAP9LOzTxIr6h0cgs=.c5812eb9-8bc6-4024-865a-7f8e94e8cfdb@github.com>

On Thu, 18 Sep 2025 04:23:17 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
>> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.
>
> Zhao Song has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   SKARA-2588

Thank you for the idea and review!

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

PR Comment: https://git.openjdk.org/skara/pull/1740#issuecomment-3308703567

From zsong at openjdk.org  Thu Sep 18 17:31:28 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Sep 2025 17:31:28 GMT
Subject: Integrated: 2588: Auto Labeling should ignore merge commits
In-Reply-To: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
References: <vxdFoMhc_AvaIXQgQwvcm-Gq0EFVAyO2CJqYnVF9GTc=.0a9ea7a3-a121-4cc8-9839-f18875d92d59@github.com>
Message-ID: <Iuk06Kz4rKm5JOuSViG5bEuPhFz3dQ94JA9HvRAop-g=.d237a158-0546-4bce-8d8a-b3dc36e728e9@github.com>

On Wed, 17 Sep 2025 15:50:08 GMT, Zhao Song <zsong at openjdk.org> wrote:

> Currently, the auto labeling doesn't ignore merge commits, so when user merge master back into their feature branch, it's possible that unrelated labels are added to the pull request.
> This patch is trying to let the bot ignore all the merge commits and the commits brought in by the merges.

This pull request has now been integrated.

Changeset: a8a681a7
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/a8a681a7688c0a7aefc375ad9afefcc93a502bcc
Stats:     225 lines in 3 files changed: 154 ins; 65 del; 6 mod

2588: Auto Labeling should ignore merge commits

Reviewed-by: erikj

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

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

From erikj at openjdk.org  Thu Sep 18 18:16:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 18:16:58 GMT
Subject: RFR: 2586: Support multi fix version mode in IssueNotifier [v2]
In-Reply-To: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
References: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
Message-ID: <mlqlbO_VeSC8zBRt4NXfXYubhJDuXrMKg_rhOAitYIc=.6570a144-26aa-4c16-90df-8f0d88a2f416@github.com>

> In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.
> 
> In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.

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

  Restore whitespace

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

Changes:
  - all: https://git.openjdk.org/skara/pull/1738/files
  - new: https://git.openjdk.org/skara/pull/1738/files/77c7fa31..cbc94264

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

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

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

From zsong at openjdk.org  Thu Sep 18 18:16:58 2025
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 18 Sep 2025 18:16:58 GMT
Subject: RFR: 2586: Support multi fix version mode in IssueNotifier [v2]
In-Reply-To: <mlqlbO_VeSC8zBRt4NXfXYubhJDuXrMKg_rhOAitYIc=.6570a144-26aa-4c16-90df-8f0d88a2f416@github.com>
References: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
 <mlqlbO_VeSC8zBRt4NXfXYubhJDuXrMKg_rhOAitYIc=.6570a144-26aa-4c16-90df-8f0d88a2f416@github.com>
Message-ID: <CW6UZwBVZRFz4arPGfMqL3a02k4N5o52x0NfVAI92bA=.f3b791ea-24d1-44f8-9ffd-16b54173bedd@github.com>

On Thu, 18 Sep 2025 18:12:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.
>> 
>> In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.
>
> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore whitespace

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1738#pullrequestreview-3241342472

From erikj at openjdk.org  Thu Sep 18 18:16:58 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 18 Sep 2025 18:16:58 GMT
Subject: Integrated: 2586: Support multi fix version mode in IssueNotifier
In-Reply-To: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
References: <K7yg6eqOoMhzbpvIA98EdmTyCMKzbymj7FkXmG8lPBg=.644d88eb-c8c7-4ae9-b830-9306f2d89c75@github.com>
Message-ID: <AKLHN6tAZK2PY--ghBf5jlmi0cI0T_lEZ9KUrn18ZT8=.f4415bdb-df34-4c2d-be39-81a595344eaf@github.com>

On Tue, 16 Sep 2025 21:36:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> In some projects, other than the JDK, we would like to use Skara in a simplified Jira workflow, where we use the multi value aspect of the Jira FixVersion field instead of creating backport records. To support this I propose to add a configuration option in the IssueNotifier "multifixversion", with default value false, which corresponds to the current behavior with backports. When set to true, then instead of creating backports, the notifier would just pile on additional fix versions when a commit is integrated into multiple different branches.
> 
> In addition to this, I would like to also add handling of a "branch-" prefix for a version strings. This would mimic the current "repo-" prefix which is already in use for JDK projects.

This pull request has now been integrated.

Changeset: 038c073b
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/038c073b1242e77507155e49ddc5c98b9b8d5847
Stats:     135 lines in 7 files changed: 101 ins; 5 del; 29 mod

2586: Support multi fix version mode in IssueNotifier

Reviewed-by: zsong

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

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

From josiahnoel at gmail.com  Sat Sep 20 18:28:32 2025
From: josiahnoel at gmail.com (Josiah Noel)
Date: Sat, 20 Sep 2025 14:28:32 -0400
Subject: OCA verify timing
Message-ID: <CAJ_t5UbcG=VBMxizdSAB-MRH1RpVkEvj6VT-Fm2ST9FWdzkdGA@mail.gmail.com>

Hey team, I've had a valid OCA since april contributing to other oracle
projects, but it seems the bot doesn't recognize me when I raised a PR to
openjdk.

It has been more than two weeks since I commented `/signed`. Is it supposed
to take so long to verify the OCA?

My PR for reference: https://github.com/openjdk/jdk/pull/27069

-- 
Cheers, Josiah.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/skara-dev/attachments/20250920/1dda9912/attachment.htm>

From dalibor.topic at oracle.com  Mon Sep 22 17:50:41 2025
From: dalibor.topic at oracle.com (Dalibor Topic)
Date: Mon, 22 Sep 2025 19:50:41 +0200
Subject: OCA verify timing
In-Reply-To: <CAJ_t5UbcG=VBMxizdSAB-MRH1RpVkEvj6VT-Fm2ST9FWdzkdGA@mail.gmail.com>
References: <CAJ_t5UbcG=VBMxizdSAB-MRH1RpVkEvj6VT-Fm2ST9FWdzkdGA@mail.gmail.com>
Message-ID: <a4d92b71-dacb-43a9-aec9-392656ff72d0@oracle.com>

Hi Josiah,

thanks for the ping & apologies for the delay. I've marked your account 
as verified in Skara. The OCA bot will lift the tags in a few minutes.

cheers,
dalibor topic

On 20/09/2025 20:28, Josiah Noel wrote:
> Hey team, I've had a valid OCA since april contributing to other oracle 
> projects, but it seems the bot doesn't recognize me when I raised a PR 
> to openjdk.
> 
> It has been more than two weeks since I commented `/signed`. Is it 
> supposed to take so long to verify the OCA?
> 
> My PR for reference: https://github.com/openjdk/jdk/pull/27069 <https:// 
> github.com/openjdk/jdk/pull/27069>
> 
> -- 
> Cheers, Josiah.

-- 
<http://www.oracle.com> Dalibor Topic
Consulting Product Manager
Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961
<tel:+491737185961>

Oracle Global Services Germany GmbH
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRB 246209
Gesch?ftsf?hrer: Ralf Herrmann


From zsong at openjdk.org  Tue Sep 23 16:58:00 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 23 Sep 2025 16:58:00 GMT
Subject: RFR: 2591: Improve auto labeler
Message-ID: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>

After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.

After discussion with Erik, we propose the following behavior for the auto labeler:
 1. The auto labeler will never remove labels that have already been added.
 2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
 3. Users can add any labels they want.
 Example:
 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
      (Current labels: ?hotspot-runtime?)
 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
     (Current labels: ?hotspot-runtime?, ?hotspot?)
3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
     (Current labels: ?hotspot-runtime?, ?hotspot?)

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

Commit messages:
 - SKARA-2591

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

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

From erikj at openjdk.org  Tue Sep 23 17:55:54 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 Sep 2025 17:55:54 GMT
Subject: RFR: 2591: Improve auto labeler
In-Reply-To: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
Message-ID: <lIE8X3TBJKMN_PYBTki-cFXzDlaslJtvH8J3CO_KarU=.6b3bfd82-fefa-40f8-8f31-ae027d06bdeb@github.com>

On Tue, 23 Sep 2025 16:47:33 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
> 
> After discussion with Erik, we propose the following behavior for the auto labeler:
>  1. The auto labeler will never remove labels that have already been added.
>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>  3. Users can add any labels they want.
>  Example:
>  1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>       (Current labels: ?hotspot-runtime?)
>  2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)
> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)

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

> 158:                             newLabels.add(label);
> 159:                         }
> 160:                     }

I think this check needs to be applied on the initial run of the auto labeler as well. The user may have manually added labels already (which previously would disable the auto labeler), but now since we run it anyway, I think it needs to check for existing group labels.

I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1741#discussion_r2373052081

From zsong at openjdk.org  Tue Sep 23 17:59:30 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 23 Sep 2025 17:59:30 GMT
Subject: RFR: 2591: Improve auto labeler
In-Reply-To: <lIE8X3TBJKMN_PYBTki-cFXzDlaslJtvH8J3CO_KarU=.6b3bfd82-fefa-40f8-8f31-ae027d06bdeb@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <lIE8X3TBJKMN_PYBTki-cFXzDlaslJtvH8J3CO_KarU=.6b3bfd82-fefa-40f8-8f31-ae027d06bdeb@github.com>
Message-ID: <Kc91-F3CbcY7ARmsVADDj4ytfLb1ZRExopQNXk_i5_k=.45171275-acc3-4772-a59a-c93898fd24d8@github.com>

On Tue, 23 Sep 2025 17:48:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
>> 
>> After discussion with Erik, we propose the following behavior for the auto labeler:
>>  1. The auto labeler will never remove labels that have already been added.
>>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>>  3. Users can add any labels they want.
>>  
>>  Example:
>> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>>       (Current labels: ?hotspot-runtime?)
>> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>
> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 160:
> 
>> 158:                             newLabels.add(label);
>> 159:                         }
>> 160:                     }
> 
> I think this check needs to be applied on the initial run of the auto labeler as well. The user may have manually added labels already (which previously would disable the auto labeler), but now since we run it anyway, I think it needs to check for existing group labels.
> 
> I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.

Yes, you're right. I need to add the check for initial run as well.

> I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.
In this case, do you mean we just add the group label and keep the old labels?

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

PR Review Comment: https://git.openjdk.org/skara/pull/1741#discussion_r2373073642

From erikj at openjdk.org  Tue Sep 23 18:09:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 Sep 2025 18:09:53 GMT
Subject: RFR: 2591: Improve auto labeler
In-Reply-To: <Kc91-F3CbcY7ARmsVADDj4ytfLb1ZRExopQNXk_i5_k=.45171275-acc3-4772-a59a-c93898fd24d8@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <lIE8X3TBJKMN_PYBTki-cFXzDlaslJtvH8J3CO_KarU=.6b3bfd82-fefa-40f8-8f31-ae027d06bdeb@github.com>
 <Kc91-F3CbcY7ARmsVADDj4ytfLb1ZRExopQNXk_i5_k=.45171275-acc3-4772-a59a-c93898fd24d8@github.com>
Message-ID: <s2lt6BjFuWguJgANqgGfWZOzW1zaoD7BVcRIfCcKpMg=.22968d97-6176-42cb-8031-ad4c61c08bbf@github.com>

On Tue, 23 Sep 2025 17:57:16 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> bots/pr/src/main/java/org/openjdk/skara/bots/pr/LabelerWorkItem.java line 160:
>> 
>>> 158:                             newLabels.add(label);
>>> 159:                         }
>>> 160:                     }
>> 
>> I think this check needs to be applied on the initial run of the auto labeler as well. The user may have manually added labels already (which previously would disable the auto labeler), but now since we run it anyway, I think it needs to check for existing group labels.
>> 
>> I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.
>
> Yes, you're right. I need to add the check for initial run as well.
> 
>> I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.
> In this case, do you mean we just add the group label and keep the old labels?

Yes, I'm referring to 2 in the examples.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1741#discussion_r2373094429

From zsong at openjdk.org  Wed Sep 24 17:46:30 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 24 Sep 2025 17:46:30 GMT
Subject: RFR: 2591: Improve auto labeler [v2]
In-Reply-To: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
Message-ID: <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>

> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
> 
> After discussion with Erik, we propose the following behavior for the auto labeler:
>  1. The auto labeler will never remove labels that have already been added.
>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>  3. Users can add any labels they want.
>  
>  Example:
> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>       (Current labels: ?hotspot-runtime?)
> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)
> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)

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/1741/files
  - new: https://git.openjdk.org/skara/pull/1741/files/58223aa7..4edb400a

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

  Stats: 124 lines in 7 files changed: 92 ins; 17 del; 15 mod
  Patch: https://git.openjdk.org/skara/pull/1741.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1741/head:pull/1741

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

From erikj at openjdk.org  Wed Sep 24 17:46:31 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 Sep 2025 17:46:31 GMT
Subject: RFR: 2591: Improve auto labeler [v2]
In-Reply-To: <s2lt6BjFuWguJgANqgGfWZOzW1zaoD7BVcRIfCcKpMg=.22968d97-6176-42cb-8031-ad4c61c08bbf@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <lIE8X3TBJKMN_PYBTki-cFXzDlaslJtvH8J3CO_KarU=.6b3bfd82-fefa-40f8-8f31-ae027d06bdeb@github.com>
 <Kc91-F3CbcY7ARmsVADDj4ytfLb1ZRExopQNXk_i5_k=.45171275-acc3-4772-a59a-c93898fd24d8@github.com>
 <s2lt6BjFuWguJgANqgGfWZOzW1zaoD7BVcRIfCcKpMg=.22968d97-6176-42cb-8031-ad4c61c08bbf@github.com>
Message-ID: <Z-iG3U73X7tzKN2Y9ay1DG2WQP4v1z6rzr155S1ZkIc=.6808695f-feed-4c9b-b88a-2337000d2b57@github.com>

On Tue, 23 Sep 2025 18:07:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Yes, you're right. I need to add the check for initial run as well.
>> 
>>> I also think we are missing the case when an existing label would pair up with a new label to match a group. Then the new label should be upgraded to the group.
>> 
>> In this case, do you mean we just add the group label and keep the old labels?
>
> Yes, I'm referring to 2 in the examples.

I just realized that we may have misunderstood each other on 2.

> The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.

I think that even if only "hotspot-gc" was found in the new commits, then it should be upgraded to "hotspot" due to "hotspot-runtime" already being present, so new list of labels should still be ?hotspot-runtime?, ?hotspot?.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1741#discussion_r2373123866

From zsong at openjdk.org  Fri Sep 26 16:12:58 2025
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 26 Sep 2025 16:12:58 GMT
Subject: RFR: 2591: Improve auto labeler [v2]
In-Reply-To: <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
Message-ID: <rOye2fzj3xo3JWNzSiQoPta_nksOH4zb9Xrs6BzHhJA=.7ecc845b-46da-4a5c-ad40-c2ea50e93025@github.com>

On Wed, 24 Sep 2025 17:46:30 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
>> 
>> After discussion with Erik, we propose the following behavior for the auto labeler:
>>  1. The auto labeler will never remove labels that have already been added.
>>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>>  3. Users can add any labels they want.
>>  
>>  Example:
>> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>>       (Current labels: ?hotspot-runtime?)
>> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

@erikj79 Hi Erik, could you please review it again?

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

PR Comment: https://git.openjdk.org/skara/pull/1741#issuecomment-3339401234

From erikj at openjdk.org  Fri Sep 26 18:12:57 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 26 Sep 2025 18:12:57 GMT
Subject: RFR: 2591: Improve auto labeler [v2]
In-Reply-To: <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
Message-ID: <-MgdRMg5dQjHkhms-Pn9XBIep6VMyFnP0gXZVH_cE9Y=.eb5cb3ab-6929-4d24-b831-c915fd3e31c3@github.com>

On Wed, 24 Sep 2025 17:46:30 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
>> 
>> After discussion with Erik, we propose the following behavior for the auto labeler:
>>  1. The auto labeler will never remove labels that have already been added.
>>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>>  3. Users can add any labels they want.
>>  
>>  Example:
>> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>>       (Current labels: ?hotspot-runtime?)
>> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>
> 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/1741#pullrequestreview-3273345137

From zsong at openjdk.org  Mon Sep 29 16:04:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 29 Sep 2025 16:04:19 GMT
Subject: Integrated: 2591: Improve auto labeler
In-Reply-To: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
Message-ID: <FcqzD7v-4weedn04y2lZmZTNMcivXcq52So8F6B46w0=.1a760df8-84c4-407f-a20c-db85a91d76c6@github.com>

On Tue, 23 Sep 2025 16:47:33 GMT, Zhao Song <zsong at openjdk.org> wrote:

> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
> 
> After discussion with Erik, we propose the following behavior for the auto labeler:
>  1. The auto labeler will never remove labels that have already been added.
>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>  3. Users can add any labels they want.
>  
>  Example:
> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>       (Current labels: ?hotspot-runtime?)
> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)
> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>      (Current labels: ?hotspot-runtime?, ?hotspot?)

This pull request has now been integrated.

Changeset: 735a6b08
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/735a6b082e371e75fab5a6939de126905ab48e7c
Stats:     198 lines in 8 files changed: 115 ins; 40 del; 43 mod

2591: Improve auto labeler

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Mon Sep 29 16:04:19 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 29 Sep 2025 16:04:19 GMT
Subject: RFR: 2591: Improve auto labeler [v2]
In-Reply-To: <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
References: <L9lYnbuXybUiXFhflmtoZLmixp3AhRIkbfx4MAvZZ7I=.d80beebc-0ef8-4444-adb9-403c9c262b3d@github.com>
 <xeBpmif7YZU0tahNgbatxvAPegp0H2wNZN7BBTu9NP4=.e1fe9472-db56-488c-a315-7824ef1c2d0a@github.com>
Message-ID: <vUjKkxJQFWI7-a2hdu4qZ0WK6B5CHKyqZkl6zd_Tj4A=.09458089-b779-4e73-b8a2-8155efd5307c@github.com>

On Wed, 24 Sep 2025 17:46:30 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> After [SKARA-2588](https://bugs.openjdk.org/browse/SKARA-2588) is deployed, users are complaining about the behavior of auto labeler.
>> 
>> After discussion with Erik, we propose the following behavior for the auto labeler:
>>  1. The auto labeler will never remove labels that have already been added.
>>  2. The only case in which the auto labeler upgrades labels to group labels is when it detects a bunch of new labels to add. In this case, it will attempt to update the labels to group labels.
>>  3. Users can add any labels they want.
>>  
>>  Example:
>> 1. In the initial labeling, the auto labeler adds ?hotspot-runtime? to the PR.
>>       (Current labels: ?hotspot-runtime?)
>> 2. The user pushes three commits that touch ?hotspot-gc? and ?hotspot-jfr?. The auto labeler upgrades these to the group label ?hotspot? and adds it to the PR.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>> 3. Later, the user pushes a new commit touches only ?hotspot-gc?. The auto labeler will not add ?hotspot-gc? to the PR since ?hotspot? label is already there.
>>      (Current labels: ?hotspot-runtime?, ?hotspot?)
>
> 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/1741#issuecomment-3347825845