From erikj at openjdk.org  Fri May  2 22:41:00 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 2 May 2025 22:41:00 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
Message-ID: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>

The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.

If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.

The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.

This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.

When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.

A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation. We can count the number of commits in the repo using "git rev-list --count <ref list>". Then when we iterate over the commits from commitMetaData iterator, we only go until the map contains the same number of commits as the repo has. At that point we know we have added all new commits. Most of the time, the rev-list loop (in topo-order) should return all the new commits first. It's only if we have a branched history within a branch that commits could be iterated in a di
 fferent order, but worst case we just reprocess the unique ancestors of in each merge parent before we have passed all new commits.

While working on this I also realized that the current implementation has another flaw in that it assumes the list of branches given will always be the same. This is currently true in the affected bot, but that's not something the HostedRepository API should be assuming. I implemented a simple invalidation of the map in case the set of branches are different from the last call. This isn't an elegant solution but it at least keeps the API clean for now and if we actually need to handle this usecase, we can figure something else out then.

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

Commit messages:
 - SKARA-2491

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

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

From ihse at openjdk.org  Mon May  5 10:10:00 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 May 2025 10:10:00 GMT
Subject: RFR: 2480: Add new PR command /ping [v3]
In-Reply-To: <S8HsykKU-fRyVK_jIB0-6KU6vl_vMin7Z84uF38GuH4=.75b3a26d-14a9-49cf-b6be-851a9b736fb8@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
 <S8HsykKU-fRyVK_jIB0-6KU6vl_vMin7Z84uF38GuH4=.75b3a26d-14a9-49cf-b6be-851a9b736fb8@github.com>
Message-ID: <AJQK8vylRviEy2oitD8yMB7I2R9Ago5OV0t2-muYyNI=.115bea54-ee55-4eed-845f-8eedfbfa44c1@github.com>

On Wed, 30 Apr 2025 22:44:22 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This PR is trying to add a new pull request command "ping".
>> 
>> The reported wants to have a pull request command that can refresh the timeouts of the pr so that the pr wouldn't be closed by pullRequestPrunerBot.
>>  
>> The reported proposed to name the command "keep-alive" with alias "/ping", however, we store command names in an Enum class, so "keep-alive" is invalid. I think we just use "ping" as the command name.
>> 
>> Besides, I would like to let the command trigger a force update of the pr. Currently, there are some cases that skara bot won't re-evaluate the pr automatically and users need to do something to poke it(like editing the pr title), so I think it's better to have a pull request command to trigger the update.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

I agree with Erik that `/touch` would be a better name. The name `ping` to me indicates that you want to ask for reviewers or re-reviews, not that you want to silence the bot. If anything, that would have been a "pong" to the bot's ping. Or `/keepalive`, if dashes are problematic.

Can you also please update the comment the bot writes to indicate that the recommended action is to write `/touch` (or `/keepalive`)? Also, if it is possible to create a link such that clicking it will start writing this as a comment for you, that would be even better. Or, at least, make it easy to copy/paste the needed command.

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

PR Comment: https://git.openjdk.org/skara/pull/1716#issuecomment-2850517624
PR Comment: https://git.openjdk.org/skara/pull/1716#issuecomment-2850522348

From zsong at openjdk.org  Mon May  5 16:47:00 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 5 May 2025 16:47:00 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
In-Reply-To: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
Message-ID: <8-6CFnxxTDYz9H0_ymR4SRPHPEeNP5IgUnpnyoYQaXY=.8fb55446-484b-49e5-b68e-61528eb359b5@github.com>

On Fri, 2 May 2025 21:46:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.
> 
> If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.
> 
> The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.
> 
> This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.
> 
> When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.
> 
> A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation. We can count the numb...

Looks good overall!

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

