From jwaters at openjdk.org Sun Jan 1 17:06:25 2023 From: jwaters at openjdk.org (Julian Waters) Date: Sun, 1 Jan 2023 17:06:25 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v52] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Extraneous import - Fortify markIntegratedAndMerged ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/076b3489..cc4407e7 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=51 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=50-51 Stats: 60 lines in 1 file changed: 51 ins; 0 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Mon Jan 2 12:02:40 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 2 Jan 2023 12:02:40 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v53] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Extra assertions ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/cc4407e7..a37fb02b Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=52 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=51-52 Stats: 26 lines in 1 file changed: 3 ins; 0 del; 23 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Tue Jan 3 01:33:07 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 3 Jan 2023 01:33:07 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v54] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Checks should also be done before rebasing and integration ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/a37fb02b..b411ed31 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=53 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=52-53 Stats: 52 lines in 2 files changed: 49 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Tue Jan 3 01:38:26 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 3 Jan 2023 01:38:26 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v55] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Whitespace ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/b411ed31..1dd18829 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=54 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=53-54 Stats: 14 lines in 2 files changed: 2 ins; 6 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Tue Jan 3 01:47:10 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 3 Jan 2023 01:47:10 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v56] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit: Squash ------------- Changes: https://git.openjdk.org/skara/pull/1409/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=55 Stats: 237 lines in 6 files changed: 181 ins; 21 del; 35 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Tue Jan 3 06:07:50 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 3 Jan 2023 06:07:50 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: References: Message-ID: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Ensure fetch properly advances local branch ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/ffbb82f9..e748d2fb Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=56 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=55-56 Stats: 12 lines in 2 files changed: 1 ins; 0 del; 11 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From erikj at openjdk.org Tue Jan 3 14:23:07 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jan 2023 14:23:07 GMT Subject: RFR: GitRepository#revert does not work as intended In-Reply-To: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> References: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> Message-ID: On Sun, 25 Dec 2022 19:49:01 GMT, Julian Waters wrote: > The `Repository#revert` interface is meant to allow for rolling the Repository back to a specific commit, but the Git implementation in `GitRepository#revert` implements this via a checkout, which can cause issues, especially with newer versions of Git where it doesn't have any effect at all. More appropriate would be using `git restore --source` to implement the GitRepository variant instead, which is actually the encouraged way to do so nowadays This looks correct. It doesn't seem like we are using this call anywhere currently for git repos, so this change shouldn't affect any current functionality. ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.org/skara/pull/1450 From zsong at openjdk.org Tue Jan 3 17:22:42 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 3 Jan 2023 17:22:42 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn Message-ID: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, this behavior does not align with the original logic. The correct logic is that if one of the CSR issues is withdrawn, CSR bot should not remove the CSR label automatically. In this case, only reviewer uses '/csr unneeded' command will be able to remove the CSR label. ------------- Commit messages: - SKARA-1729 Changes: https://git.openjdk.org/skara/pull/1451/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1451&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1729 Stats: 12 lines in 2 files changed: 8 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1451.diff Fetch: git fetch https://git.openjdk.org/skara pull/1451/head:pull/1451 PR: https://git.openjdk.org/skara/pull/1451 From erikj at openjdk.org Tue Jan 3 17:28:43 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jan 2023 17:28:43 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version Message-ID: In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: "prbranch": { "protect": true, }, The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. ------------- Commit messages: - Restore manual annotation - Must encode refs in URLs - SKARA-1173 Changes: https://git.openjdk.org/skara/pull/1452/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1452&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1173 Stats: 128 lines in 9 files changed: 122 ins; 1 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1452.diff Fetch: git fetch https://git.openjdk.org/skara pull/1452/head:pull/1452 PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Tue Jan 3 17:37:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jan 2023 17:37:18 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: > In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: > > > "prbranch": { > "protect": true, > }, > > The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) > > I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Fix import ------------- Changes: - all: https://git.openjdk.org/skara/pull/1452/files - new: https://git.openjdk.org/skara/pull/1452/files/43322c9f..68619fab Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1452&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1452&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1452.diff Fetch: git fetch https://git.openjdk.org/skara pull/1452/head:pull/1452 PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Tue Jan 3 18:19:16 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 3 Jan 2023 18:19:16 GMT Subject: RFR: 1731: Improve RestRequestCache rate limiter Message-ID: In the RestRequestCache, we are trying to limit non GET calls for a specific host and user to one call per second (and all calls, including GET, for a specific host and user, need to be serialized). This throttling is based on recommendations from GitHub (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-abuse-rate-limits). The current implementation isn't really doing that however. Calls are serialized, but depending on timing, we can definitely send more than one non GET call per second, at least in bursts. This patch tries to rework this, using two locks. During high contention, it's possible that this new implementation will be less favorable to non GET calls than the current implementation, but I'm pretty sure we will at least adhere to the recommendation of performing at most one non-GET call per second. See bug for breakdown of locking order. ------------- Commit messages: - SKARA-1731 Changes: https://git.openjdk.org/skara/pull/1453/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1453&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1731 Stats: 32 lines in 1 file changed: 12 ins; 10 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1453.diff Fetch: git fetch https://git.openjdk.org/skara pull/1453/head:pull/1453 PR: https://git.openjdk.org/skara/pull/1453 From zsong at openjdk.org Wed Jan 4 00:09:42 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 4 Jan 2023 00:09:42 GMT Subject: RFR: 1731: Improve RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:15:36 GMT, Erik Joelsson wrote: > In the RestRequestCache, we are trying to limit non GET calls for a specific host and user to one call per second (and all calls, including GET, for a specific host and user, need to be serialized). This throttling is based on recommendations from GitHub (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-abuse-rate-limits). The current implementation isn't really doing that however. Calls are serialized, but depending on timing, we can definitely send more than one non GET call per second, at least in bursts. > > This patch tries to rework this, using two locks. During high contention, it's possible that this new implementation will be less favorable to non GET calls than the current implementation, but I'm pretty sure we will at least adhere to the recommendation of performing at most one non-GET call per second. See bug for breakdown of locking order. It really took me a while to understand how it was able to send two non-GET requests in one second, but once I understood it, I checked your revision and I believe that the clever two-lock solution will solve the problem perfectly. ------------- Marked as reviewed by zsong (Committer). PR: https://git.openjdk.org/skara/pull/1453 From jwaters at openjdk.org Wed Jan 4 08:53:40 2023 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 4 Jan 2023 08:53:40 GMT Subject: RFR: GitRepository#revert does not work as intended In-Reply-To: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> References: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> Message-ID: On Sun, 25 Dec 2022 19:49:01 GMT, Julian Waters wrote: > The `Repository#revert` interface is meant to allow for rolling the Repository back to a specific commit, but the Git implementation in `GitRepository#revert` implements this via a checkout, which can cause issues, especially with newer versions of Git where it doesn't have any effect at all. More appropriate would be using `git restore --source` to implement the GitRepository variant instead, which is actually the encouraged way to do so nowadays Thanks for the review Erik ------------- PR: https://git.openjdk.org/skara/pull/1450 From duke at openjdk.org Thu Jan 5 14:04:40 2023 From: duke at openjdk.org (altrisi) Date: Thu, 5 Jan 2023 14:04:40 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Tue, 3 Jan 2023 06:07:50 GMT, Julian Waters wrote: >> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. >> >> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. >> >> >> https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Ensure fetch properly advances local branch Is there any reason why Skara doesn't use (or emulate in a way that is detected if there's no direct way/endpoint) what GitHub does when using the "Rebase and Merge" button? That marks pull requests as merged unless it's changed recently, without making the rebase directly in the PR branch. ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Jan 5 15:24:04 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 5 Jan 2023 15:24:04 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Thu, 5 Jan 2023 14:02:23 GMT, altrisi wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Ensure fetch properly advances local branch > > Is there any reason why Skara doesn't use (or emulate in a way that is detected if there's no direct way/endpoint) what GitHub does when using the "Rebase and Merge" button? > > That marks pull requests as merged unless it's changed recently, without making the rebase directly in the PR branch. @altrisi could you elaborate further on this "Rebase and Merge" feature for GitHub? Do you mean the usual rebasing and merging of the PR's actual sequence of commits directly into the repository, or is this part of GitHub's indirect merge logic (where the Pull Request does not need to be actually merged into the target branch for it to be marked as merged, I am aware that there are a few circumstances where GitHub will currently do that) that I haven't heard of? If it's the latter, I am pretty curious and interested ------------- PR: https://git.openjdk.org/skara/pull/1409 From duke at openjdk.org Thu Jan 5 16:59:38 2023 From: duke at openjdk.org (altrisi) Date: Thu, 5 Jan 2023 16:59:38 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Tue, 3 Jan 2023 06:07:50 GMT, Julian Waters wrote: >> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. >> >> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. >> >> >> https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Ensure fetch properly advances local branch I'm talking about the `Rebase and merge` option on the dropdown when manually merging a PR from the web UI, just wondering if there's a reason not to use that or something similar in Skara. I don't know if it's exposed to apps, or if Skara has more requirements that feature doesn't meet though. ------------- PR: https://git.openjdk.org/skara/pull/1409 From duke at openjdk.org Thu Jan 5 17:27:51 2023 From: duke at openjdk.org (altrisi) Date: Thu, 5 Jan 2023 17:27:51 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Tue, 3 Jan 2023 06:07:50 GMT, Julian Waters wrote: >> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. >> >> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. >> >> >> https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Ensure fetch properly advances local branch Sorry I've said it wrong, I was referring to Squash and merge this entire time, for some reason confused it with rebase. ------------- PR: https://git.openjdk.org/skara/pull/1409 From erikj at openjdk.org Thu Jan 5 18:13:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 5 Jan 2023 18:13:41 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Tue, 3 Jan 2023 06:07:50 GMT, Julian Waters wrote: >> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. >> >> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. >> >> >> https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Ensure fetch properly advances local branch > Is there any reason why Skara doesn't use (or emulate in a way that is detected if there's no direct way/endpoint) what GitHub does when using the "Rebase and Merge" button? > > That marks pull requests as merged unless it's changed recently, without making the rebase directly in the PR branch. > Sorry I've said it wrong, I was referring to Squash and merge this entire time, for some reason confused it with rebase. An important design choice in Skara was to make sure it was compatible with at least 2 different hosting providers (currently github and gitlab) so that we did not build in a hard dependency on a single provider. This means we can't lean too heavily on functionality specific to any one provider, but rather prefer to implement general solutions that can be used with both/all. I can't say if there is anything in particular that the GitHub API of today is missing that would hinder us from using it for squash merging PRs, at least not without spending a considerable amount of time investigating. I'm pretty sure the original implementors of Skara found that the current strategy was necessary to support the OpenJDK process on both GitLab and GitHub at the time it was implemented, and I trust their judgement. ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Jan 5 19:54:02 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 5 Jan 2023 19:54:02 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Thu, 5 Jan 2023 18:11:29 GMT, Erik Joelsson wrote: > I can't say if there is anything in particular that the GitHub API of today is missing that would hinder us from using it for squash merging PRs, at least not without spending a considerable amount of time investigating. >From my time experimenting with the APIs of both hosts, the only thing really missing is the ability to set the committer and author of the actual Pull Request, like we currently do in `CheckablePullRequest`. Otherwise quite a lot of the existing logic could (with substantial effort) be migrated to use the Pull Request API instead of the current strategy of creating a commit on our own local repositories before pushing to remote ("commit_title" and "commit_message" can already be set from the API for instance, same with GitLab). A rather extreme option to circumvent this issue if we really wanted to utilize the host's merging abilities as altrisi suggests would be giving Skara the ability to force the Pull Request itself (the branch that contains its commits in essence) to allow edits from the pr bot (both GitHub and GitLab support doing so) and pushing the commit from our own local repo into the PR instead, before then merging it through the API as if from the UI as per normal ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Thu Jan 5 19:57:23 2023 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 5 Jan 2023 19:57:23 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57] In-Reply-To: References: <4yftmvUhZI_ehEZekFAN0NugiRJDaqfPexmVwEh6eA4=.666008af-89f4-489c-8a7c-917670db1f35@github.com> Message-ID: On Thu, 5 Jan 2023 18:11:29 GMT, Erik Joelsson wrote: > I can't say if there is anything in particular that the GitHub API of today is missing that would hinder us from using it for squash merging PRs, at least not without spending a considerable amount of time investigating. >From my time experimenting with the APIs of both hosts, the only thing really missing is the ability to set the committer and author of the actual Pull Request, like we currently do in `CheckablePullRequest`. Otherwise quite a lot of the existing logic could (with substantial effort) be migrated to use the Pull Request API instead of the current strategy of creating a commit on our own local repositories before pushing to remote ("commit_title" and "commit_message" can already be set from the API for instance, same with GitLab). A rather extreme option to circumvent this issue if we really wanted to utilize the host's merging abilities as altrisi suggests would be giving Skara the ability to force the Pull Request itself (the branch that contains its commits in essence) to allow edits from the pr bot (both GitHub and GitLab support doing so) and pushing the commit from our own local repo into the PR instead, before then merging it through the API as if from the UI as per normal (Side note: Doing it this way would also result in having to make messy decisions on what to do with the existing prepush comment system and the handling for the "Pushed as commit" comments, since those would no longer be accurate in such a scenario) ------------- PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Mon Jan 9 07:33:17 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 9 Jan 2023 07:33:17 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v58] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Copy changes to Pull Request before integration ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/e748d2fb..21167d4a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=57 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=56-57 Stats: 181 lines in 6 files changed: 29 ins; 110 del; 42 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From jwaters at openjdk.org Mon Jan 9 09:00:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 9 Jan 2023 09:00:41 GMT Subject: RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v59] In-Reply-To: References: Message-ID: > Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead. > > Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was. > > > https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172 Julian Waters has updated the pull request incrementally with two additional commits since the last revision: - Resolve Conflicts - Integrate via indirect merge ------------- Changes: - all: https://git.openjdk.org/skara/pull/1409/files - new: https://git.openjdk.org/skara/pull/1409/files/21167d4a..52af6bb2 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=58 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1409&range=57-58 Stats: 22 lines in 2 files changed: 16 ins; 4 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1409.diff Fetch: git fetch https://git.openjdk.org/skara pull/1409/head:pull/1409 PR: https://git.openjdk.org/skara/pull/1409 From zsong at openjdk.org Mon Jan 9 20:15:10 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 9 Jan 2023 20:15:10 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn [v2] In-Reply-To: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> Message-ID: > While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. > > Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, this behavior does not align with the original logic. The correct logic is that if one of the CSR issues is withdrawn, CSR bot should not remove the CSR label automatically. In this case, only reviewer uses '/csr unneeded' command will be able to remove the CSR label. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: changed the logic about removing CSR label when pr contains withdrawn csr issue ------------- Changes: - all: https://git.openjdk.org/skara/pull/1451/files - new: https://git.openjdk.org/skara/pull/1451/files/0b99714f..4b9f58f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1451&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1451&range=00-01 Stats: 26 lines in 2 files changed: 19 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1451.diff Fetch: git fetch https://git.openjdk.org/skara pull/1451/head:pull/1451 PR: https://git.openjdk.org/skara/pull/1451 From erikj at openjdk.org Mon Jan 9 21:46:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 9 Jan 2023 21:46:39 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn [v2] In-Reply-To: References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> Message-ID: <2IMtQU6tiMBJOm0eOlKOnqIBDcbV1WKofeNDnru80ec=.2abef7ed-f09a-4525-a871-1d8f30d53771@github.com> On Mon, 9 Jan 2023 20:15:10 GMT, Zhao Song wrote: >> While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. >> >> Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, if the CSR label is added via using '/csr needed' command and the pr contains withdrawn CSR issues, the CSR should not remove the CSR label. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > changed the logic about removing CSR label when pr contains withdrawn csr issue bots/csr/src/main/java/org/openjdk/skara/bots/csr/PullRequestWorkItem.java line 267: > 265: * Determine whether the CSR label is added via '/csr needed' command > 266: */ > 267: private boolean CSRNeeded(List comments) { Please always use lower case at start of method. I would suggest `isCSRNeeded` bots/csr/src/main/java/org/openjdk/skara/bots/csr/PullRequestWorkItem.java line 277: > 275: } > 276: } > 277: return CSRNeededCommentCount > 0; I don't think this should be determined by count. The last comment with `` in it is the one that is currently in effect. ------------- PR: https://git.openjdk.org/skara/pull/1451 From zsong at openjdk.org Mon Jan 9 22:02:10 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 9 Jan 2023 22:02:10 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn [v2] In-Reply-To: <2IMtQU6tiMBJOm0eOlKOnqIBDcbV1WKofeNDnru80ec=.2abef7ed-f09a-4525-a871-1d8f30d53771@github.com> References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> <2IMtQU6tiMBJOm0eOlKOnqIBDcbV1WKofeNDnru80ec=.2abef7ed-f09a-4525-a871-1d8f30d53771@github.com> Message-ID: On Mon, 9 Jan 2023 21:43:50 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> changed the logic about removing CSR label when pr contains withdrawn csr issue > > bots/csr/src/main/java/org/openjdk/skara/bots/csr/PullRequestWorkItem.java line 277: > >> 275: } >> 276: } >> 277: return CSRNeededCommentCount > 0; > > I don't think this should be determined by count. The last comment with `` in it is the one that is currently in effect. Agree with you, I will change it. ------------- PR: https://git.openjdk.org/skara/pull/1451 From zsong at openjdk.org Mon Jan 9 22:17:46 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 9 Jan 2023 22:17:46 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn [v3] In-Reply-To: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> Message-ID: > While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. > > Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, if the CSR label is added via using '/csr needed' command and the pr contains withdrawn CSR issues, the CSR should not remove the CSR label. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: change the logic about the method isCSRNeeded ------------- Changes: - all: https://git.openjdk.org/skara/pull/1451/files - new: https://git.openjdk.org/skara/pull/1451/files/4b9f58f0..5aad0337 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1451&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1451&range=01-02 Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1451.diff Fetch: git fetch https://git.openjdk.org/skara pull/1451/head:pull/1451 PR: https://git.openjdk.org/skara/pull/1451 From erikj at openjdk.org Mon Jan 9 23:30:49 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 9 Jan 2023 23:30:49 GMT Subject: RFR: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn [v3] In-Reply-To: References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> Message-ID: On Mon, 9 Jan 2023 22:17:46 GMT, Zhao Song wrote: >> While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. >> >> Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, if the CSR label is added via using '/csr needed' command and the pr contains withdrawn CSR issues, the CSR should not remove the CSR label. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > change the logic about the method isCSRNeeded Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1451 From zsong at openjdk.org Mon Jan 9 23:39:29 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 9 Jan 2023 23:39:29 GMT Subject: Integrated: 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn In-Reply-To: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> References: <615c7ljGalRNkUugRypTmlELrDMuK2eiVnVeiFqgNxY=.87dfaa40-cc54-4e67-81a3-fb5f905870d1@github.com> Message-ID: <2K8gRymbIckBHJqbo6ySadJCKnNKwXaKLB3mG7ap1_U=.338cbdad-7939-47d8-89f1-7905137648ca@github.com> On Tue, 3 Jan 2023 16:23:05 GMT, Zhao Song wrote: > While testing [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), I discovered a bug in the PullRequestWorkItem of the CSR bot. > > Currently, the CSR bot would remove CSR label if all the CSR issues of the pr is closed(whether approved or withdrawn). However, if the CSR label is added via using '/csr needed' command and the pr contains withdrawn CSR issues, the CSR should not remove the CSR label. This pull request has now been integrated. Changeset: f904c415 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/f904c415b13ac89eef78a0823a31c3bcd580dfdd Stats: 30 lines in 2 files changed: 27 ins; 0 del; 3 mod 1729: CSR bot should not remove CSR label if one of the CSR issues is withdrawn Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1451 From jwaters at openjdk.org Tue Jan 10 01:09:21 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 10 Jan 2023 01:09:21 GMT Subject: RFR: GitRepository#revert does not work as intended In-Reply-To: References: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> Message-ID: <9UEDy87S_KxdNFxIdSdiqAW5qO5ZVnQGKrJKGULCicU=.ce4437eb-f2d5-4e1c-a39c-8c2478396d18@github.com> On Tue, 3 Jan 2023 14:20:47 GMT, Erik Joelsson wrote: >> The `Repository#revert` interface is meant to allow for rolling the Repository back to a specific commit, but the Git implementation in `GitRepository#revert` implements this via a checkout, which can cause issues, especially with newer versions of Git where it doesn't have any effect at all. More appropriate would be using `git restore --source` to implement the GitRepository variant instead, which is actually the encouraged way to do so nowadays > > This looks correct. It doesn't seem like we are using this call anywhere currently for git repos, so this change shouldn't affect any current functionality. @erikj79 Could I trouble you for a sponsor? Sorry for the trouble! ------------- PR: https://git.openjdk.org/skara/pull/1450 From jwaters at openjdk.org Tue Jan 10 15:03:58 2023 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 10 Jan 2023 15:03:58 GMT Subject: Integrated: GitRepository#revert does not work as intended In-Reply-To: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> References: <0zkAqsBtkhRC-887Vz7beYeclV8sDu5GHebMLgKVbMk=.176419bd-927e-492e-aff2-a9f20f270466@github.com> Message-ID: On Sun, 25 Dec 2022 19:49:01 GMT, Julian Waters wrote: > The `Repository#revert` interface is meant to allow for rolling the Repository back to a specific commit, but the Git implementation in `GitRepository#revert` implements this via a checkout, which can cause issues, especially with newer versions of Git where it doesn't have any effect at all. More appropriate would be using `git restore --source` to implement the GitRepository variant instead, which is actually the encouraged way to do so nowadays This pull request has now been integrated. Changeset: d5e6e591 Author: Julian Waters Committer: Erik Joelsson URL: https://git.openjdk.org/skara/commit/d5e6e591bdde15ecdcd3e5d0391e3713f433e745 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod GitRepository#revert does not work as intended Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1450 From zsong at openjdk.org Tue Jan 10 23:45:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 10 Jan 2023 23:45:24 GMT Subject: RFR: 1741: Change the logic of removing CSR label when CSR label is added via '/csr needed' command Message-ID: <7bqJDsV6yebawMf_Uxq__qxa3CUq-TIzDU04AzH0VWk=.bdbb5f0b-045b-4d4c-a2f9-0b09c094a1a4@github.com> Assuming there is such a situation: 1. One pr solves issue1 and issue2. 2. One user thought this pr needs CSR Issue and commented '/csr needed'. 3. Author of this pr created csr1 of issue1, but then he thought it is not right to create csr of issue1 and withdrawn csr1. 4. Author of this pr created csr2 of issue2 and csr2 got approved. 5. In my opinion, the csr label should be removed(But due to [SKARA-1729](https://bugs.openjdk.org/browse/SKARA-1729), it is not removed) To sum, There are two ways that CSR label can be added to a PR 1. via '/csr needed' command 2. A CSR issue is discovered For the first case, if the CSR label is added via '/csr needed', there will be a CSR_NEEDED_MARKER. In this case, if we want to remove the csr label. there are two ways (1) No active CSR Issue exists and use '/csr unneeded' command (2) all of the CSR issues are approved or withdrawn(at least 1 CSR Issue is approved) For the second case, if the CSR label is added because a CSR Issue is discovered, there will not be CSR_NEEDED_MARKER. In this case, if we want to remove the csr label, there is only one way (1) all of the CSR issues are approved or withdrawn ------------- Commit messages: - SKARA-1741 Changes: https://git.openjdk.org/skara/pull/1454/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1454&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1741 Stats: 15 lines in 2 files changed: 2 ins; 3 del; 10 mod Patch: https://git.openjdk.org/skara/pull/1454.diff Fetch: git fetch https://git.openjdk.org/skara pull/1454/head:pull/1454 PR: https://git.openjdk.org/skara/pull/1454 From erikj at openjdk.org Wed Jan 11 14:15:16 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Jan 2023 14:15:16 GMT Subject: RFR: 1741: Change the logic of removing CSR label when CSR label is added via '/csr needed' command In-Reply-To: <7bqJDsV6yebawMf_Uxq__qxa3CUq-TIzDU04AzH0VWk=.bdbb5f0b-045b-4d4c-a2f9-0b09c094a1a4@github.com> References: <7bqJDsV6yebawMf_Uxq__qxa3CUq-TIzDU04AzH0VWk=.bdbb5f0b-045b-4d4c-a2f9-0b09c094a1a4@github.com> Message-ID: On Tue, 10 Jan 2023 23:21:48 GMT, Zhao Song wrote: > Assuming there is such a situation: > > 1. One pr solves issue1 and issue2. > 2. One user thought this pr needs CSR Issue and commented '/csr needed'. > 3. Author of this pr created csr1 of issue1, but then he thought it is not right to create csr of issue1 and withdrawn csr1. > 4. Author of this pr created csr2 of issue2 and csr2 got approved. > 5. In my opinion, the csr label should be removed(But due to [SKARA-1729](https://bugs.openjdk.org/browse/SKARA-1729), it is not removed) > > To sum, > > There are two ways that CSR label can be added to a PR > 1. via '/csr needed' command > 2. A CSR issue is discovered > > For the first case, if the CSR label is added via '/csr needed', there will be a CSR_NEEDED_MARKER. > In this case, if we want to remove the csr label. there are two ways > (1) No active CSR Issue exists and use '/csr unneeded' command > (2) all of the CSR issues are approved or withdrawn(at least 1 CSR Issue is approved) > > For the second case, if the CSR label is added because a CSR Issue is discovered, there will not be CSR_NEEDED_MARKER. > In this case, if we want to remove the csr label, there is only one way > (1) all of the CSR issues are approved or withdrawn Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1454 From zsong at openjdk.org Wed Jan 11 16:57:21 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 16:57:21 GMT Subject: Integrated: 1741: Change the logic of removing CSR label when CSR label is added via '/csr needed' command In-Reply-To: <7bqJDsV6yebawMf_Uxq__qxa3CUq-TIzDU04AzH0VWk=.bdbb5f0b-045b-4d4c-a2f9-0b09c094a1a4@github.com> References: <7bqJDsV6yebawMf_Uxq__qxa3CUq-TIzDU04AzH0VWk=.bdbb5f0b-045b-4d4c-a2f9-0b09c094a1a4@github.com> Message-ID: On Tue, 10 Jan 2023 23:21:48 GMT, Zhao Song wrote: > Assuming there is such a situation: > > 1. One pr solves issue1 and issue2. > 2. One user thought this pr needs CSR Issue and commented '/csr needed'. > 3. Author of this pr created csr1 of issue1, but then he thought it is not right to create csr of issue1 and withdrawn csr1. > 4. Author of this pr created csr2 of issue2 and csr2 got approved. > 5. In my opinion, the csr label should be removed(But due to [SKARA-1729](https://bugs.openjdk.org/browse/SKARA-1729), it is not removed) > > To sum, > > There are two ways that CSR label can be added to a PR > 1. via '/csr needed' command > 2. A CSR issue is discovered > > For the first case, if the CSR label is added via '/csr needed', there will be a CSR_NEEDED_MARKER. > In this case, if we want to remove the csr label. there are two ways > (1) No active CSR Issue exists and use '/csr unneeded' command > (2) all of the CSR issues are approved or withdrawn(at least 1 CSR Issue is approved) > > For the second case, if the CSR label is added because a CSR Issue is discovered, there will not be CSR_NEEDED_MARKER. > In this case, if we want to remove the csr label, there is only one way > (1) all of the CSR issues are approved or withdrawn This pull request has now been integrated. Changeset: 28edb7c7 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/28edb7c7c8b5973ddb546c44e3ae6343ee3c47b2 Stats: 15 lines in 2 files changed: 2 ins; 3 del; 10 mod 1741: Change the logic of removing CSR label when CSR label is added via '/csr needed' command Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1454 From zsong at openjdk.org Wed Jan 11 19:38:20 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 19:38:20 GMT Subject: RFR: 1785: Do not always add CSR_UPDATE_MARKER when CSR bot finds withdrawn CSR Issue Message-ID: In [SKARA-1728](https://bugs.openjdk.org/browse/SKARA-1728), I said that 'if we find a withdrawn pr, we need to add CSR_UPDATE_MARKER to the pr body.', yes, we need to add CSR_UPDATE_MARKER, but there is a prerequisite which is that our status message **doesn't** contain this withdrawn issue. Without the prerequisite, the CSR bot will always add CSR_UPDATE_MARKER when it finds a withdrawn CSR Issue and the pr body will be updated very frequently(looks like the bot go berserk). This issue is same as [SKARA-1673](https://bugs.openjdk.org/browse/SKARA-1673). I discovered this issue and fixed it, but I am silly enough to make the same mistake again. ------------- Commit messages: - SKARA-1785 - SKARA-1785 Changes: https://git.openjdk.org/skara/pull/1455/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1455&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1785 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1455.diff Fetch: git fetch https://git.openjdk.org/skara pull/1455/head:pull/1455 PR: https://git.openjdk.org/skara/pull/1455 From erikj at openjdk.org Wed Jan 11 20:17:26 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Jan 2023 20:17:26 GMT Subject: RFR: 1785: Do not always add CSR_UPDATE_MARKER when CSR bot finds withdrawn CSR Issue In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 19:30:04 GMT, Zhao Song wrote: > In [SKARA-1728](https://bugs.openjdk.org/browse/SKARA-1728), I said that 'if we find a withdrawn pr, we need to add CSR_UPDATE_MARKER to the pr body.', yes, we need to add CSR_UPDATE_MARKER, but there is a prerequisite which is that our status message **doesn't** contain this withdrawn issue. Without the prerequisite, the CSR bot will always add CSR_UPDATE_MARKER when it finds a withdrawn CSR Issue and the pr body will be updated very frequently(looks like the bot go berserk). > > This issue is same as [SKARA-1673](https://bugs.openjdk.org/browse/SKARA-1673). I discovered this issue and fixed it, but I am silly enough to make the same mistake again. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1455 From zsong at openjdk.org Wed Jan 11 20:47:37 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 20:47:37 GMT Subject: RFR: 1785: Do not always add CSR_UPDATE_MARKER when CSR bot finds withdrawn CSR Issue In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 19:30:04 GMT, Zhao Song wrote: > In [SKARA-1728](https://bugs.openjdk.org/browse/SKARA-1728), I said that 'if we find a withdrawn pr, we need to add CSR_UPDATE_MARKER to the pr body.', yes, we need to add CSR_UPDATE_MARKER, but there is a prerequisite which is that our status message **doesn't** contain this withdrawn issue. Without the prerequisite, the CSR bot will always add CSR_UPDATE_MARKER when it finds a withdrawn CSR Issue and the pr body will be updated very frequently(looks like the bot go berserk). > > This issue is same as [SKARA-1673](https://bugs.openjdk.org/browse/SKARA-1673). I discovered this issue and fixed it, but I am silly enough to make the same mistake again. Thanks for the review! ------------- PR: https://git.openjdk.org/skara/pull/1455 From zsong at openjdk.org Wed Jan 11 20:47:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 20:47:38 GMT Subject: Integrated: 1785: Do not always add CSR_UPDATE_MARKER when CSR bot finds withdrawn CSR Issue In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 19:30:04 GMT, Zhao Song wrote: > In [SKARA-1728](https://bugs.openjdk.org/browse/SKARA-1728), I said that 'if we find a withdrawn pr, we need to add CSR_UPDATE_MARKER to the pr body.', yes, we need to add CSR_UPDATE_MARKER, but there is a prerequisite which is that our status message **doesn't** contain this withdrawn issue. Without the prerequisite, the CSR bot will always add CSR_UPDATE_MARKER when it finds a withdrawn CSR Issue and the pr body will be updated very frequently(looks like the bot go berserk). > > This issue is same as [SKARA-1673](https://bugs.openjdk.org/browse/SKARA-1673). I discovered this issue and fixed it, but I am silly enough to make the same mistake again. This pull request has now been integrated. Changeset: 20e61e4a Author: Zhao Song URL: https://git.openjdk.org/skara/commit/20e61e4aa1c2065cf3cbd6b6c35e735e28d473e8 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod 1785: Do not always add CSR_UPDATE_MARKER when CSR bot finds withdrawn CSR Issue Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1455 From zsong at openjdk.org Wed Jan 11 23:24:30 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 23:24:30 GMT Subject: RFR: 1737: Draft PR for clean backport mistakenly marked as ready Message-ID: 1. readyForIntegration for normal pr is determined by (1) whether there is any failed check (2) whether there is any additional errors (3) whether there is any uncompleted additional progress (4) whether there is any integration blocker So if there is a draft normal pr, there will always exist a failed check(ReviewersCheck will always fail because the pr is in draft mode and nobody will approve this pr) Therefore, a draft normal pr will not be marked as 'ready' because there is a failed check not because this pr is in draft mode. 2. readyForIntegration for clean backport is determined by (1) whether this pr is ready for review(TooFewReviewersIssue won't make it false) (2) whether there is any additional errors (3) whether there is any uncompleted additional progress (4) whether there is any integration blocker So if there is a draft clean backport pr, readyForIntegration will be true in most cases. Therefore, the clean backport pr will be marked as 'ready' whether it is in draft mode or not. In this patch, whether there is an rfr label will determine whether readyforintegration is true or false. ------------- Commit messages: - SKARA-1737 Changes: https://git.openjdk.org/skara/pull/1456/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1456&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1737 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1456.diff Fetch: git fetch https://git.openjdk.org/skara pull/1456/head:pull/1456 PR: https://git.openjdk.org/skara/pull/1456 From erikj at openjdk.org Wed Jan 11 23:42:58 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 11 Jan 2023 23:42:58 GMT Subject: RFR: 1737: Draft PR for clean backport mistakenly marked as ready In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 22:51:35 GMT, Zhao Song wrote: > 1. readyForIntegration for normal pr is determined by > (1) whether there is any failed check > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft normal pr, there will always exist a failed check(ReviewersCheck will always fail because the pr is in draft mode and nobody will approve this pr) > Therefore, a draft normal pr will not be marked as 'ready' because there is a failed check not because this pr is in draft mode. > > 2. readyForIntegration for clean backport is determined by > (1) whether this pr is ready for review(TooFewReviewersIssue won't make it false) > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft clean backport pr, readyForIntegration will be true in most cases. > Therefore, the clean backport pr will be marked as 'ready' whether it is in draft mode or not. > > In this patch, whether there is an rfr label will determine whether readyforintegration is true or false. While this will function correctly, I'm not sure using the contents of newLabels is the right thing to do here. I think it would be better to be explicit and check `pr.isDraft()` directly. It makes it clearer when reading the code what the requirements are. The rest of the requirements for readyForReview are already repeated in the readyForIntegration checks. It would also be possible to more clearly define a boolean for `readyForReview` (maybe as a return value from `updateReadyForReview`?) and use that in this check, but then also remove the redundant checks in `readyForIntegration`. ------------- PR: https://git.openjdk.org/skara/pull/1456 From zsong at openjdk.org Wed Jan 11 23:54:34 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 23:54:34 GMT Subject: RFR: 1737: Draft PR for clean backport mistakenly marked as ready In-Reply-To: References: Message-ID: On Wed, 11 Jan 2023 23:40:38 GMT, Erik Joelsson wrote: > While this will function correctly, I'm not sure using the contents of newLabels is the right thing to do here. I think it would be better to be explicit and check `pr.isDraft()` directly. It makes it clearer when reading the code what the requirements are. The rest of the requirements for readyForReview are already repeated in the readyForIntegration checks. > > It would also be possible to more clearly define a boolean for `readyForReview` (maybe as a return value from `updateReadyForReview`?) and use that in this check, but then also remove the redundant checks in `readyForIntegration`. It's a good idea to define a boolean called `readyForReview` and remove the redundant checks. I will do it now. Thanks for the advice! ------------- PR: https://git.openjdk.org/skara/pull/1456 From zsong at openjdk.org Wed Jan 11 23:59:46 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 11 Jan 2023 23:59:46 GMT Subject: RFR: 1737: Draft PR for clean backport mistakenly marked as ready [v2] In-Reply-To: References: Message-ID: <2mXT4x7ACoIt_rj4f8nQDYyePxJ4E2s70uC1wa4fgJw=.a3afcd00-b1e8-4a64-9658-ed57d39d65ce@github.com> > 1. readyForIntegration for normal pr is determined by > (1) whether there is any failed check > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft normal pr, there will always exist a failed check(ReviewersCheck will always fail because the pr is in draft mode and nobody will approve this pr) > Therefore, a draft normal pr will not be marked as 'ready' because there is a failed check not because this pr is in draft mode. > > 2. readyForIntegration for clean backport is determined by > (1) whether this pr is ready for review(TooFewReviewersIssue won't make it false) > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft clean backport pr, readyForIntegration will be true in most cases. > Therefore, the clean backport pr will be marked as 'ready' whether it is in draft mode or not. > > In this patch, whether there is an rfr label will determine whether readyforintegration is true or false. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: optimize how to determine readyForIntegration ------------- Changes: - all: https://git.openjdk.org/skara/pull/1456/files - new: https://git.openjdk.org/skara/pull/1456/files/902b9fec..dd56603f Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1456&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1456&range=00-01 Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1456.diff Fetch: git fetch https://git.openjdk.org/skara pull/1456/head:pull/1456 PR: https://git.openjdk.org/skara/pull/1456 From erikj at openjdk.org Thu Jan 12 00:04:07 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 12 Jan 2023 00:04:07 GMT Subject: RFR: 1737: Draft PR for clean backport mistakenly marked as ready [v2] In-Reply-To: <2mXT4x7ACoIt_rj4f8nQDYyePxJ4E2s70uC1wa4fgJw=.a3afcd00-b1e8-4a64-9658-ed57d39d65ce@github.com> References: <2mXT4x7ACoIt_rj4f8nQDYyePxJ4E2s70uC1wa4fgJw=.a3afcd00-b1e8-4a64-9658-ed57d39d65ce@github.com> Message-ID: <98EVT2Ysf6YmERD13RodLBJiRHpmRepLrJ98kfKzYns=.f1643aa2-3dae-4313-b060-3c873cbb36bf@github.com> On Wed, 11 Jan 2023 23:59:46 GMT, Zhao Song wrote: >> 1. readyForIntegration for normal pr is determined by >> (1) whether there is any failed check >> (2) whether there is any additional errors >> (3) whether there is any uncompleted additional progress >> (4) whether there is any integration blocker >> >> So if there is a draft normal pr, there will always exist a failed check(ReviewersCheck will always fail because the pr is in draft mode and nobody will approve this pr) >> Therefore, a draft normal pr will not be marked as 'ready' because there is a failed check not because this pr is in draft mode. >> >> 2. readyForIntegration for clean backport is determined by >> (1) whether this pr is ready for review(TooFewReviewersIssue won't make it false) >> (2) whether there is any additional errors >> (3) whether there is any uncompleted additional progress >> (4) whether there is any integration blocker >> >> So if there is a draft clean backport pr, readyForIntegration will be true in most cases. >> Therefore, the clean backport pr will be marked as 'ready' whether it is in draft mode or not. >> >> In this patch, whether there is an rfr label will determine whether readyforintegration is true or false. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > optimize how to determine readyForIntegration Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1456 From zsong at openjdk.org Thu Jan 12 18:01:41 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 12 Jan 2023 18:01:41 GMT Subject: Integrated: 1737: Draft PR for clean backport mistakenly marked as ready In-Reply-To: References: Message-ID: <8ZCGj6dlLLUjZW3-pGQrmmSuKWiMRt--fM91XpUc-uQ=.9e066fc3-c43d-4d03-8ef0-dd3fb59f6c6c@github.com> On Wed, 11 Jan 2023 22:51:35 GMT, Zhao Song wrote: > 1. readyForIntegration for normal pr is determined by > (1) whether there is any failed check > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft normal pr, there will always exist a failed check(ReviewersCheck will always fail because the pr is in draft mode and nobody will approve this pr) > Therefore, a draft normal pr will not be marked as 'ready' because there is a failed check not because this pr is in draft mode. > > 2. readyForIntegration for clean backport is determined by > (1) whether this pr is ready for review(TooFewReviewersIssue won't make it false) > (2) whether there is any additional errors > (3) whether there is any uncompleted additional progress > (4) whether there is any integration blocker > > So if there is a draft clean backport pr, readyForIntegration will be true in most cases. > Therefore, the clean backport pr will be marked as 'ready' whether it is in draft mode or not. > > In this patch, whether there is an rfr label will determine whether readyforintegration is true or false. This pull request has now been integrated. Changeset: bbb3595a Author: Zhao Song URL: https://git.openjdk.org/skara/commit/bbb3595ac2bccc4ecc8fd6508a2375b86562cc04 Stats: 10 lines in 1 file changed: 2 ins; 1 del; 7 mod 1737: Draft PR for clean backport mistakenly marked as ready Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1456 From zsong at openjdk.org Thu Jan 12 22:22:33 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 12 Jan 2023 22:22:33 GMT Subject: RFR: 1727: Ability to control whether clean backports require review Message-ID: In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. By default, no review is necessary for clean backports. However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: { "pr": { "repositories": { "repo1": { "requiresReviewForBackport": true } } } } ------------- Commit messages: - fix a problem - fix comment - SKARA-1727 Changes: https://git.openjdk.org/skara/pull/1457/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1457&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1727 Stats: 141 lines in 7 files changed: 126 ins; 0 del; 15 mod Patch: https://git.openjdk.org/skara/pull/1457.diff Fetch: git fetch https://git.openjdk.org/skara pull/1457/head:pull/1457 PR: https://git.openjdk.org/skara/pull/1457 From erikj at openjdk.org Fri Jan 13 15:14:52 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jan 2023 15:14:52 GMT Subject: RFR: 1727: Ability to control whether clean backports require review In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 21:30:40 GMT, Zhao Song wrote: > In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. > > By default, no review is necessary for clean backports. > > However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "requiresReviewForBackport": true > } > } > } > } bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 72: > 70: private final static Set primaryTypes = Set.of("Bug", "New Feature", "Enhancement", "Task", "Sub-task"); > 71: private final Set newLabels; > 72: private final boolean requiresReviewForBackport; Can we change the name and the configuration option to `reviewCleanBackport` bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 520: > 518: } > 519: > 520: private String getChecksList(PullRequestCheckIssueVisitor visitor, boolean noNeedReview, Map additionalProgresses) { Can we flip this boolean to avoid negation in the name? I would suggest `reviewNeeded`. ------------- PR: https://git.openjdk.org/skara/pull/1457 From zsong at openjdk.org Fri Jan 13 16:57:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 16:57:23 GMT Subject: RFR: 1727: Ability to control whether clean backports require review In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 15:10:34 GMT, Erik Joelsson wrote: >> In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. >> >> By default, no review is necessary for clean backports. >> >> However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: >> >> { >> "pr": { >> "repositories": { >> "repo1": { >> "requiresReviewForBackport": true >> } >> } >> } >> } > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 72: > >> 70: private final static Set primaryTypes = Set.of("Bug", "New Feature", "Enhancement", "Task", "Sub-task"); >> 71: private final Set newLabels; >> 72: private final boolean requiresReviewForBackport; > > Can we change the name and the configuration option to `reviewCleanBackport` Sure! > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 520: > >> 518: } >> 519: >> 520: private String getChecksList(PullRequestCheckIssueVisitor visitor, boolean noNeedReview, Map additionalProgresses) { > > Can we flip this boolean to avoid negation in the name? I would suggest `reviewNeeded`. Sure, I will fix it. ------------- PR: https://git.openjdk.org/skara/pull/1457 From zsong at openjdk.org Fri Jan 13 17:20:25 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 17:20:25 GMT Subject: RFR: 1727: Ability to control whether clean backports require review [v2] In-Reply-To: References: Message-ID: > In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. > > By default, no review is necessary for clean backports. > > However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "requiresReviewForBackport": true > } > } > } > } Zhao Song has updated the pull request incrementally with one additional commit since the last revision: renamed two variables ------------- Changes: - all: https://git.openjdk.org/skara/pull/1457/files - new: https://git.openjdk.org/skara/pull/1457/files/1a3386b1..8f1719ef Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1457&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1457&range=00-01 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod Patch: https://git.openjdk.org/skara/pull/1457.diff Fetch: git fetch https://git.openjdk.org/skara pull/1457/head:pull/1457 PR: https://git.openjdk.org/skara/pull/1457 From zsong at openjdk.org Fri Jan 13 18:33:40 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 18:33:40 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 17:37:18 GMT, Erik Joelsson wrote: >> In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: >> >> >> "prbranch": { >> "protect": true, >> }, >> >> The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) >> >> I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix import bots/notify/src/main/java/org/openjdk/skara/bots/notify/prbranch/PullRequestBranchNotifier.java line 61: > 59: log.info("Creating new pull request pre-integration branch " + branch); > 60: seedRepo.push(pr.headHash(), pr.repository().url(), branch, true); > 61: } catch (IOException e) { I am wondering in the previous pushBranch, we didn't manually make the branch protected, but the branch pushed are protected, is this due to settings in GitLab? ------------- PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Fri Jan 13 18:36:20 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 18:36:20 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 17:37:18 GMT, Erik Joelsson wrote: >> In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: >> >> >> "prbranch": { >> "protect": true, >> }, >> >> The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) >> >> I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Fix import bots/tester/src/test/java/org/openjdk/skara/bots/tester/InMemoryHostedRepository.java line 177: > 175: @Override > 176: public void protectBranchPattern(String ref) { > 177: } The name of this method is protectBranchPattern, but I think it actually protects a specific branch rather than a pattern. ------------- PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Fri Jan 13 21:02:36 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jan 2023 21:02:36 GMT Subject: RFR: 1727: Ability to control whether clean backports require review [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 17:20:25 GMT, Zhao Song wrote: >> In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. >> >> By default, no review is necessary for clean backports. >> >> However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: >> >> { >> "pr": { >> "repositories": { >> "repo1": { >> "requiresReviewForBackport": true >> } >> } >> } >> } > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > renamed two variables Marked as reviewed by erikj (Lead). bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1175: > 1173: integrationBlockers.isEmpty(); > 1174: if (!reviewNeeded) { > 1175: // Reviews are not needed for clean backports if this repo is not configured with reviewCleanBackport enabled Suggestion: // Reviews are not needed for clean backports unless this repo is configured with reviewCleanBackport enabled ------------- PR: https://git.openjdk.org/skara/pull/1457 From erikj at openjdk.org Fri Jan 13 21:09:53 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jan 2023 21:09:53 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 18:31:27 GMT, Zhao Song wrote: >> Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix import > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/prbranch/PullRequestBranchNotifier.java line 61: > >> 59: log.info("Creating new pull request pre-integration branch " + branch); >> 60: seedRepo.push(pr.headHash(), pr.repository().url(), branch, true); >> 61: } catch (IOException e) { > > I am wondering in the previous pushBranch, we didn't manually make the branch protected, but the branch pushed are protected, is this due to settings in GitLab? Before this change, we relied on a static configuration for the repository with certain branch patterns being protected. When this change goes live, we will need to adjust those patterns so that they do not apply to pr/X branches. Not sure if this answers your question. > bots/tester/src/test/java/org/openjdk/skara/bots/tester/InMemoryHostedRepository.java line 177: > >> 175: @Override >> 176: public void protectBranchPattern(String ref) { >> 177: } > > The name of this method is protectBranchPattern, but I think it actually protects a specific branch rather than a pattern. Hm, on GitLab the underlying call takes a pattern, but now that I think about it, on GitHub it doesn't. There you have to use GraphQL to add pattern based protection. I should change this method to reflect that. We aren't using patterns anyway. ------------- PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Fri Jan 13 21:15:18 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jan 2023 21:15:18 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v3] In-Reply-To: References: Message-ID: <39AGTdtDvdrK4-xT9DvsU5IqSJxplIHzyrl1bjToTQg=.420ea5b4-9344-4eba-9816-5b192bda1a3f@github.com> > In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: > > > "prbranch": { > "protect": true, > }, > > The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) > > I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: Renamed parameter ------------- Changes: - all: https://git.openjdk.org/skara/pull/1452/files - new: https://git.openjdk.org/skara/pull/1452/files/68619fab..8ce0d132 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1452&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1452&range=01-02 Stats: 7 lines in 2 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1452.diff Fetch: git fetch https://git.openjdk.org/skara pull/1452/head:pull/1452 PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Fri Jan 13 21:15:19 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 13 Jan 2023 21:15:19 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:07:32 GMT, Erik Joelsson wrote: >> bots/tester/src/test/java/org/openjdk/skara/bots/tester/InMemoryHostedRepository.java line 177: >> >>> 175: @Override >>> 176: public void protectBranchPattern(String ref) { >>> 177: } >> >> The name of this method is protectBranchPattern, but I think it actually protects a specific branch rather than a pattern. > > Hm, on GitLab the underlying call takes a pattern, but now that I think about it, on GitHub it doesn't. There you have to use GraphQL to add pattern based protection. I should change this method to reflect that. We aren't using patterns anyway. I take that back. I see now that I chose not to implement this on GitHub at all since we don't need it. This does take a branch pattern, which are supported by both GitHub and GitLab in the web UI. ------------- PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Fri Jan 13 21:34:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 21:34:24 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v3] In-Reply-To: <39AGTdtDvdrK4-xT9DvsU5IqSJxplIHzyrl1bjToTQg=.420ea5b4-9344-4eba-9816-5b192bda1a3f@github.com> References: <39AGTdtDvdrK4-xT9DvsU5IqSJxplIHzyrl1bjToTQg=.420ea5b4-9344-4eba-9816-5b192bda1a3f@github.com> Message-ID: On Fri, 13 Jan 2023 21:15:18 GMT, Erik Joelsson wrote: >> In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: >> >> >> "prbranch": { >> "protect": true, >> }, >> >> The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) >> >> I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Renamed parameter Marked as reviewed by zsong (Committer). ------------- PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Fri Jan 13 21:34:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 21:34:24 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:06:01 GMT, Erik Joelsson wrote: > Before this change, we relied on a static configuration for the repository with certain branch patterns being protected. When this change goes live, we will need to adjust those patterns so that they do not apply to pr/X branches. Not sure if this answers your question. Yes, it answered my question. Thank you! ------------- PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Fri Jan 13 21:34:24 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 21:34:24 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v2] In-Reply-To: References: Message-ID: On Fri, 13 Jan 2023 21:10:38 GMT, Erik Joelsson wrote: > I take that back. I see now that I chose not to implement this on GitHub at all since we don't need it. This does take a branch pattern, which are supported by both GitHub and GitLab in the web UI. Got it! It makes sense ------------- PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Fri Jan 13 21:36:48 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 13 Jan 2023 21:36:48 GMT Subject: RFR: 1727: Ability to control whether clean backports require review [v3] In-Reply-To: References: Message-ID: > In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. > > By default, no review is necessary for clean backports. > > However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "requiresReviewForBackport": true > } > } > } > } Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1457/files - new: https://git.openjdk.org/skara/pull/1457/files/8f1719ef..1b5ca328 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1457&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1457&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1457.diff Fetch: git fetch https://git.openjdk.org/skara pull/1457/head:pull/1457 PR: https://git.openjdk.org/skara/pull/1457 From ludovic at rivosinc.com Tue Jan 17 13:32:28 2023 From: ludovic at rivosinc.com (Ludovic Henry) Date: Tue, 17 Jan 2023 14:32:28 +0100 Subject: Backports of Linux/RISC-V to jdk11u and jdk17u In-Reply-To: References: Message-ID: Hello, I'm looking at what it would take to backport the Linux/RISC-V port to jdk11u and jdk17u (and maybe jdk8u). AFAIU, we would need to create the `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` repositories, similarly to `openjdk/lilliput-jdk17u` or `openjdk/aarch32-port-jdk8u`. What would then be the process to create these `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` repositories? (And to be clear, this isn't a request to create these repos, it's only a request for information.) Please let me know which mailing list or email address would be best to reach out to if this isn't the right one. Thank you, Ludovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Tue Jan 17 13:55:08 2023 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 17 Jan 2023 05:55:08 -0800 Subject: Backports of Linux/RISC-V to jdk11u and jdk17u In-Reply-To: References: Message-ID: Hello Ludovic, The riscv-port project would need to request these repositories by sending an email to ops at openjdk. /Erik On 1/17/23 05:32, Ludovic Henry wrote: > Hello, > > I'm looking at what it would take to backport the Linux/RISC-V port to > jdk11u and jdk17u (and maybe jdk8u). AFAIU, we would need to create > the `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` > repositories, similarly to `openjdk/lilliput-jdk17u` or > `openjdk/aarch32-port-jdk8u`. > > What would then be the process to create these > `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` > repositories? (And to be clear, this isn't a request to create these > repos, it's only a request for information.) > > Please let me know which mailing list or email address would be best > to reach out to if this isn't the right one. > > Thank you, > Ludovic From ludovic at rivosinc.com Tue Jan 17 14:09:15 2023 From: ludovic at rivosinc.com (Ludovic Henry) Date: Tue, 17 Jan 2023 15:09:15 +0100 Subject: Backports of Linux/RISC-V to jdk11u and jdk17u In-Reply-To: References: Message-ID: Hi Erik, Perfect, thank you for the information. Thanks, Ludovic On Tue, Jan 17, 2023 at 2:55 PM wrote: > Hello Ludovic, > > The riscv-port project would need to request these repositories by > sending an email to ops at openjdk. > > /Erik > > On 1/17/23 05:32, Ludovic Henry wrote: > > Hello, > > > > I'm looking at what it would take to backport the Linux/RISC-V port to > > jdk11u and jdk17u (and maybe jdk8u). AFAIU, we would need to create > > the `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` > > repositories, similarly to `openjdk/lilliput-jdk17u` or > > `openjdk/aarch32-port-jdk8u`. > > > > What would then be the process to create these > > `openjdk/riscv-port-jdk11u` and `openjdk/riscv-port-jdk17u` > > repositories? (And to be clear, this isn't a request to create these > > repos, it's only a request for information.) > > > > Please let me know which mailing list or email address would be best > > to reach out to if this isn't the right one. > > > > Thank you, > > Ludovic > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsong at openjdk.org Tue Jan 17 22:00:29 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 17 Jan 2023 22:00:29 GMT Subject: Integrated: 1727: Ability to control whether clean backports require review In-Reply-To: References: Message-ID: On Thu, 12 Jan 2023 21:30:40 GMT, Zhao Song wrote: > In this patch, PR bot has been added with the capability to control the requirement of reviews for clean backports. > > By default, no review is necessary for clean backports. > > However, if it is desired to enable the requirement of reviews for backports in a repo, the configuration can be added to the PR bot configuration as follows: > > { > "pr": { > "repositories": { > "repo1": { > "reviewCleanBackport": true > } > } > } > } This pull request has now been integrated. Changeset: 9eeac31d Author: Zhao Song URL: https://git.openjdk.org/skara/commit/9eeac31d10e2cfdaf15e16770425318315a604ac Stats: 141 lines in 7 files changed: 126 ins; 0 del; 15 mod 1727: Ability to control whether clean backports require review Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1457 From ihse at openjdk.org Wed Jan 18 13:58:53 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 18 Jan 2023 13:58:53 GMT Subject: RFR: 1731: Improve RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 18:15:36 GMT, Erik Joelsson wrote: > In the RestRequestCache, we are trying to limit non GET calls for a specific host and user to one call per second (and all calls, including GET, for a specific host and user, need to be serialized). This throttling is based on recommendations from GitHub (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-abuse-rate-limits). The current implementation isn't really doing that however. Calls are serialized, but depending on timing, we can definitely send more than one non GET call per second, at least in bursts. > > This patch tries to rework this, using two locks. During high contention, it's possible that this new implementation will be less favorable to non GET calls than the current implementation, but I'm pretty sure we will at least adhere to the recommendation of performing at most one non-GET call per second. See bug for breakdown of locking order. Marked as reviewed by ihse (Reviewer). Is this not slowing us down unnecessarily? If we have like an incoming stream of requests like this: GET1 POST1 POST2 GET2 GET3 GET4 Then we will correctly make sure only a single request is sent at a time, and that the two post operations will have a delay between them. But that will also mean that GET2...GET4 will be artificially delayed, awaiting POST1 and POST2. My understanding is that we should be able to do like: GET1 POST1 (wait with POST2) GET2 GET3 POST4 (now enough time has passed) GET4 I think this would be easy to accomplish, as well. Just reverse the order on the post locks, so we first take the non-get lock to ensure one second has passed since the last POST operation, and then we take the general lock. That way additional GET requests can be handled while the POST operation is waiting for the full second to pass, but we will still in the end always need to hold the general lock, so we do not send a POST and a GET at the same time. Actually, that is what you are doing. :-) I got confused by: var authNonGetLock = authNonGetLocks.computeIfAbsent(authId, id -> new ReentrantLock()); ``` thinking it was grabbing the lock. ------------- PR: https://git.openjdk.org/skara/pull/1453 From ihse at openjdk.org Wed Jan 18 14:06:19 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 18 Jan 2023 14:06:19 GMT Subject: RFR: 1715: Configure custom default security level for new backport issues in notifier In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 22:12:29 GMT, Erik Joelsson wrote: > This patch makes it possible to configure a default security level to use for any newly created backport in the IssueNotifier. The configuration is done per repository and branch, with a regex for matching branch names. This is what it would look like in the bot configuration. > > > "issue": { > "project": "bugs/JDK", > "fixversions": {}, > "buildname": "master", > "headversion": true, > "defaultsecurity": { // <- new > "jdk.*": "10000", > } > } > > > If the parent bug already has a security level, then that is inherited, just like today, otherwise this new default value is used. LGTM. bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/JbsBackport.java line 55: > 53: var finalProperties = new HashMap<>(primary.properties()); > 54: finalProperties.put("issuetype", JSON.of("Backport")); > 55: finalProperties.put("fixVersion", JSON.of(fixVersion)); Not sure I fully understand what this does in the context of this PR. ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1445 From ihse at openjdk.org Wed Jan 18 14:33:16 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 18 Jan 2023 14:33:16 GMT Subject: RFR: 1699: CommitCommentsWorkItem does excessive unnecessary work In-Reply-To: References: Message-ID: <6g8FrG7i4rUN0aHw9eSwGwrTCRFNtqSR2yyXbprankY=.737d4060-a17a-4c6d-b164-a1670469548b@github.com> On Tue, 20 Dec 2022 21:14:41 GMT, Erik Joelsson wrote: > The `CommitCommentsWorkItem` gets scheduled once for each repository by `PullRequestBot::getPeriodicItems`. It's responsible for querying the repository for new comments on commits, and if any are found, spawn `CommitCommandWorkItem` for them. It's unfortunately not very straight forward to query forges for new commit comments. For GitHub we have a rather complicated GraphQL that does the trick, but for GitLab, we need to jump through some rather nasty hoops. > > The main issue is that the data we get from the "events" query from GitLab contains notes posted to commits, but without the commit hash. We only get the commit "title" to identify which commit was commented on. To solve this, we have a rather elaborate logic that first builds a complete map from title to set of hashes for every commit in the repo. This is done preemptively on a local clone of the repo. Using this map and some clever comparisons, we can figure out which commit each comment belongs to. > > I don't have data on how long it takes to build this map for a big repository, like the JDK, but it's likely not trivially short. In addition to this, before using any local clone of a repository, we always run the git fsck check (see [SKARA-1598](https://bugs.openjdk.org/browse/SKARA-1598)), which can take around 20s for the JDK repo. The local clone is unfortunately also used to check if the commits for the found comments belong to a valid branch. However, both of these operations are read only, so we shouldn't really need a clone for this. We should be fine just using the seed repository directly from the `HostedRepositoryPool`. > > This patch tries to make this situation better in several ways. > > 1. Use the seed repository instead of a clone in `CommitCommentsWorkItem`. (Removes ~20s fsck time every time this is scheduled for a jdk repository, which is in the order of once a minute times the numer of JDK repo clones that Skara operates on) > 2. Refactored `HostedRepository::recentCommitComments` to take a `ReadOnlyRepository` instead of the pre calculated map. `GitLabRepository` is then responsible for using this repository to build the map itself. > 3. `HostedRepository::recentCommitComments` now takes an `updatedAfter` arg to limit the number of comments that get returned. In `GitLabRepository` this was already limited to last 4 days, but in `GitHubRepository`, we just got the last 100 comments, regardless of age (due to a limitation in GraphQL). We can still filter the returned comments on updatedAt so that we get less comments to process in many cases. This should make a big impact on bot restarts. > 4. `CommitCommentsWorkItem` has a configuration option to ignore comments from certain users (typically meant for bot users, e.g. the notifier who posts a comment on every commit). This configuration wasn't working due to a bug in the factory. (Together with 3, should bring down the number of scheduled `CommitCommandWorkItem` on bot restart from 100 per repo to a handful and often 0.) > 5. `GitLabRepository` keeps a cached copy of the commitTitleToHash map. It will also only build or update the map if any new notes are actually found. (This won't have a huge impact, but should speed things up a little bit more) Looks good. Did you measure any speed improvements? ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1446 From erikj at openjdk.org Wed Jan 18 14:53:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 14:53:32 GMT Subject: RFR: 1715: Configure custom default security level for new backport issues in notifier In-Reply-To: References: Message-ID: <5U0bknitdVYvDXUYOOlg9buPec0VYVFT-x1RbsvbRuE=.a3cf8bd2-9f5f-4169-953e-6e6febfd13f0@github.com> On Wed, 18 Jan 2023 14:03:57 GMT, Magnus Ihse Bursie wrote: >> This patch makes it possible to configure a default security level to use for any newly created backport in the IssueNotifier. The configuration is done per repository and branch, with a regex for matching branch names. This is what it would look like in the bot configuration. >> >> >> "issue": { >> "project": "bugs/JDK", >> "fixversions": {}, >> "buildname": "master", >> "headversion": true, >> "defaultsecurity": { // <- new >> "jdk.*": "10000", >> } >> } >> >> >> If the parent bug already has a security level, then that is inherited, just like today, otherwise this new default value is used. > > bots/notify/src/main/java/org/openjdk/skara/bots/notify/issue/JbsBackport.java line 55: > >> 53: var finalProperties = new HashMap<>(primary.properties()); >> 54: finalProperties.put("issuetype", JSON.of("Backport")); >> 55: finalProperties.put("fixVersion", JSON.of(fixVersion)); > > Not sure I fully understand what this does in the context of this PR. You are right, that's not related to the actual issue, just something that I found missing in this code path. In practice, this path is only used in tests. When interacting with a real JBS instance, we have a backportRequest. ------------- PR: https://git.openjdk.org/skara/pull/1445 From erikj at openjdk.org Wed Jan 18 14:55:51 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 14:55:51 GMT Subject: RFR: 1699: CommitCommentsWorkItem does excessive unnecessary work In-Reply-To: <6g8FrG7i4rUN0aHw9eSwGwrTCRFNtqSR2yyXbprankY=.737d4060-a17a-4c6d-b164-a1670469548b@github.com> References: <6g8FrG7i4rUN0aHw9eSwGwrTCRFNtqSR2yyXbprankY=.737d4060-a17a-4c6d-b164-a1670469548b@github.com> Message-ID: On Wed, 18 Jan 2023 14:30:53 GMT, Magnus Ihse Bursie wrote: > Looks good. Thanks! > Did you measure any speed improvements? I haven't run this live yet, so won't know the real impact until we deploy this for real. ------------- PR: https://git.openjdk.org/skara/pull/1446 From ihse at openjdk.org Wed Jan 18 15:15:14 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 18 Jan 2023 15:15:14 GMT Subject: RFR: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version [v3] In-Reply-To: <39AGTdtDvdrK4-xT9DvsU5IqSJxplIHzyrl1bjToTQg=.420ea5b4-9344-4eba-9816-5b192bda1a3f@github.com> References: <39AGTdtDvdrK4-xT9DvsU5IqSJxplIHzyrl1bjToTQg=.420ea5b4-9344-4eba-9816-5b192bda1a3f@github.com> Message-ID: On Fri, 13 Jan 2023 21:15:18 GMT, Erik Joelsson wrote: >> In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: >> >> >> "prbranch": { >> "protect": true, >> }, >> >> The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) >> >> I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. > > Erik Joelsson has updated the pull request incrementally with one additional commit since the last revision: > > Renamed parameter Looks good. Great that you actually managed to find a workaround for this limitation in Gitlab! ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.org/skara/pull/1452 From zsong at openjdk.org Wed Jan 18 19:16:18 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 19:16:18 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments Message-ID: A user reported that Skara bots were not responding to commands in review comments or the body of a review. This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. ------------- Commit messages: - SKARA-1789 Changes: https://git.openjdk.org/skara/pull/1458/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1789 Stats: 58 lines in 2 files changed: 55 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1458.diff Fetch: git fetch https://git.openjdk.org/skara pull/1458/head:pull/1458 PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Wed Jan 18 19:16:18 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 19:16:18 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:04:42 GMT, Zhao Song wrote: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 245: > 243: comments.addAll(pr.reviewComments().stream() > 244: .map(reviewComment -> new Comment("ReviewComment" + reviewComment.id(), reviewComment.body(), reviewComment.author(), reviewComment.createdAt(), reviewComment.updatedAt())) > 245: .toList()); I am not sure if the "review", "review comment", and "comment" in Github refer to the same numbering system, but based on my experiments, it is likely that they have their own independent numbering system. Although the probability of ID conflicts is small, I think it would be better to add "review" before the ID of a review, and "ReviewComment" before the ID of a review comment. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Wed Jan 18 19:59:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 19:59:06 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:04:42 GMT, Zhao Song wrote: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. I will need to think more on what this means and how it would work. The bug only asked for adding commands in `Review`, not `ReviewComment`. I don't think it makes sense to run commands in a `ReviewComment`. (The latter is a comment on a specific file or line inside a review) If we do this, then commands must still be processed in order, so the list needs to be sorted on create time. We also need to consider how this applies to Gitlab, where reviews are different. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Wed Jan 18 19:59:06 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 19:59:06 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 19:54:18 GMT, Erik Joelsson wrote: > We also need to consider how this applies to Gitlab, where reviews are different. In GitLab Reviews don't have a body, so this wouldn't have any effect there at least. ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Wed Jan 18 20:07:19 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 20:07:19 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 19:54:18 GMT, Erik Joelsson wrote: > I will need to think more on what this means and how it would work. The bug only asked for adding commands in `Review`, not `ReviewComment`. I don't think it makes sense to run commands in a `ReviewComment`. (The latter is a comment on a specific file or line inside a review) > > If we do this, then commands must still be processed in order, so the list needs to be sorted on create time. > > We also need to consider how this applies to Gitlab, where reviews are different. In the description of the bug, Magnus said "I guess the same goes if you would make a single comment in review mode as well, but I have not tested this. ". I thought he would expect the command in single comment(which is reviewComment) could be interpreted too. I don't know whether we need it or not. It's a good point that we should sort the comments by created time. I will fix it now. ------------- PR: https://git.openjdk.org/skara/pull/1458 From ihse at openjdk.org Wed Jan 18 20:07:19 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 18 Jan 2023 20:07:19 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:04:42 GMT, Zhao Song wrote: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. I am a bit uncertain about PR commands in review comments. I don't think there is much of a use case for that, and if it is costly for us to process, I think we can skip it. But otoh, if the overhead is not an issue, I think having a consistent UX is a good thing. If someone were to be adding a PR command in a comment, they will be surprised if it doesn't work. But the main part is the review itself, yes. That definitely feels like a "normal" comment. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Wed Jan 18 20:07:20 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 20:07:20 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:08:54 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 245: > >> 243: comments.addAll(pr.reviewComments().stream() >> 244: .map(reviewComment -> new Comment("ReviewComment" + reviewComment.id(), reviewComment.body(), reviewComment.author(), reviewComment.createdAt(), reviewComment.updatedAt())) >> 245: .toList()); > > I am not sure if the "review", "review comment", and "comment" in Github refer to the same numbering system, but based on my experiments, it is likely that they have their own independent numbering system. Although the probability of ID conflicts is small, I think it would be better to add "review" before the ID of a review, and "ReviewComment" before the ID of a review comment. Have you found a conflict? I did a quick check and didn't find any, but that's definitely no guarantee. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Wed Jan 18 20:43:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 20:43:22 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:02:56 GMT, Zhao Song wrote: > In the description of the bug, Magnus said "I guess the same goes if you would make a single comment in review mode as well, but I have not tested this. ". I thought he would expect the command in single comment(which is reviewComment) could be interpreted too. I don't know whether we need it or not. You are right, I misinterpreted that part. > I am a bit uncertain about PR commands in review comments. I don't think there is much of a use case for that, and if it is costly for us to process, I think we can skip it. But otoh, if the overhead is not an issue, I think having a consistent UX is a good thing. If someone were to be adding a PR command in a comment, they will be surprised if it doesn't work. My concern is that review threads can be marked as resolved and no longer visible. They can also be hard to find if the author force pushes to the source branch. It makes it hard to backtrack through the comment history to understand when a command was issued. ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Wed Jan 18 20:43:22 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 20:43:22 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:04:46 GMT, Erik Joelsson wrote: > Have you found a conflict? I did a quick check and didn't find any, but that's definitely no guarantee. No I didn't found a conflict. But in my experiment, the id of comments are around **1,322,767,076**, id of reviewComments are around **1,072,885,574**, id of reviews are around **1,252,530,272**. If the growth rate of id of reviewComment is greater than that of review, then there is a likelihood that their ids will conflict. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Wed Jan 18 20:43:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 18 Jan 2023 20:43:22 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:39:43 GMT, Zhao Song wrote: >> Have you found a conflict? I did a quick check and didn't find any, but that's definitely no guarantee. > >> Have you found a conflict? I did a quick check and didn't find any, but that's definitely no guarantee. > > No I didn't found a conflict. But in my experiment, the id of comments are around **1,322,767,076**, id of reviewComments are around **1,072,885,574**, id of reviews are around **1,252,530,272**. If the growth rate of id of reviewComment is greater than that of review, then there is a likelihood that their ids will conflict. I thought some more on your proposed solution here and I think it's sound. ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Wed Jan 18 21:41:03 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 21:41:03 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: Message-ID: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: sort comments by created time ------------- Changes: - all: https://git.openjdk.org/skara/pull/1458/files - new: https://git.openjdk.org/skara/pull/1458/files/7faa5ec3..377bab8c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=00-01 Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1458.diff Fetch: git fetch https://git.openjdk.org/skara pull/1458/head:pull/1458 PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Wed Jan 18 21:44:45 2023 From: zsong at openjdk.org (Zhao Song) Date: Wed, 18 Jan 2023 21:44:45 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 20:39:38 GMT, Erik Joelsson wrote: > > In the description of the bug, Magnus said "I guess the same goes if you would make a single comment in review mode as well, but I have not tested this. ". I thought he would expect the command in single comment(which is reviewComment) could be interpreted too. I don't know whether we need it or not. > > You are right, I misinterpreted that part. > > > I am a bit uncertain about PR commands in review comments. I don't think there is much of a use case for that, and if it is costly for us to process, I think we can skip it. But otoh, if the overhead is not an issue, I think having a consistent UX is a good thing. If someone were to be adding a PR command in a comment, they will be surprised if it doesn't work. > > My concern is that review threads can be marked as resolved and no longer visible. They can also be hard to find if the author force pushes to the source branch. It makes it hard to backtrack through the comment history to understand when a command was issued. Due to Erik's concern, I think it would be better to temporarily disregard commands within ReviewComments. If a use case for this feature is identified in the future, we can revisit the topic. ------------- PR: https://git.openjdk.org/skara/pull/1458 From dholmes at openjdk.org Thu Jan 19 06:44:34 2023 From: dholmes at openjdk.org (David Holmes) Date: Thu, 19 Jan 2023 06:44:34 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Wed, 18 Jan 2023 21:41:03 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > sort comments by created time I also have misgivings about scanning review comments for PR commands - so it seems there is consensus there. Even in the main review comment what gets scanned - all the text? Only the start of lines? I would worry about text being misconstrued as a command. This would especially be true for skara PRs where review comments may well refer to PR commands as part of the discussion. ------------- PR: https://git.openjdk.org/skara/pull/1458 From kcr at openjdk.org Thu Jan 19 12:54:18 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Jan 2023 12:54:18 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Thu, 19 Jan 2023 06:42:14 GMT, David Holmes wrote: > I also have misgivings about scanning review comments for PR commands - so it seems there is consensus there. I definitely agree with David and others on this. > Even in the main review comment what gets scanned - all the text? Only the start of lines? I would worry about text being misconstrued as a command. This would especially be true for skara PRs where review comments may well refer to PR commands as part of the discussion. If it works the same as PR commands in ordinary comments, they are only parsed at the beginning of a line after trimming whitespace. @erikj79 or @zhaosongzs can confirm. ------------- PR: https://git.openjdk.org/skara/pull/1458 From ihse at openjdk.org Thu Jan 19 14:44:28 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 19 Jan 2023 14:44:28 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Wed, 18 Jan 2023 21:41:03 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > sort comments by created time It sounds reasonable to not allow PR comments in review comments on individual lines, yes. As Erik says, they are presented differently, can be hidden, and form a "different kind" of communication. I still think the main review "comment" (or whatever to call it) deserves to be parsed for PR comments. Once it is posted, it looks just like a regular comment. If it were not for Skara treating this differently, I would have had no idea it was even treated differently internally in Github. To me, it is like a "approve this PR + also add this comment", not "approve this PR with this special kind of comment that can only be generated here but looks like any other normal comment". David: > Even in the main review comment what gets scanned - all the text? Only the start of lines? I would worry about text being misconstrued as a command. This would especially be true for skara PRs where review comments may well refer to PR commands as part of the discussion. I am not sure what you mean by that? My example is the kind of comment I've been doing far too many times before remembering that it will not work, I look at a change, check the build changes, presses the green button, selects "Approve" and writes: This looks good from a build perspective, but you'll need someone from core-libs to check it as well. *LOL* Thank you @openjdk bot for providing a quick example that the risk for "misconstruing" commands are just as present in normal commands, and not something that will be a special problems for main review comments. :-D ------------- PR: https://git.openjdk.org/skara/pull/1458 From kcr at openjdk.org Thu Jan 19 16:01:15 2023 From: kcr at openjdk.org (Kevin Rushforth) Date: Thu, 19 Jan 2023 16:01:15 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Wed, 18 Jan 2023 21:41:03 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > sort comments by created time Since there is general agreement not to attempt to use inline "file" comments, I left a couple suggestions to remove some commented out code. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 233: > 231: > 232: /** > 233: * This method returns all the comments in the pr including comments in reviews(review body) and file specific comments Given the discussion around only using "ordinary" PR comments, and not inline comments, I think the "and file specific comments" part is now wrong. bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 245: > 243: // comments.addAll(pr.reviewComments().stream() > 244: // .map(reviewComment -> new Comment("ReviewComment" + reviewComment.id(), reviewComment.body(), reviewComment.author(), reviewComment.createdAt(), reviewComment.updatedAt())) > 245: // .toList()); Since we have decided not to do this, I recommend to remove this commented out code. bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestCommandTests.java line 395: > 393: // // Run the bot > 394: // TestBotRunner.runPeriodicItems(prBot); > 395: // assertLastCommentContains(pr, "The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 4"); Ditto the recommendation to remove this. ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 16:48:21 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 16:48:21 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Thu, 19 Jan 2023 15:56:42 GMT, Kevin Rushforth wrote: > Given the discussion around only using "ordinary" PR comments, and not inline comments, I think the "and file specific comments" part is now wrong. Good catch! Thanks Kevin. Will fix it. > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 245: > >> 243: // comments.addAll(pr.reviewComments().stream() >> 244: // .map(reviewComment -> new Comment("ReviewComment" + reviewComment.id(), reviewComment.body(), reviewComment.author(), reviewComment.createdAt(), reviewComment.updatedAt())) >> 245: // .toList()); > > Since we have decided not to do this, I recommend to remove this commented out code. Sure > bots/pr/src/test/java/org/openjdk/skara/bots/pr/PullRequestCommandTests.java line 395: > >> 393: // // Run the bot >> 394: // TestBotRunner.runPeriodicItems(prBot); >> 395: // assertLastCommentContains(pr, "The total number of required reviews for this PR (including the jcheck configuration and the last /reviewers command) is now set to 4"); > > Ditto the recommendation to remove this. Sure ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 16:53:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 16:53:53 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: On Thu, 19 Jan 2023 12:51:58 GMT, Kevin Rushforth wrote: > > I also have misgivings about scanning review comments for PR commands - so it seems there is consensus there. > > I definitely agree with David and others on this. > > > Even in the main review comment what gets scanned - all the text? Only the start of lines? I would worry about text being misconstrued as a command. This would especially be true for skara PRs where review comments may well refer to PR commands as part of the discussion. > > If it works the same as PR commands in ordinary comments, they are only parsed at the beginning of a line after trimming whitespace. @erikj79 or @zhaosongzs can confirm. Yes, you are right. It just works the same as PR commands in regular comments. ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 17:41:27 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 17:41:27 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v3] In-Reply-To: References: Message-ID: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: remove some comments and add tests ------------- Changes: - all: https://git.openjdk.org/skara/pull/1458/files - new: https://git.openjdk.org/skara/pull/1458/files/377bab8c..c5cb717e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=01-02 Stats: 17 lines in 2 files changed: 7 ins; 4 del; 6 mod Patch: https://git.openjdk.org/skara/pull/1458.diff Fetch: git fetch https://git.openjdk.org/skara pull/1458/head:pull/1458 PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Thu Jan 19 19:36:22 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 19:36:22 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v3] In-Reply-To: References: Message-ID: <6l9brq-Pr5b0WBAP2pWXPcCVBa78ai4XnT3wzVZBpUE=.31f167c2-f2ea-42ec-8973-dcea35e374f3@github.com> On Thu, 19 Jan 2023 17:41:27 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > remove some comments and add tests Marked as reviewed by erikj (Lead). bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 237: > 235: private List getAllComments() { > 236: // Regular comments > 237: List comments = new ArrayList<>(prComments()); It's not really important, but you could use Streams.concat() instead of creating two intermediate lists. ------------- PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Thu Jan 19 19:41:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 19:41:23 GMT Subject: Integrated: 1715: Configure custom default security level for new backport issues in notifier In-Reply-To: References: Message-ID: On Thu, 15 Dec 2022 22:12:29 GMT, Erik Joelsson wrote: > This patch makes it possible to configure a default security level to use for any newly created backport in the IssueNotifier. The configuration is done per repository and branch, with a regex for matching branch names. This is what it would look like in the bot configuration. > > > "issue": { > "project": "bugs/JDK", > "fixversions": {}, > "buildname": "master", > "headversion": true, > "defaultsecurity": { // <- new > "jdk.*": "10000", > } > } > > > If the parent bug already has a security level, then that is inherited, just like today, otherwise this new default value is used. This pull request has now been integrated. Changeset: bbb8690b Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/bbb8690b86d663b91beb8db9a713c31692aac5d7 Stats: 136 lines in 6 files changed: 125 ins; 0 del; 11 mod 1715: Configure custom default security level for new backport issues in notifier Reviewed-by: zsong, ihse ------------- PR: https://git.openjdk.org/skara/pull/1445 From erikj at openjdk.org Thu Jan 19 19:43:32 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 19:43:32 GMT Subject: Integrated: 1699: CommitCommentsWorkItem does excessive unnecessary work In-Reply-To: References: Message-ID: On Tue, 20 Dec 2022 21:14:41 GMT, Erik Joelsson wrote: > The `CommitCommentsWorkItem` gets scheduled once for each repository by `PullRequestBot::getPeriodicItems`. It's responsible for querying the repository for new comments on commits, and if any are found, spawn `CommitCommandWorkItem` for them. It's unfortunately not very straight forward to query forges for new commit comments. For GitHub we have a rather complicated GraphQL that does the trick, but for GitLab, we need to jump through some rather nasty hoops. > > The main issue is that the data we get from the "events" query from GitLab contains notes posted to commits, but without the commit hash. We only get the commit "title" to identify which commit was commented on. To solve this, we have a rather elaborate logic that first builds a complete map from title to set of hashes for every commit in the repo. This is done preemptively on a local clone of the repo. Using this map and some clever comparisons, we can figure out which commit each comment belongs to. > > I don't have data on how long it takes to build this map for a big repository, like the JDK, but it's likely not trivially short. In addition to this, before using any local clone of a repository, we always run the git fsck check (see [SKARA-1598](https://bugs.openjdk.org/browse/SKARA-1598)), which can take around 20s for the JDK repo. The local clone is unfortunately also used to check if the commits for the found comments belong to a valid branch. However, both of these operations are read only, so we shouldn't really need a clone for this. We should be fine just using the seed repository directly from the `HostedRepositoryPool`. > > This patch tries to make this situation better in several ways. > > 1. Use the seed repository instead of a clone in `CommitCommentsWorkItem`. (Removes ~20s fsck time every time this is scheduled for a jdk repository, which is in the order of once a minute times the numer of JDK repo clones that Skara operates on) > 2. Refactored `HostedRepository::recentCommitComments` to take a `ReadOnlyRepository` instead of the pre calculated map. `GitLabRepository` is then responsible for using this repository to build the map itself. > 3. `HostedRepository::recentCommitComments` now takes an `updatedAfter` arg to limit the number of comments that get returned. In `GitLabRepository` this was already limited to last 4 days, but in `GitHubRepository`, we just got the last 100 comments, regardless of age (due to a limitation in GraphQL). We can still filter the returned comments on updatedAt so that we get less comments to process in many cases. This should make a big impact on bot restarts. > 4. `CommitCommentsWorkItem` has a configuration option to ignore comments from certain users (typically meant for bot users, e.g. the notifier who posts a comment on every commit). This configuration wasn't working due to a bug in the factory. (Together with 3, should bring down the number of scheduled `CommitCommandWorkItem` on bot restart from 100 per repo to a handful and often 0.) > 5. `GitLabRepository` keeps a cached copy of the commitTitleToHash map. It will also only build or update the map if any new notes are actually found. (This won't have a huge impact, but should speed things up a little bit more) This pull request has now been integrated. Changeset: c6f7ce8b Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/c6f7ce8b42f7ade041014934c646c53644ab0d9f Stats: 117 lines in 7 files changed: 77 ins; 21 del; 19 mod 1699: CommitCommentsWorkItem does excessive unnecessary work Reviewed-by: zsong, ihse ------------- PR: https://git.openjdk.org/skara/pull/1446 From erikj at openjdk.org Thu Jan 19 19:44:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 19:44:03 GMT Subject: Integrated: 1173: Dependent PR feature does not work with protected branches in newer Gitlab version In-Reply-To: References: Message-ID: On Tue, 3 Jan 2023 17:24:36 GMT, Erik Joelsson wrote: > In GitLab, if a branch is protected, it cannot be removed. This is preventing us from using the pr/X feature of Skara to support dependent pull requests. This patch adds the ability to dynamically protect and unprotect branch patterns when creating pr/X branches. This is controlled with a new configuration option on the prbranch notifier like this: > > > "prbranch": { > "protect": true, > }, > > The semantics needed for GitLab is to first add a pattern based protection rule, then create the branch. Unfortunately, I couldn't easily implement the same semantics for GitHubRepository. The REST API for branch protection in GitHub doesn't allow patterns, only existing branches. It could probably be done using GraphQL, but given how complicated that would be to implement, I chose not to, since we don't actually need this feature on GitHub. (GitHub branch protection is flexible enough so we can have a static configuration that allows admins to delete branches, and this is already in use today) > > I have tested the basic branch protection functionality using the new manual test and I have run the notifier bot with the new configuration against a playground repository in GitLab and manually created and closed PRs. This pull request has now been integrated. Changeset: 5823b37f Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/5823b37f47256417601ec4275be6a2b3958265c6 Stats: 127 lines in 9 files changed: 122 ins; 0 del; 5 mod 1173: Dependent PR feature does not work with protected branches in newer Gitlab version Reviewed-by: zsong, ihse ------------- PR: https://git.openjdk.org/skara/pull/1452 From erikj at openjdk.org Thu Jan 19 19:44:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 19:44:23 GMT Subject: Integrated: 1731: Improve RestRequestCache rate limiter In-Reply-To: References: Message-ID: <90_83bfAOi7XfXdPpo2T3PDyXZ7AXXZLNkMSWgsjNik=.276c774d-5607-4fcb-8755-06a7565e3eef@github.com> On Tue, 3 Jan 2023 18:15:36 GMT, Erik Joelsson wrote: > In the RestRequestCache, we are trying to limit non GET calls for a specific host and user to one call per second (and all calls, including GET, for a specific host and user, need to be serialized). This throttling is based on recommendations from GitHub (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-abuse-rate-limits). The current implementation isn't really doing that however. Calls are serialized, but depending on timing, we can definitely send more than one non GET call per second, at least in bursts. > > This patch tries to rework this, using two locks. During high contention, it's possible that this new implementation will be less favorable to non GET calls than the current implementation, but I'm pretty sure we will at least adhere to the recommendation of performing at most one non-GET call per second. See bug for breakdown of locking order. This pull request has now been integrated. Changeset: 4a6330c1 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/4a6330c1f789c9433295c02e56a7e9a1be26c1e1 Stats: 32 lines in 1 file changed: 12 ins; 10 del; 10 mod 1731: Improve RestRequestCache rate limiter Reviewed-by: zsong, ihse ------------- PR: https://git.openjdk.org/skara/pull/1453 From zsong at openjdk.org Thu Jan 19 19:54:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 19:54:38 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v4] In-Reply-To: References: Message-ID: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - delete useless import - fix a problem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1458/files - new: https://git.openjdk.org/skara/pull/1458/files/c5cb717e..5d13903c Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=02-03 Stats: 9 lines in 2 files changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1458.diff Fetch: git fetch https://git.openjdk.org/skara pull/1458/head:pull/1458 PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 19:54:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 19:54:38 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v3] In-Reply-To: <6l9brq-Pr5b0WBAP2pWXPcCVBa78ai4XnT3wzVZBpUE=.31f167c2-f2ea-42ec-8973-dcea35e374f3@github.com> References: <6l9brq-Pr5b0WBAP2pWXPcCVBa78ai4XnT3wzVZBpUE=.31f167c2-f2ea-42ec-8973-dcea35e374f3@github.com> Message-ID: On Thu, 19 Jan 2023 19:33:26 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> remove some comments and add tests > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/PullRequestCommandWorkItem.java line 237: > >> 235: private List getAllComments() { >> 236: // Regular comments >> 237: List comments = new ArrayList<>(prComments()); > > It's not really important, but you could use Streams.concat() instead of creating two intermediate lists. It would be better ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 21:07:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 21:07:38 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v5] In-Reply-To: References: Message-ID: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: rename test method ------------- Changes: - all: https://git.openjdk.org/skara/pull/1458/files - new: https://git.openjdk.org/skara/pull/1458/files/5d13903c..0a3206a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1458&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1458.diff Fetch: git fetch https://git.openjdk.org/skara pull/1458/head:pull/1458 PR: https://git.openjdk.org/skara/pull/1458 From erikj at openjdk.org Thu Jan 19 21:42:57 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 19 Jan 2023 21:42:57 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v5] In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 21:07:38 GMT, Zhao Song wrote: >> A user reported that Skara bots were not responding to commands in review comments or the body of a review. >> >> This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > rename test method Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Thu Jan 19 23:18:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 19 Jan 2023 23:18:53 GMT Subject: RFR: 1725: Clarify "no known role" error message Message-ID: A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: (no known github.com user name / role) What it actually means is "no known OpenJDK user name / role". Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. ------------- Commit messages: - SKARA-1725 Changes: https://git.openjdk.org/skara/pull/1459/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1459&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1725 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1459.diff Fetch: git fetch https://git.openjdk.org/skara pull/1459/head:pull/1459 PR: https://git.openjdk.org/skara/pull/1459 From zsong at openjdk.org Fri Jan 20 00:08:54 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 20 Jan 2023 00:08:54 GMT Subject: Integrated: 1789: Skara PR commands are not interpreted on Github review comments In-Reply-To: References: Message-ID: On Wed, 18 Jan 2023 18:04:42 GMT, Zhao Song wrote: > A user reported that Skara bots were not responding to commands in review comments or the body of a review. > > This patch addresses that issue by ensuring that the Skara bots can correctly detect and interpret commands. This pull request has now been integrated. Changeset: 2d70b1bd Author: Zhao Song URL: https://git.openjdk.org/skara/commit/2d70b1bd4736fd1e0ea6773b8594875434cccdf6 Stats: 56 lines in 2 files changed: 53 ins; 0 del; 3 mod 1789: Skara PR commands are not interpreted on Github review comments Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1458 From dholmes at openjdk.org Fri Jan 20 02:43:49 2023 From: dholmes at openjdk.org (David Holmes) Date: Fri, 20 Jan 2023 02:43:49 GMT Subject: RFR: 1789: Skara PR commands are not interpreted on Github review comments [v2] In-Reply-To: References: <8cTgtS81Jj2i8j6Nz2jmoJP5rFgbNXXChYkDrtCtot4=.836d8560-54cd-4c20-a830-2accd665f6ab@github.com> Message-ID: <2-FuHQfpQtyXrCdjrBiQxtZZIhEMr5hJE_aF928cZT4=.4c39adeb-d73d-44f6-8afe-b2f759010b6c@github.com> On Thu, 19 Jan 2023 14:42:10 GMT, Magnus Ihse Bursie wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> sort comments by created time > > *LOL* > > Thank you @openjdk bot for providing a quick example that the risk for "misconstruing" commands are just as present in normal commands, and not something that will be a special problems for main review comments. :-D @magicus you demonstrated my concern about misconstrued comments beautifully - thank you :) If they are only processed as commands at the start of the line that greatly reduces the risk and concern, and for the rest people just have to be careful. :) ------------- PR: https://git.openjdk.org/skara/pull/1458 From zsong at openjdk.org Fri Jan 20 21:40:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 20 Jan 2023 21:40:23 GMT Subject: RFR: 1799: Do not notify on Withdrawn CSR issue Message-ID: In [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), we will add '(Withdrawn)' to withdrawn CSR issues shown in the pr body. However, this will cause a small bug in the notify bot which the issueNotifier will add a review link to withdrawn CSR issues. To fix this, simply update the filter in the notify/PullRequestWorkItem#parseIssues method. ------------- Commit messages: - SKARA-1799 Changes: https://git.openjdk.org/skara/pull/1460/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1460&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1799 Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod Patch: https://git.openjdk.org/skara/pull/1460.diff Fetch: git fetch https://git.openjdk.org/skara pull/1460/head:pull/1460 PR: https://git.openjdk.org/skara/pull/1460 From erikj at openjdk.org Fri Jan 20 21:44:20 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 20 Jan 2023 21:44:20 GMT Subject: RFR: 1799: Do not notify on Withdrawn CSR issue In-Reply-To: References: Message-ID: <1XYyAK_SyOgTa5iSHzrmQuli--85DdGjIrovlIFz0wY=.de62dd0b-77ba-480c-80de-5a54771352d6@github.com> On Fri, 20 Jan 2023 20:40:04 GMT, Zhao Song wrote: > In [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), we will add '(Withdrawn)' to withdrawn CSR issues shown in the pr body. However, this will cause a small bug in the notify bot which the issueNotifier will add a review link to withdrawn CSR issues. To fix this, simply update the filter in the notify/PullRequestWorkItem#parseIssues method. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1460 From zsong at openjdk.org Fri Jan 20 21:50:51 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 20 Jan 2023 21:50:51 GMT Subject: Integrated: 1799: Do not notify on Withdrawn CSR issue In-Reply-To: References: Message-ID: On Fri, 20 Jan 2023 20:40:04 GMT, Zhao Song wrote: > In [SKARA-1714](https://bugs.openjdk.org/browse/SKARA-1714), we will add '(Withdrawn)' to withdrawn CSR issues shown in the pr body. However, this will cause a small bug in the notify bot which the issueNotifier will add a review link to withdrawn CSR issues. To fix this, simply update the filter in the notify/PullRequestWorkItem#parseIssues method. This pull request has now been integrated. Changeset: 12e3cdc6 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/12e3cdc69142797dd68c189ece2d5afe68590cca Stats: 19 lines in 2 files changed: 14 ins; 0 del; 5 mod 1799: Do not notify on Withdrawn CSR issue Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1460 From ihse at openjdk.org Mon Jan 23 11:03:26 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jan 2023 11:03:26 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 22:27:09 GMT, Zhao Song wrote: > A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: > > (no known github.com user name / role) > > What it actually means is "no known OpenJDK user name / role". > > Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. And the OpenJDK census name ends with `-OpenJDK`, so the effect is to output `no known OpenJDK user name / role`? ------------- PR: https://git.openjdk.org/skara/pull/1459 From ihse at openjdk.org Mon Jan 23 11:03:44 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jan 2023 11:03:44 GMT Subject: RFR: Comment detailing refspec format in GitRepository#push In-Reply-To: References: Message-ID: <_tvBB1hyBnJ7IabiRNnLnhqJuLwY5-vxXkTPzD1xW9U=.3855f75d-d242-4e7e-afc5-58211bd1fb9a@github.com> On Thu, 22 Dec 2022 18:02:49 GMT, Julian Waters wrote: > Small change to document the git refspec field in GitRepository#push via comment Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1448 From jwaters at openjdk.org Mon Jan 23 11:50:14 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 23 Jan 2023 11:50:14 GMT Subject: RFR: Comment detailing refspec format in GitRepository#push In-Reply-To: References: Message-ID: On Thu, 22 Dec 2022 18:02:49 GMT, Julian Waters wrote: > Small change to document the git refspec field in GitRepository#push via comment Ah, thanks Magnus ------------- PR: https://git.openjdk.org/skara/pull/1448 From jwaters at openjdk.org Mon Jan 23 13:08:41 2023 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 23 Jan 2023 13:08:41 GMT Subject: Integrated: Comment detailing refspec format in GitRepository#push In-Reply-To: References: Message-ID: On Thu, 22 Dec 2022 18:02:49 GMT, Julian Waters wrote: > Small change to document the git refspec field in GitRepository#push via comment This pull request has now been integrated. Changeset: f6c928a5 Author: Julian Waters Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/skara/commit/f6c928a5ee5285dc24bc5991efa023733eaf184b Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod Comment detailing refspec format in GitRepository#push Reviewed-by: ihse ------------- PR: https://git.openjdk.org/skara/pull/1448 From erikj at openjdk.org Mon Jan 23 14:18:28 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 23 Jan 2023 14:18:28 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: <3D5O7jy0Ju9xVTd9_HgHWU_AMZq9NyWr-0c2vWT-DyU=.8eff8d0e-1782-48db-bc35-539edbad6a16@github.com> On Thu, 19 Jan 2023 22:27:09 GMT, Zhao Song wrote: > A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: > > (no known github.com user name / role) > > What it actually means is "no known OpenJDK user name / role". > > Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. I'm not sure using the name of the internal data repository as the source for this error message is the right thing. Maybe we need to add some new field to the census data that we can extract. ------------- PR: https://git.openjdk.org/skara/pull/1459 From erikj at openjdk.org Mon Jan 23 14:25:28 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 23 Jan 2023 14:25:28 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 22:27:09 GMT, Zhao Song wrote: > A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: > > (no known github.com user name / role) > > What it actually means is "no known OpenJDK user name / role". > > Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. The jcheck configuration has a field `domain` in the `[census]` section, perhaps that would be a better description of the space we are looking for the user in? In the OpenJDK projects, this field has the value `openjdk.org` (internally we use oracle.com). ------------- PR: https://git.openjdk.org/skara/pull/1459 From ihse at openjdk.org Mon Jan 23 15:15:43 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 23 Jan 2023 15:15:43 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: On Thu, 19 Jan 2023 22:27:09 GMT, Zhao Song wrote: > A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: > > (no known github.com user name / role) > > What it actually means is "no known OpenJDK user name / role". > > Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. I think "has no OpenJDK user name" is better than "has no openjdk.org user name", so we would need to do something about that if we were to use that field. A "openjdk.org user name" sounds like something you could use on the home page, which is not a thing. The accounts we are talking about are commonly referred to as "OpenJDK user name" and I think we should stay with that terminology. ------------- PR: https://git.openjdk.org/skara/pull/1459 From zsong at openjdk.org Mon Jan 23 17:41:47 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 23 Jan 2023 17:41:47 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 11:00:37 GMT, Magnus Ihse Bursie wrote: > And the OpenJDK census name ends with `-OpenJDK`, so the effect is to output `no known OpenJDK user name / role`? Yes, exactly. ------------- PR: https://git.openjdk.org/skara/pull/1459 From zsong at openjdk.org Mon Jan 23 18:25:27 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 23 Jan 2023 18:25:27 GMT Subject: RFR: 1725: Clarify "no known role" error message In-Reply-To: References: Message-ID: On Mon, 23 Jan 2023 14:23:11 GMT, Erik Joelsson wrote: > The jcheck configuration has a field `domain` in the `[census]` section, perhaps that would be a better description of the space we are looking for the user in? In the OpenJDK projects, this field has the value `openjdk.org` (internally we use oracle.com). Yes, it's a good idea to use this field `domain`. Thx! ------------- PR: https://git.openjdk.org/skara/pull/1459 From zsong at openjdk.org Mon Jan 23 18:40:49 2023 From: zsong at openjdk.org (Zhao Song) Date: Mon, 23 Jan 2023 18:40:49 GMT Subject: RFR: 1725: Clarify "no known role" error message [v2] In-Reply-To: References: Message-ID: <405Su3P5Yakgs6gX33XK8MaROwhqMDyy1dRHkSbVQDk=.e1ffb9a8-615b-4210-970e-168f555c17bd@github.com> > A user reported that when people review PRs, the bot adds a list of reviewers into description. If a user is not registered in OpenJDK Census, a note is added: > > (no known github.com user name / role) > > What it actually means is "no known OpenJDK user name / role". > > Github.com is being used here because we are utilizing the name of the namespace. However, the purpose of the namespace is to map users from this namespace to either openjdk or internal. Actually, we couldn't find the user in openjdk or internal, not in the namespace. The census repository name can indicate whether it is openjdk or internal. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix a problem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1459/files - new: https://git.openjdk.org/skara/pull/1459/files/ab6d260e..d6479ee3 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1459&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1459&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1459.diff Fetch: git fetch https://git.openjdk.org/skara pull/1459/head:pull/1459 PR: https://git.openjdk.org/skara/pull/1459 From erikj at openjdk.org Tue Jan 24 14:45:43 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jan 2023 14:45:43 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter Message-ID: In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. Two PRs were unable to integrate yesterday due to this contention: https://github.com/openjdk/jdk/pull/12139 https://github.com/openjdk/jdk/pull/11922 ------------- Commit messages: - SKARA-1801 Changes: https://git.openjdk.org/skara/pull/1461/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1461&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1801 Stats: 19 lines in 4 files changed: 10 ins; 0 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1461.diff Fetch: git fetch https://git.openjdk.org/skara pull/1461/head:pull/1461 PR: https://git.openjdk.org/skara/pull/1461 From ihse at openjdk.org Tue Jan 24 16:15:37 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 24 Jan 2023 16:15:37 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 You don't think we need to explicitly track GraphQL "points" to allow the rate limiter in RestRequest allow for future GraphQL requests which are more expensive? Your comment seem to indicate that you have manually analyzed our current GraphQL requests and come to the conclusion that they are worth 1 point each. ------------- PR: https://git.openjdk.org/skara/pull/1461 From ihse at openjdk.org Tue Jan 24 16:17:51 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 24 Jan 2023 16:17:51 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 Basically, what I think I am suggesting, is that instead of a `skipLimit` boolean, we should have a `graphQlPoints`, which we can set to 0 for normal REST calls. And if it is non-zero, the rate limits counts towards the graph QL point limit instead. If we know that we stay way below the 5000 per hour, we can skip the actual limitation for now, but that would make it easy to inject such a check in the future. Or, we could do it properly from the start, and add a check that the accumulated QL points do not exceed the limit. ------------- PR: https://git.openjdk.org/skara/pull/1461 From erikj at openjdk.org Tue Jan 24 17:00:15 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jan 2023 17:00:15 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 > You don't think we need to explicitly track GraphQL "points" to allow the rate limiter in RestRequest allow for future GraphQL requests which are more expensive? Your comment seem to indicate that you have manually analyzed our current GraphQL requests and come to the conclusion that they are worth 1 point each. > Basically, what I think I am suggesting, is that instead of a `skipLimit` boolean, we should have a `graphQlPoints`, which we can set to 0 for normal REST calls. And if it is non-zero, the rate limits counts towards the graph QL point limit instead. > > If we know that we stay way below the 5000 per hour, we can skip the actual limitation for now, but that would make it easy to inject such a check in the future. Or, we could do it properly from the start, and add a check that the accumulated QL points do not exceed the limit. That's an interesting idea. Can we keep it i mind for future improvements? Especially if we end up trying to implement more complex GraphQL queries in the future. I think implementing what you suggest in a useful way is a bit more complex. With the current set of queries, I would prefer not to make things more complicated right now. I have monitored the current bot using a manual GraphQL query for current points. Our bot user has 12500 points per hour and we are currently well within that. ------------- PR: https://git.openjdk.org/skara/pull/1461 From ihse at openjdk.org Tue Jan 24 17:05:24 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 24 Jan 2023 17:05:24 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 Marked as reviewed by ihse (Reviewer). Sure, let's keep that in store for the future. ------------- PR: https://git.openjdk.org/skara/pull/1461 From erikj at openjdk.org Tue Jan 24 17:21:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jan 2023 17:21:03 GMT Subject: RFR: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 Thanks! ------------- PR: https://git.openjdk.org/skara/pull/1461 From erikj at openjdk.org Tue Jan 24 17:21:03 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jan 2023 17:21:03 GMT Subject: Integrated: 1801: Exclude some GraphQL calls from RestRequestCache rate limiter In-Reply-To: References: Message-ID: <37a3L4ej8Zcm0TySeD6sz-EuveM0r6D1Jn1kZ2gU1cs=.12c506e4-e2e3-4d77-aefc-ef8183fd42b7@github.com> On Tue, 24 Jan 2023 14:41:46 GMT, Erik Joelsson wrote: > In [SKARA-1731](https://bugs.openjdk.org/browse/SKARA-1731), the best practices regarding non GET requests on Github became better enforced. Unfortunately that has lead to some unexpected performance issues. I believe this is mostly caused by GraphQL requests, which are always POST, being treated as a non GET REST requests by the limiter and limited to one per second. This limitation on a subset of our github queries is currently causing a queue buildup for that lock, which stabilizes to about 1m wait time. This delay is slowing down response times from the bots massively. > > Reading the Integrator best practices document again (https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28) and the GraphQL resource limitations (https://docs.github.com/en/graphql/overview/resource-limitations) I'm pretty sure you aren't supposed to limit GraphQL to one call per second, but rather just make sure you stay within the points limit. The one per second recommendation is for the REST API. > > I want to make it possible to exclude certain calls from this rate limiter to see if this can alleviate the contention we are currently seeing. I have run with this patch for the pr bot since yesterday afternoon (PT) and it seems to be working well. > > Two PRs were unable to integrate yesterday due to this contention: > https://github.com/openjdk/jdk/pull/12139 > https://github.com/openjdk/jdk/pull/11922 This pull request has now been integrated. Changeset: 51956054 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/51956054485fce5cb42629c9696a3131cb098178 Stats: 19 lines in 4 files changed: 10 ins; 0 del; 9 mod 1801: Exclude some GraphQL calls from RestRequestCache rate limiter Reviewed-by: ihse ------------- PR: https://git.openjdk.org/skara/pull/1461 From erikj at openjdk.org Tue Jan 24 20:50:41 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 24 Jan 2023 20:50:41 GMT Subject: RFR: 1803: GitLabRepository.canPush only checks direct members Message-ID: The method `canPush` on GitLabRepository uses the wrong endpoint for the query. It only checks for direct members and not inherited members (https://docs.gitlab.com/ee/api/members.html). ------------- Commit messages: - SKARA-1803 Changes: https://git.openjdk.org/skara/pull/1462/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1462&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1803 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1462.diff Fetch: git fetch https://git.openjdk.org/skara pull/1462/head:pull/1462 PR: https://git.openjdk.org/skara/pull/1462 From zsong at openjdk.org Tue Jan 24 23:53:34 2023 From: zsong at openjdk.org (Zhao Song) Date: Tue, 24 Jan 2023 23:53:34 GMT Subject: RFR: 1803: GitLabRepository.canPush only checks direct members In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 20:46:57 GMT, Erik Joelsson wrote: > The method `canPush` on GitLabRepository uses the wrong endpoint for the query. It only checks for direct members and not inherited members (https://docs.gitlab.com/ee/api/members.html). LGTM ------------- Marked as reviewed by zsong (Committer). PR: https://git.openjdk.org/skara/pull/1462 From ihse at openjdk.org Wed Jan 25 17:40:12 2023 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 25 Jan 2023 17:40:12 GMT Subject: RFR: 1803: GitLabRepository.canPush only checks direct members In-Reply-To: References: Message-ID: On Tue, 24 Jan 2023 20:46:57 GMT, Erik Joelsson wrote: > The method `canPush` on GitLabRepository uses the wrong endpoint for the query. It only checks for direct members and not inherited members (https://docs.gitlab.com/ee/api/members.html). Marked as reviewed by ihse (Reviewer). ------------- PR: https://git.openjdk.org/skara/pull/1462 From erikj at openjdk.org Wed Jan 25 18:23:38 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 25 Jan 2023 18:23:38 GMT Subject: Integrated: 1803: GitLabRepository.canPush only checks direct members In-Reply-To: References: Message-ID: <7Odd0Ts054Ig0kKrvmE9bG975R8mNwmYMHULS1D9_VM=.f29392e4-143f-4abd-b1aa-bbd9fe2a06fb@github.com> On Tue, 24 Jan 2023 20:46:57 GMT, Erik Joelsson wrote: > The method `canPush` on GitLabRepository uses the wrong endpoint for the query. It only checks for direct members and not inherited members (https://docs.gitlab.com/ee/api/members.html). This pull request has now been integrated. Changeset: 9a2a9f74 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/9a2a9f7415f937b27b84fbf13f7cbd0d28559082 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 1803: GitLabRepository.canPush only checks direct members Reviewed-by: zsong, ihse ------------- PR: https://git.openjdk.org/skara/pull/1462 From zsong at openjdk.org Thu Jan 26 16:45:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 16:45:53 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found Message-ID: A user reported that she have a PR which can't find its corresponding CSR. Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. In this patch, I optimized the CSR progress message and log. ------------- Commit messages: - SKARA-1806 Changes: https://git.openjdk.org/skara/pull/1463/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1806 Stats: 37 lines in 3 files changed: 4 ins; 0 del; 33 mod Patch: https://git.openjdk.org/skara/pull/1463.diff Fetch: git fetch https://git.openjdk.org/skara pull/1463/head:pull/1463 PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 17:04:49 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 17:04:49 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: Message-ID: On Wed, 25 Jan 2023 23:40:42 GMT, Zhao Song wrote: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 77: > 75: private Duration expiresIn; > 76: > 77: private Optional versionOpt; Fields should not be `Optional`. We should also not add fields that are arbitrarily initiated as a side effect of some method. This needs to be initiated in one place and then propagated through parameters. Looking at the calling tree of the various getIssue methods, this looks like a pretty bad mess. Not sure how to untangle this to propagate the version value. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 18:14:54 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 18:14:54 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 17:00:45 GMT, Erik Joelsson wrote: >> A user reported that she have a PR which can't find its corresponding CSR. >> Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. >> >> In this patch, I optimized the CSR progress message and log. > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 77: > >> 75: private Duration expiresIn; >> 76: >> 77: private Optional versionOpt; > > Fields should not be `Optional`. We should also not add fields that are arbitrarily initiated as a side effect of some method. This needs to be initiated in one place and then propagated through parameters. Looking at the calling tree of the various getIssue methods, this looks like a pretty bad mess. Not sure how to untangle this to propagate the version value. I add this field because I don't want to call `BotUtils.getVersion(pr)` twice. If adding a field is a bad idea, I think just call `BotUtils.getVersion(pr)` twice is better than add `JdkVersion` to many method interfaces. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 18:21:23 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 18:21:23 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 18:12:38 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 77: >> >>> 75: private Duration expiresIn; >>> 76: >>> 77: private Optional versionOpt; >> >> Fields should not be `Optional`. We should also not add fields that are arbitrarily initiated as a side effect of some method. This needs to be initiated in one place and then propagated through parameters. Looking at the calling tree of the various getIssue methods, this looks like a pretty bad mess. Not sure how to untangle this to propagate the version value. > > I add this field because I don't want to call `BotUtils.getVersion(pr)` twice. If adding a field is a bad idea, I think just call `BotUtils.getVersion(pr)` twice is better than add `JdkVersion` to many method interfaces. I think the calling tree of `issues()` is in a mess because we have two different type of issues(`org.openjdk.skara.vcs.openjdk` and `org.openjdk.skara.issuetracker.Issue`). Besides, we don't have class fields to store issues, csrIssues, JepIssues. So we need to call `issues()` three times. ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 20:53:02 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 20:53:02 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: Message-ID: <5vqsVBPY4x6yevJNAZuIWUd7Jxd6ZW9I4eHRKXVRbPs=.c1928432-e6b8-4429-92e2-af470262447b@github.com> On Thu, 26 Jan 2023 18:19:15 GMT, Zhao Song wrote: >> I add this field because I don't want to call `BotUtils.getVersion(pr)` twice. If adding a field is a bad idea, I think just call `BotUtils.getVersion(pr)` twice is better than add `JdkVersion` to many method interfaces. > > I think the calling tree of `issues()` is in a mess because we have two different type of issues(`org.openjdk.skara.vcs.openjdk` and `org.openjdk.skara.issuetracker.Issue`). Besides, we don't have class fields to store issues, csrIssues, JepIssues. So we need to call `issues()` three times. Yes, the two different Issue types definitely adds to the confusion, but we also have the `::issues` method that takes two booleans. It has three callers and only one of those sets the parameters true. This should just have been split into different methods. As it is now, they are calling each other in a circle, only saved by the boolean being false in the second call. Untangling this would make it pretty straightforward to provide a JdkVersion argument to the method for getting just CSR issues. I think there is value in only calling `BotUtils.getVersion(pr)` once as it's quite expensive to evaluate. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 21:14:36 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 21:14:36 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: <5vqsVBPY4x6yevJNAZuIWUd7Jxd6ZW9I4eHRKXVRbPs=.c1928432-e6b8-4429-92e2-af470262447b@github.com> References: <5vqsVBPY4x6yevJNAZuIWUd7Jxd6ZW9I4eHRKXVRbPs=.c1928432-e6b8-4429-92e2-af470262447b@github.com> Message-ID: On Thu, 26 Jan 2023 20:50:44 GMT, Erik Joelsson wrote: > Yes, the two different Issue types definitely adds to the confusion, but we also have the `::issues` method that takes two booleans. It has three callers and only one of those sets the parameters true. This should just have been split into different methods. As it is now, they are calling each other in a circle, only saved by the boolean being false in the second call. Untangling this would make it pretty straightforward to provide a JdkVersion argument to the method for getting just CSR issues. > > I think there is value in only calling `BotUtils.getVersion(pr)` once as it's quite expensive to evaluate. Good idea, I will split them into different methods. Thx! ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 21:45:42 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 21:45:42 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: <5vqsVBPY4x6yevJNAZuIWUd7Jxd6ZW9I4eHRKXVRbPs=.c1928432-e6b8-4429-92e2-af470262447b@github.com> Message-ID: On Thu, 26 Jan 2023 21:12:17 GMT, Zhao Song wrote: >> Yes, the two different Issue types definitely adds to the confusion, but we also have the `::issues` method that takes two booleans. It has three callers and only one of those sets the parameters true. This should just have been split into different methods. As it is now, they are calling each other in a circle, only saved by the boolean being false in the second call. Untangling this would make it pretty straightforward to provide a JdkVersion argument to the method for getting just CSR issues. >> >> I think there is value in only calling `BotUtils.getVersion(pr)` once as it's quite expensive to evaluate. > >> Yes, the two different Issue types definitely adds to the confusion, but we also have the `::issues` method that takes two booleans. It has three callers and only one of those sets the parameters true. This should just have been split into different methods. As it is now, they are calling each other in a circle, only saved by the boolean being false in the second call. Untangling this would make it pretty straightforward to provide a JdkVersion argument to the method for getting just CSR issues. >> >> I think there is value in only calling `BotUtils.getVersion(pr)` once as it's quite expensive to evaluate. > > Good idea, I will split them into different methods. Thx! I started looking at this call chain some more. We are already fetching issues multiple times, that's really what's causing this problem in the first place. We should only fetch issues once in a CheckRun. It will take some refactoring, since we need to preserve the IssueTracker Issues for CSR issues, but still worth it I think. So instead of sending the fixVersion around, we should be fetching issues at a higher level and send those around. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 22:03:38 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 22:03:38 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v2] In-Reply-To: References: Message-ID: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: refactor ------------- Changes: - all: https://git.openjdk.org/skara/pull/1463/files - new: https://git.openjdk.org/skara/pull/1463/files/ace7fdc0..aef642f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=00-01 Stats: 37 lines in 1 file changed: 9 ins; 5 del; 23 mod Patch: https://git.openjdk.org/skara/pull/1463.diff Fetch: git fetch https://git.openjdk.org/skara pull/1463/head:pull/1463 PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 22:03:39 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 22:03:39 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v2] In-Reply-To: References: <5vqsVBPY4x6yevJNAZuIWUd7Jxd6ZW9I4eHRKXVRbPs=.c1928432-e6b8-4429-92e2-af470262447b@github.com> Message-ID: On Thu, 26 Jan 2023 21:42:51 GMT, Erik Joelsson wrote: > I started looking at this call chain some more. We are already fetching issues multiple times, that's really what's causing this problem in the first place. We should only fetch issues once in a CheckRun. It will take some refactoring, since we need to preserve the IssueTracker Issues for CSR issues, but still worth it I think. > > So instead of sending the fixVersion around, we should be fetching issues at a higher level and send those around. I think so too. So I already did some refactoring, now we will only fetch issues once and fetch csr issues once too. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 22:40:45 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 22:40:45 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: References: Message-ID: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. Zhao Song has updated the pull request incrementally with three additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - fix a problem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1463/files - new: https://git.openjdk.org/skara/pull/1463/files/aef642f2..bedcd3e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=01-02 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1463.diff Fetch: git fetch https://git.openjdk.org/skara pull/1463/head:pull/1463 PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 22:40:45 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 22:40:45 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v2] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:03:38 GMT, Zhao Song wrote: >> A user reported that she have a PR which can't find its corresponding CSR. >> Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. >> >> In this patch, I optimized the CSR progress message and log. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > refactor This is definitely better. I still feel like the whole class could use some kind of overhaul, but no need to dig further now. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 167: > 165: * Get the csr issue. Note: this `Issue` is not the issue in module `issuetracker`. > 166: */ > 167: private List getCsrIssues(List CsrIssueTrackerIssues) { Suggestion: private List getCsrIssues(List csrIssueTrackerIssues) { bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 169: > 167: private List getCsrIssues(List CsrIssueTrackerIssues) { > 168: > 169: return CsrIssueTrackerIssues.stream() Suggestion: return csrIssueTrackerIssues.stream() ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 22:40:46 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 22:40:46 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:36:51 GMT, Zhao Song wrote: >> A user reported that she have a PR which can't find its corresponding CSR. >> Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. >> >> In this patch, I optimized the CSR progress message and log. > > Zhao Song has updated the pull request incrementally with three additional commits since the last revision: > > - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> > - fix a problem bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1131: > 1129: version = BotUtils.getVersion(pr).orElse(null); > 1130: } catch (Exception e) { > 1131: } I'm not sure ignoring an exception here is a good idea. In what situation did it throw one? ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Thu Jan 26 22:42:46 2023 From: zsong at openjdk.org (Zhao Song) Date: Thu, 26 Jan 2023 22:42:46 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:36:51 GMT, Erik Joelsson wrote: > I'm not sure ignoring an exception here is a good idea. In what situation did it throw one? It's because `BotUtils.getVersion` only works for fixVersion is configured in` .jcheck/conf`. If we use the override jcheck conf, it will throw exception. So it will make some override jcheck conf tests fail. I think we could fix it, but not in this pr. ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Thu Jan 26 23:51:29 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 26 Jan 2023 23:51:29 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:40:27 GMT, Zhao Song wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 1131: >> >>> 1129: version = BotUtils.getVersion(pr).orElse(null); >>> 1130: } catch (Exception e) { >>> 1131: } >> >> I'm not sure ignoring an exception here is a good idea. In what situation did it throw one? > >> I'm not sure ignoring an exception here is a good idea. In what situation did it throw one? > > It's because `BotUtils.getVersion` only works for fixVersion is configured in` .jcheck/conf`. If we use the override jcheck conf, it will throw exception. So it will make some override jcheck conf tests fail. I think we could fix it, but not in this pr. It needs to be solved in some way. Catching `Exception` and ignoring it is not allowed in bot code. That could be triggered by an IOException, or failure in contacting the remote or almost anything else. If that happens, we need to handle the failure correct so that the WorkItem will be retried. BotUtils.getVersion either can't throw RuntimeException when it can't find a .jcheck/conf file, or we need to handle the fallback to the override repo. The latter would be cleaner, but we probably don't really need that support. I think returning Optional.empty() from BotUtils.getVersion() is probably ok if no .jcheck/conf file could be found. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 00:06:58 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 00:06:58 GMT Subject: RFR: 1547: Collect PR specific constants in single shared class Message-ID: There are numerous string literals and constants duplicated and spread around different bots. This includes markers (used in PR body and comments) for various bot functionality as well as label names. In this patch, I cleaned the constants in different bots according to this standard: 1. If a constant is used by multiple bots, it should be placed in bots.common.PullRequestConstants. 2. If a constant is used by different classes within a single bot, it should be placed in a single class within the bot, and other classes should import the constant. 3. If a constant is only used by one class within a single bot, it should be made private to that class. Also, I have renamed the constants that were previously named in an inconsistent manner. ------------- Commit messages: - SKARA-1547 Changes: https://git.openjdk.org/skara/pull/1464/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1464&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1547 Stats: 344 lines in 40 files changed: 65 ins; 26 del; 253 mod Patch: https://git.openjdk.org/skara/pull/1464.diff Fetch: git fetch https://git.openjdk.org/skara pull/1464/head:pull/1464 PR: https://git.openjdk.org/skara/pull/1464 From zsong at openjdk.org Fri Jan 27 00:10:51 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 00:10:51 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: References: Message-ID: <7ouO_lqtMQI9X-jJ_TxNS0oiw7xobo1qDdXdJRel8m8=.a83c6199-dbc6-454b-aa2a-3a5e21d2da81@github.com> On Thu, 26 Jan 2023 23:49:15 GMT, Erik Joelsson wrote: > It needs to be solved in some way. Catching `Exception` and ignoring it is not allowed in bot code. That could be triggered by an IOException, or failure in contacting the remote or almost anything else. If that happens, we need to handle the failure correct so that the WorkItem will be retried. > > BotUtils.getVersion either can't throw RuntimeException when it can't find a .jcheck/conf file, or we need to handle the fallback to the override repo. The latter would be cleaner, but we probably don't really need that support. I think returning Optional.empty() from BotUtils.getVersion() is probably ok if no .jcheck/conf file could be found. Got it! I will fix it ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 00:39:46 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 00:39:46 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v3] In-Reply-To: <7ouO_lqtMQI9X-jJ_TxNS0oiw7xobo1qDdXdJRel8m8=.a83c6199-dbc6-454b-aa2a-3a5e21d2da81@github.com> References: <7ouO_lqtMQI9X-jJ_TxNS0oiw7xobo1qDdXdJRel8m8=.a83c6199-dbc6-454b-aa2a-3a5e21d2da81@github.com> Message-ID: On Fri, 27 Jan 2023 00:08:38 GMT, Zhao Song wrote: >> It needs to be solved in some way. Catching `Exception` and ignoring it is not allowed in bot code. That could be triggered by an IOException, or failure in contacting the remote or almost anything else. If that happens, we need to handle the failure correct so that the WorkItem will be retried. >> >> BotUtils.getVersion either can't throw RuntimeException when it can't find a .jcheck/conf file, or we need to handle the fallback to the override repo. The latter would be cleaner, but we probably don't really need that support. I think returning Optional.empty() from BotUtils.getVersion() is probably ok if no .jcheck/conf file could be found. > >> It needs to be solved in some way. Catching `Exception` and ignoring it is not allowed in bot code. That could be triggered by an IOException, or failure in contacting the remote or almost anything else. If that happens, we need to handle the failure correct so that the WorkItem will be retried. >> >> BotUtils.getVersion either can't throw RuntimeException when it can't find a .jcheck/conf file, or we need to handle the fallback to the override repo. The latter would be cleaner, but we probably don't really need that support. I think returning Optional.empty() from BotUtils.getVersion() is probably ok if no .jcheck/conf file could be found. > > Got it! I will fix it Now I realized that this jcheck conf issue happens because the place of `JdkVersion version = BotUtils.getVersion(pr).orElse(null);`. In `CheckWorkItem`, we have check for jcheck configuration in **target branch**. So if jcheck conf missing or invalid in **target branch**, the bot will return immediately. However, in `BotUtils#getVersion`, the bot would try to get conf from **source branch** first. Although we also have check for **source branch**, it is after the call of JdkVersion version = BotUtils.getVersion(pr).orElse(null);`. So bad conf in **source branch** would cause getVersion throw exceptions. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 01:00:53 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 01:00:53 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v4] In-Reply-To: References: Message-ID: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix a problem ------------- Changes: - all: https://git.openjdk.org/skara/pull/1463/files - new: https://git.openjdk.org/skara/pull/1463/files/bedcd3e3..ab5990bd Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=02-03 Stats: 35 lines in 3 files changed: 23 ins; 8 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1463.diff Fetch: git fetch https://git.openjdk.org/skara pull/1463/head:pull/1463 PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Fri Jan 27 15:12:45 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Jan 2023 15:12:45 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v4] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 01:00:53 GMT, Zhao Song wrote: >> A user reported that she have a PR which can't find its corresponding CSR. >> Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. >> >> In this patch, I optimized the CSR progress message and log. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > fix a problem bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java line 48: > 46: if(confFile == null){ > 47: return Optional.empty(); > 48: } Suggestion: if (confFile == null) { return Optional.empty(); } ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Fri Jan 27 15:18:17 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Jan 2023 15:18:17 GMT Subject: RFR: 1547: Collect PR specific constants in single shared class In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:59:07 GMT, Zhao Song wrote: > There are numerous string literals and constants duplicated and spread around different bots. This includes markers (used in PR body and comments) for various bot functionality as well as label names. > > In this patch, I cleaned the constants in different bots according to this standard: > > 1. If a constant is used by multiple bots, it should be placed in bots.common.PullRequestConstants. > 2. If a constant is used by different classes within a single bot, it should be placed in a single class within the bot, and other classes should import the constant. > 3. If a constant is only used by one class within a single bot, it should be made private to that class. > > Also, I have renamed the constants that were previously named in an inconsistent manner. Looks great, thanks for fixing this! ------------- Marked as reviewed by erikj (Lead). PR: https://git.openjdk.org/skara/pull/1464 From erikj at openjdk.org Fri Jan 27 15:20:23 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Jan 2023 15:20:23 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v4] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 15:05:58 GMT, Erik Joelsson wrote: >> Zhao Song has updated the pull request incrementally with one additional commit since the last revision: >> >> fix a problem > > bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java line 48: > >> 46: if(confFile == null){ >> 47: return Optional.empty(); >> 48: } > > Suggestion: > > if (confFile == null) { > return Optional.empty(); > } If you fix this formatting, then this is as good as it gets now. I'm not happy with the state of CheckRun, but at least this version should work as we want it without doing excessive extra work. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 17:08:55 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 17:08:55 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v5] In-Reply-To: References: Message-ID: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: Update bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1463/files - new: https://git.openjdk.org/skara/pull/1463/files/ab5990bd..9720527a Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1463&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1463.diff Fetch: git fetch https://git.openjdk.org/skara pull/1463/head:pull/1463 PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 17:11:25 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 17:11:25 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v4] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 15:18:15 GMT, Erik Joelsson wrote: > If you fix this formatting, then this is as good as it gets now. I'm not happy with the state of CheckRun, but at least this version should work as we want it without doing excessive extra work. Agree with you, the `CheckRun` looks bulky and the logic inside is somewhat complex, I think maybe we need to refactor it in the future. ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 17:13:58 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 17:13:58 GMT Subject: RFR: 1547: Collect PR specific constants in single shared class In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 22:59:07 GMT, Zhao Song wrote: > There are numerous string literals and constants duplicated and spread around different bots. This includes markers (used in PR body and comments) for various bot functionality as well as label names. > > In this patch, I cleaned the constants in different bots according to this standard: > > 1. If a constant is used by multiple bots, it should be placed in bots.common.PullRequestConstants. > 2. If a constant is used by different classes within a single bot, it should be placed in a single class within the bot, and other classes should import the constant. > 3. If a constant is only used by one class within a single bot, it should be made private to that class. > > Also, I have renamed the constants that were previously named in an inconsistent manner. Thanks! ------------- PR: https://git.openjdk.org/skara/pull/1464 From zsong at openjdk.org Fri Jan 27 17:13:58 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 17:13:58 GMT Subject: Integrated: 1547: Collect PR specific constants in single shared class In-Reply-To: References: Message-ID: <1ensLw0rZeWBm9yBxusJHoBVcmNehXjLfhcfe3Yd9tw=.cba2e219-1e64-478f-a6f9-13bc8445f602@github.com> On Thu, 26 Jan 2023 22:59:07 GMT, Zhao Song wrote: > There are numerous string literals and constants duplicated and spread around different bots. This includes markers (used in PR body and comments) for various bot functionality as well as label names. > > In this patch, I cleaned the constants in different bots according to this standard: > > 1. If a constant is used by multiple bots, it should be placed in bots.common.PullRequestConstants. > 2. If a constant is used by different classes within a single bot, it should be placed in a single class within the bot, and other classes should import the constant. > 3. If a constant is only used by one class within a single bot, it should be made private to that class. > > Also, I have renamed the constants that were previously named in an inconsistent manner. This pull request has now been integrated. Changeset: e7a8063a Author: Zhao Song URL: https://git.openjdk.org/skara/commit/e7a8063ae1ad73de8834eec0a5f523112279a2e7 Stats: 344 lines in 40 files changed: 65 ins; 26 del; 253 mod 1547: Collect PR specific constants in single shared class Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1464 From zsong at openjdk.org Fri Jan 27 17:43:35 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 17:43:35 GMT Subject: RFR: 1807: Escape HTML in source code hosting provider's web UI as required Message-ID: To avoid format errors caused by '<' and '>' in PR comments, the PR bot should properly escape these characters before posting the comment on GitHub or GitLab. ------------- Commit messages: - SKARA-1807 Changes: https://git.openjdk.org/skara/pull/1465/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1465&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1807 Stats: 28 lines in 6 files changed: 12 ins; 8 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1465.diff Fetch: git fetch https://git.openjdk.org/skara pull/1465/head:pull/1465 PR: https://git.openjdk.org/skara/pull/1465 From erikj at openjdk.org Fri Jan 27 18:26:39 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Jan 2023 18:26:39 GMT Subject: RFR: 1806: Optimize the CSR progress message and log when CSR not found [v5] In-Reply-To: References: Message-ID: On Fri, 27 Jan 2023 17:08:55 GMT, Zhao Song wrote: >> A user reported that she have a PR which can't find its corresponding CSR. >> Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. >> >> In this patch, I optimized the CSR progress message and log. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > Update bots/common/src/main/java/org/openjdk/skara/bots/common/BotUtils.java > > Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1463 From erikj at openjdk.org Fri Jan 27 18:30:13 2023 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 27 Jan 2023 18:30:13 GMT Subject: RFR: 1807: Escape HTML in source code hosting provider's web UI as required In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 23:58:20 GMT, Zhao Song wrote: > To avoid format errors caused by '<' and '>' in PR Body, the PR bot should properly escape the issue title in PR body on GitHub or GitLab. Marked as reviewed by erikj (Lead). ------------- PR: https://git.openjdk.org/skara/pull/1465 From zsong at openjdk.org Fri Jan 27 18:32:58 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 18:32:58 GMT Subject: Integrated: 1806: Optimize the CSR progress message and log when CSR not found In-Reply-To: References: Message-ID: <5Sei1BW3dLLDHseN-5_ElwTR0MA1d1htJyYL0VRPz38=.f6cbe6b2-8d1e-4cbf-859e-4cf3b4d9bf23@github.com> On Wed, 25 Jan 2023 23:40:42 GMT, Zhao Song wrote: > A user reported that she have a PR which can't find its corresponding CSR. > Erik found that the issue was caused by the user not updating their branch in a long time, and the fixVersion in the .jcheck/conf file was still set at 20. However, the fixVersion of the CSR was 21, make the bot unable to locate the corresponding CSR. > > In this patch, I optimized the CSR progress message and log. This pull request has now been integrated. Changeset: e57d4167 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/e57d4167697c2390dc1fdcd1eebc2b8477def0b9 Stats: 89 lines in 5 files changed: 30 ins; 3 del; 56 mod 1806: Optimize the CSR progress message and log when CSR not found Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1463 From zsong at openjdk.org Fri Jan 27 18:35:30 2023 From: zsong at openjdk.org (Zhao Song) Date: Fri, 27 Jan 2023 18:35:30 GMT Subject: Integrated: 1807: Escape HTML in source code hosting provider's web UI as required In-Reply-To: References: Message-ID: On Thu, 26 Jan 2023 23:58:20 GMT, Zhao Song wrote: > To avoid format errors caused by '<' and '>' in PR Body, the PR bot should properly escape the issue title in PR body on GitHub or GitLab. This pull request has now been integrated. Changeset: 1838b76d Author: Zhao Song URL: https://git.openjdk.org/skara/commit/1838b76d4f3223c4e187b3b51f91716d1a9fc1e9 Stats: 28 lines in 6 files changed: 12 ins; 8 del; 8 mod 1807: Escape HTML in source code hosting provider's web UI as required Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1465