> 645:             Set<Branch> branchSet = Set.copyOf(branches);
> 646:             if (!branchSet.equals(commitMapBranchSet)) {
> 647:                 log.info("Invalidating commitTitleToCommits map for branch set: " + branchSet + " old set: " + commitMapBranchSet);

Since commitMapBranchSet doesn't have an initial value, this log will also be printed during the initial run. Is this intentional?

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

PR Review: https://git.openjdk.org/skara/pull/1717#pullrequestreview-2815422159
PR Review Comment: https://git.openjdk.org/skara/pull/1717#discussion_r2073795369

From erikj at openjdk.org  Mon May  5 17:50:00 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 May 2025 17:50:00 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
In-Reply-To: <8-6CFnxxTDYz9H0_ymR4SRPHPEeNP5IgUnpnyoYQaXY=.8fb55446-484b-49e5-b68e-61528eb359b5@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
 <8-6CFnxxTDYz9H0_ymR4SRPHPEeNP5IgUnpnyoYQaXY=.8fb55446-484b-49e5-b68e-61528eb359b5@github.com>
Message-ID: <ig_5_No5ct84Z8_FmX8ODFeik5CxGzYT2Ozwh4_yElc=.f812dbd8-a2d4-436a-bcfa-39c0c5c464dc@github.com>

On Mon, 5 May 2025 16:43:11 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.
>> 
>> If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.
>> 
>> The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.
>> 
>> This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.
>> 
>> When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.
>> 
>> A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation....
>
> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 647:
> 
>> 645:             Set<Branch> branchSet = Set.copyOf(branches);
>> 646:             if (!branchSet.equals(commitMapBranchSet)) {
>> 647:                 log.info("Invalidating commitTitleToCommits map for branch set: " + branchSet + " old set: " + commitMapBranchSet);
> 
> Since commitMapBranchSet doesn't have an initial value, this log will also be printed during the initial run. Is this intentional?

Yes, kind of. I did note that it would happen and figured it was fine. I don't think it's worth complicating the code further to try to handle the first call differently.

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

PR Review Comment: https://git.openjdk.org/skara/pull/1717#discussion_r2073900450

From zsong at openjdk.org  Mon May  5 17:53:22 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 5 May 2025 17:53:22 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
In-Reply-To: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
Message-ID: <jzAgIeZHsZqu66r0DwjAhMOmok1cbs-UVaph7_QfXvc=.8ae92c8b-7e4c-4465-ba2d-6ee99f621852@github.com>

On Fri, 2 May 2025 21:46:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.
> 
> If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.
> 
> The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.
> 
> This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.
> 
> When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.
> 
> A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation. We can count the numb...

Marked as reviewed by zsong (Reviewer).

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

PR Review: https://git.openjdk.org/skara/pull/1717#pullrequestreview-2815611213

From zsong at openjdk.org  Mon May  5 17:53:22 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 5 May 2025 17:53:22 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
In-Reply-To: <ig_5_No5ct84Z8_FmX8ODFeik5CxGzYT2Ozwh4_yElc=.f812dbd8-a2d4-436a-bcfa-39c0c5c464dc@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
 <8-6CFnxxTDYz9H0_ymR4SRPHPEeNP5IgUnpnyoYQaXY=.8fb55446-484b-49e5-b68e-61528eb359b5@github.com>
 <ig_5_No5ct84Z8_FmX8ODFeik5CxGzYT2Ozwh4_yElc=.f812dbd8-a2d4-436a-bcfa-39c0c5c464dc@github.com>
Message-ID: <KAdHitM-KoNpCIZpzrJ__A1VAhPnIfQS_KkHlCK44EA=.27fc633a-d3ed-4e95-a48c-b3f3c79329f1@github.com>

On Mon, 5 May 2025 17:47:48 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> forge/src/main/java/org/openjdk/skara/forge/gitlab/GitLabRepository.java line 647:
>> 
>>> 645:             Set<Branch> branchSet = Set.copyOf(branches);
>>> 646:             if (!branchSet.equals(commitMapBranchSet)) {
>>> 647:                 log.info("Invalidating commitTitleToCommits map for branch set: " + branchSet + " old set: " + commitMapBranchSet);
>> 
>> Since commitMapBranchSet doesn't have an initial value, this log will also be printed during the initial run. Is this intentional?
>
> Yes, kind of. I did note that it would happen and figured it was fine. I don't think it's worth complicating the code further to try to handle the first call differently.

I'm also ok with it

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

PR Review Comment: https://git.openjdk.org/skara/pull/1717#discussion_r2073905841

From erikj at openjdk.org  Mon May  5 18:00:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 May 2025 18:00:53 GMT
Subject: RFR: 2491: GitLabRepository::recentCommitComments can miss commits
In-Reply-To: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
Message-ID: <45WLLCBJu43A8nLIwqP-AxUWWxFSl2JoHHhfIsgC22c=.47f0501f-0b09-4ba9-b9d0-4a8f7af9ff04@github.com>

On Fri, 2 May 2025 21:46:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.
> 
> If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.
> 
> The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.
> 
> This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.
> 
> When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.
> 
> A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation. We can count the numb...

Thanks!

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

PR Comment: https://git.openjdk.org/skara/pull/1717#issuecomment-2851869021

From erikj at openjdk.org  Mon May  5 18:00:53 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 May 2025 18:00:53 GMT
Subject: Integrated: 2491: GitLabRepository::recentCommitComments can miss
 commits
In-Reply-To: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
References: <IX_CYxD3gWrHrMdVxLcxivt1maloCHQjl7JtJjdqu0M=.f2ffcb0a-b492-4e40-8597-a58255f96716@github.com>
Message-ID: <JmmlijstrGBgL9qsO9tHcVIo0R03UOV04Mfa2veo3s8=.0ba9aaa4-16f0-465a-b783-7f5c1e229cbc@github.com>

On Fri, 2 May 2025 21:46:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The mechanism for polling GitLab for commit comments has a flaw that may cause it to start missing relevant comments. The underlying issue is that we are trusting timestamps on commits which may originate from a client machine, where the system clock may be wrong.
> 
> If a user changes their system clock to a date in the future and commits, that commit ends up having a future date. If this commit is then pushed to their personal fork and included in a merge request, then this commit will end up in a pr/X branch in the main/parent repository.
> 
> The rather convoluted mechanism for polling for commit comments (for the purpose of finding commit commands) for GitLab involves maintaining a mapping from commit title message to commit hash. This map is needed because the only way to find comments globally for a repository is to query for "events", and the event object only has the commit title, not the hash. Then for all possibly relevant events, we look up the commits in the map.
> 
> This map is initially generated from a local repository using a git command like this: "git rev-list <branch list>". After the first initialization, it is then updated using API calls to the server, querying for commits after a timestamp. The timestamp is the latest found already in the map. This is where the flaw lies. There is no guarantee that the timestamps are ever increasing, so once a commit with a faulty future timestamp ends up in the map, no new commits will ever be added when attempting to update it.
> 
> When I wrote this code, I think I assumed the timestamps would be strictly increasing because all official commits are generated by Skara. That still holds true for commits in repos and branches where we have strict Skara controlled pull requests. The problem here is that the API query does not limit commits to the specified branches, it gets all commits after the timestamp, which includes commits in pr/X branches as well as unreferenced commits.
> 
> A quick solution here would be to change the query to use branches. That would require doing a call per branch. I think a better solution would be to stick to one source for commits to the map, the local repository. It is already updated before each time we check for new commit comments. The challenge then is to identify the new commits to complement the map without having to rebuild it from scratch each time. I can't think of an exact way to accomplish this, but think we can get away with a good enough approximation. We can count the numb...

This pull request has now been integrated.

Changeset: c61ebd05
Author:    Erik Joelsson <erikj at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/c61ebd053f0c9de2ab2345e3ec4c01cbfb7455b9
Stats:     125 lines in 7 files changed: 92 ins; 20 del; 13 mod

2491: GitLabRepository::recentCommitComments can miss commits

Reviewed-by: zsong

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

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

From zsong at openjdk.org  Mon May  5 18:10:38 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 5 May 2025 18:10:38 GMT
Subject: RFR: 2480: Add new PR command /ping [v3]
In-Reply-To: <AJQK8vylRviEy2oitD8yMB7I2R9Ago5OV0t2-muYyNI=.115bea54-ee55-4eed-845f-8eedfbfa44c1@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
 <S8HsykKU-fRyVK_jIB0-6KU6vl_vMin7Z84uF38GuH4=.75b3a26d-14a9-49cf-b6be-851a9b736fb8@github.com>
 <AJQK8vylRviEy2oitD8yMB7I2R9Ago5OV0t2-muYyNI=.115bea54-ee55-4eed-845f-8eedfbfa44c1@github.com>
Message-ID: <qMzok634CHz_HNYnerphcVRI6idAJW1JCb4Y78_egIg=.584b0102-c7eb-4650-8163-3d00e302979c@github.com>

On Mon, 5 May 2025 10:05:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I agree with Erik that `/touch` would be a better name. The name `ping` to me indicates that you want to ask for reviewers or re-reviews, not that you want to silence the bot. If anything, that would have been a "pong" to the bot's ping. Or `/keepalive`, if dashes are problematic.

Since Erik and you have the same idea, I will rename the command to /touch

> Can you also please update the comment the bot writes to indicate that the recommended action is to write `/touch` (or `/keepalive`)? Also, if it is possible to create a link such that clicking it will start writing this as a comment for you, that would be even better. Or, at least, make it easy to copy/paste the needed command.

Yes, it's a good idea, will update the comment from PullRequestPrunerBot

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

PR Comment: https://git.openjdk.org/skara/pull/1716#issuecomment-2851896781
PR Comment: https://git.openjdk.org/skara/pull/1716#issuecomment-2851899390

From zsong at openjdk.org  Mon May  5 20:14:40 2025
From: zsong at openjdk.org (Zhao Song)
Date: Mon, 5 May 2025 20:14:40 GMT
Subject: RFR: 2480: Add new PR command /touch [v4]
In-Reply-To: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
Message-ID: <peamgUoERFmWOkrwefUnsUNg3oWTA0X22r4ztHmiIm4=.72576f90-68b3-400f-8b1c-a1030a9759ba@github.com>

> This PR is trying to add a new pull request command "ping".
> 
> The reported wants to have a pull request command that can refresh the timeouts of the pr so that the pr wouldn't be closed by pullRequestPrunerBot.
>  
> The reported proposed to name the command "keep-alive" with alias "/ping", however, we store command names in an Enum class, so "keep-alive" is invalid. I think we just use "ping" as the command name.
> 
> Besides, I would like to let the command trigger a force update of the pr. Currently, there are some cases that skara bot won't re-evaluate the pr automatically and users need to do something to poke it(like editing the pr title), so I think it's better to have a pull request command to trigger the update.

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/1716/files
  - new: https://git.openjdk.org/skara/pull/1716/files/206d55e6..83070162

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

  Stats: 148 lines in 8 files changed: 67 ins; 68 del; 13 mod
  Patch: https://git.openjdk.org/skara/pull/1716.diff
  Fetch: git fetch https://git.openjdk.org/skara.git pull/1716/head:pull/1716

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

From erikj at openjdk.org  Mon May  5 21:46:38 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 5 May 2025 21:46:38 GMT
Subject: RFR: 2480: Add new PR command /touch [v4]
In-Reply-To: <peamgUoERFmWOkrwefUnsUNg3oWTA0X22r4ztHmiIm4=.72576f90-68b3-400f-8b1c-a1030a9759ba@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
 <peamgUoERFmWOkrwefUnsUNg3oWTA0X22r4ztHmiIm4=.72576f90-68b3-400f-8b1c-a1030a9759ba@github.com>
Message-ID: <OCOhoX592fQr3Hz20fiCOwLAnT9Qv9Qv92EOruEXRFk=.8ab3e821-0185-4b4f-9d9d-136ab051faa9@github.com>

On Mon, 5 May 2025 20:14:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This PR is trying to add a new pull request command "touch".
>> 
>> The reported wants to have a pull request command that can refresh the timeouts of the pr so that the pr wouldn't be closed by pullRequestPrunerBot.
>>  
>> The reported proposed to name the command "keep-alive" with alias "/ping", however, we store command names in an Enum class, so "keep-alive" is invalid. I think we just use "touch" as the command name.
>> 
>> Besides, I would like to let the command trigger a force update of the pr. Currently, there are some cases that skara bot won't re-evaluate the pr automatically and users need to do something to poke it(like editing the pr title), so I think it's better to have a pull request command to trigger the update.
>
> 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/1716#pullrequestreview-2816184078

From zsong at openjdk.org  Tue May  6 16:24:37 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 6 May 2025 16:24:37 GMT
Subject: RFR: 2480: Add new PR command /touch [v4]
In-Reply-To: <peamgUoERFmWOkrwefUnsUNg3oWTA0X22r4ztHmiIm4=.72576f90-68b3-400f-8b1c-a1030a9759ba@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
 <peamgUoERFmWOkrwefUnsUNg3oWTA0X22r4ztHmiIm4=.72576f90-68b3-400f-8b1c-a1030a9759ba@github.com>
Message-ID: <GjC7xxGeCAinE12IwANFIhJbMVON0pH-ViDwvEDWslY=.ce0c6f6d-3911-41de-a021-18de64c9f5f2@github.com>

On Mon, 5 May 2025 20:14:40 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> This PR is trying to add a new pull request command "touch".
>> 
>> The reported wants to have a pull request command that can refresh the timeouts of the pr so that the pr wouldn't be closed by pullRequestPrunerBot.
>>  
>> The reported proposed to name the command "keep-alive" with alias "/ping", however, we store command names in an Enum class, so "keep-alive" is invalid. I think we just use "touch" as the command name.
>> 
>> Besides, I would like to let the command trigger a force update of the pr. Currently, there are some cases that skara bot won't re-evaluate the pr automatically and users need to do something to poke it(like editing the pr title), so I think it's better to have a pull request command to trigger the update.
>
> Zhao Song has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comment

Thank you!

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

PR Comment: https://git.openjdk.org/skara/pull/1716#issuecomment-2855193988

From zsong at openjdk.org  Tue May  6 16:24:37 2025
From: zsong at openjdk.org (Zhao Song)
Date: Tue, 6 May 2025 16:24:37 GMT
Subject: Integrated: 2480: Add new PR command /touch
In-Reply-To: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
References: <xCC54kLxm0t04mxQCMmXjb3CgqCITOX9HyHoiBAIqBw=.77ce0d34-c24f-409c-a8ed-3e6396b9ee2f@github.com>
Message-ID: <CG0Gqp-ecxCub7VrhAsyvDSfNvfKTQJ-TJZtZfBuxpA=.635f61ed-0b28-492c-b9f4-7c81246ed97a@github.com>

On Wed, 30 Apr 2025 21:31:18 GMT, Zhao Song <zsong at openjdk.org> wrote:

> This PR is trying to add a new pull request command "touch".
> 
> The reported wants to have a pull request command that can refresh the timeouts of the pr so that the pr wouldn't be closed by pullRequestPrunerBot.
>  
> The reported proposed to name the command "keep-alive" with alias "/ping", however, we store command names in an Enum class, so "keep-alive" is invalid. I think we just use "touch" as the command name.
> 
> Besides, I would like to let the command trigger a force update of the pr. Currently, there are some cases that skara bot won't re-evaluate the pr automatically and users need to do something to poke it(like editing the pr title), so I think it's better to have a pull request command to trigger the update.

This pull request has now been integrated.

Changeset: b99d1edf
Author:    Zhao Song <zsong at openjdk.org>
URL:       https://git.openjdk.org/skara/commit/b99d1edfea89cb1dabbf507953b660feaa78a486
Stats:     104 lines in 7 files changed: 96 ins; 0 del; 8 mod

2480: Add new PR command /touch

Reviewed-by: erikj

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

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

From zsong at openjdk.org  Wed May  7 17:28:04 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 7 May 2025 17:28:04 GMT
Subject: RFR: 2495: Touch Command should return early on closed pull requests
Message-ID: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>

In [SKARA-2480](https://bugs.openjdk.org/browse/SKARA-2480), I added a new pull request command /touch. When the /touch command is issued on a closed pull request, Skara should return immediately. I forgot to add the return statement in that logic.

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

Commit messages:
 - SKARA-2495

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

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

From erikj at openjdk.org  Wed May  7 17:45:14 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 7 May 2025 17:45:14 GMT
Subject: RFR: 2495: Touch Command should return early on closed pull
 requests
In-Reply-To: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
References: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
Message-ID: <NqsKCELM_Fr_tbqPKk__uGX_ui9-0fdmbmc7mSvDRCc=.9a624a83-7f40-4347-bfaa-12c2a586ee67@github.com>

On Wed, 7 May 2025 17:22:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-2480](https://bugs.openjdk.org/browse/SKARA-2480), I added a new pull request command /touch. When the /touch command is issued on a closed pull request, Skara should return immediately. I forgot to add the return statement in that logic.

Marked as reviewed by erikj (Lead).

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

PR Review: https://git.openjdk.org/skara/pull/1718#pullrequestreview-2822658906

From zsong at openjdk.org  Wed May  7 17:45:14 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 7 May 2025 17:45:14 GMT
Subject: RFR: 2495: Touch Command should return early on closed pull
 requests
In-Reply-To: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
References: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
Message-ID: <H1q4e_TuKkUa1D7buTC1hPQ6ucSm6GJ6tHEoHPTlgpk=.88a648df-1505-453e-8af8-baafbaa55989@github.com>

On Wed, 7 May 2025 17:22:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-2480](https://bugs.openjdk.org/browse/SKARA-2480), I added a new pull request command /touch. When the /touch command is issued on a closed pull request, Skara should return immediately. I forgot to add the return statement in that logic.

Thank you for the quick review!

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

PR Comment: https://git.openjdk.org/skara/pull/1718#issuecomment-2859567131

From zsong at openjdk.org  Wed May  7 17:45:14 2025
From: zsong at openjdk.org (Zhao Song)
Date: Wed, 7 May 2025 17:45:14 GMT
Subject: Integrated: 2495: Touch Command should return early on closed pull
 requests
In-Reply-To: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
References: <gWuHHaiGn4IjM7Gib5FV0YtRg0oWRSJXbWUsIEuLAkU=.0f717d04-81a1-455a-9085-522cd27d361e@github.com>
Message-ID: <_irzFwA1XiRuxBB_DfvXvw9jNV9feiuw_u38QsXge-s=.1c44e1db-2446-4c9d-864d-903e93599cbe@github.com>

On Wed, 7 May 2025 17:22:50 GMT, Zhao Song <zsong at openjdk.org> wrote:

> In [SKARA-2480](https://bugs.openjdk.org/browse/SKARA-2480), I added a new pull request command /touch. When the /touch command is issued on a closed pull request, Skara should return immediately. I forgot to add the return statement in that logic.

This pull request has now been integrated.

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

2495: Touch Command should return early on closed pull requests

Reviewed-by: erikj

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

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