From ehelin at openjdk.org Wed Apr 3 09:08:53 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 09:08:53 GMT Subject: RFR: 2218: Automate execution of integration tests Message-ID: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Hi all, please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. Thanks, Erik ### Testing - [x] Verified that tests are *not* run when properties are missing - [x] Verified that tests *are* run when properties are present - [x] Verified that tests are *not* run when no `test.properties` file is present - [x] Verified that all JIRA integration tests still pass ------------- Commit messages: - skara-2218 Changes: https://git.openjdk.org/skara/pull/1627/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1627&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2218 Stats: 2280 lines in 12 files changed: 1230 ins; 1049 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1627.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1627/head:pull/1627 PR: https://git.openjdk.org/skara/pull/1627 From erikj at openjdk.org Wed Apr 3 13:49:17 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 Apr 2024 13:49:17 GMT Subject: RFR: 2218: Automate execution of integration tests In-Reply-To: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: On Wed, 3 Apr 2024 09:04:28 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). > > I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). > > I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. > > I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). > > Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. > > Thanks, > Erik > > ### Testing > - [x] Verified that tests are *not* run when properties are missing > - [x] Verified that tests *are* run when properties are present > - [x] Verified that tests are *not* run when no `test.properties` file is present > - [x] Verified that all JIRA integration tests still pass Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1627#pullrequestreview-1976885140 From ehelin at openjdk.org Wed Apr 3 14:11:29 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 14:11:29 GMT Subject: RFR: 2218: Automate execution of integration tests In-Reply-To: References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: On Wed, 3 Apr 2024 13:47:08 GMT, Erik Joelsson wrote: >> Hi all, >> >> please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). >> >> I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). >> >> I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. >> >> I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). >> >> Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. >> >> Thanks, >> Erik >> >> ### Testing >> - [x] Verified that tests are *not* run when properties are missing >> - [x] Verified that tests *are* run when properties are present >> - [x] Verified that tests are *not* run when no `test.properties` file is present >> - [x] Verified that all JIRA integration tests still pass > > Marked as reviewed by erikj (Lead). Thanks for reviewing @erikj79 ! @zhaosongzs could you also take a look? ------------- PR Comment: https://git.openjdk.org/skara/pull/1627#issuecomment-2034727312 From zsong at openjdk.org Wed Apr 3 15:57:29 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Apr 2024 15:57:29 GMT Subject: RFR: 2218: Automate execution of integration tests In-Reply-To: References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: <4evFCHtMfDy-Q_U_wRxHSS4o5_Doh42Cmpu6tx_z3Wg=.833b4b8d-44f1-44d6-8277-d34690d78d90@github.com> On Wed, 3 Apr 2024 13:47:08 GMT, Erik Joelsson wrote: >> Hi all, >> >> please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). >> >> I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). >> >> I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. >> >> I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). >> >> Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. >> >> Thanks, >> Erik >> >> ### Testing >> - [x] Verified that tests are *not* run when properties are missing >> - [x] Verified that tests *are* run when properties are present >> - [x] Verified that tests are *not* run when no `test.properties` file is present >> - [x] Verified that all JIRA integration tests still pass > > Marked as reviewed by erikj (Lead). > Thanks for reviewing @erikj79 ! @zhaosongzs could you also take a look? Sure ------------- PR Comment: https://git.openjdk.org/skara/pull/1627#issuecomment-2034993593 From zsong at openjdk.org Wed Apr 3 17:46:08 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Apr 2024 17:46:08 GMT Subject: RFR: 2218: Automate execution of integration tests In-Reply-To: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: On Wed, 3 Apr 2024 09:04:28 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). > > I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). > > I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. > > I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). > > Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. > > Thanks, > Erik > > ### Testing > - [x] Verified that tests are *not* run when properties are missing > - [x] Verified that tests *are* run when properties are present > - [x] Verified that tests are *not* run when no `test.properties` file is present > - [x] Verified that all JIRA integration tests still pass Looks pretty good and I really like it. Previously, running these tests was inconvenient. Now, this patch has made testing much simpler! Thanks for implementing it! forge/src/test/java/org/openjdk/skara/forge/github/GitHubIntegrationTests.java line 26: > 24: > 25: import java.time.Duration; > 26: import java.util.Properties; No longer need "import java.util.Properties" forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabIntegrationTests.java line 28: > 26: import java.time.ZonedDateTime; > 27: import java.util.Arrays; > 28: import java.util.Properties; No longer need "import java.util.Properties" forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabIntegrationTests.java line 331: > 329: @Test > 330: @EnabledIfTestProperties({"gitlab.user", "gitlab.pat", "gitlab.uri", "gitlab.group", > 331: "gitlab.user"}) "gitlab.user" is duplicated ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1627#pullrequestreview-1977505130 PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550169168 PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550168540 PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550161119 From ehelin at openjdk.org Wed Apr 3 18:23:45 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 18:23:45 GMT Subject: RFR: 2218: Automate execution of integration tests [v2] In-Reply-To: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: > Hi all, > > please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). > > I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). > > I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. > > I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). > > Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. > > Thanks, > Erik > > ### Testing > - [x] Verified that tests are *not* run when properties are missing > - [x] Verified that tests *are* run when properties are present > - [x] Verified that tests are *not* run when no `test.properties` file is present > - [x] Verified that all JIRA integration tests still pass Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: Review feedback from Zhao ------------- Changes: - all: https://git.openjdk.org/skara/pull/1627/files - new: https://git.openjdk.org/skara/pull/1627/files/5895bb73..1530d5b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1627&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1627&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1627.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1627/head:pull/1627 PR: https://git.openjdk.org/skara/pull/1627 From ehelin at openjdk.org Wed Apr 3 18:52:39 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 18:52:39 GMT Subject: RFR: 2218: Automate execution of integration tests [v2] In-Reply-To: References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: <7RzPau6xm80thKhtv6mtiStKTvqshSocUGI2SlZD3AM=.d142ce16-5c58-4a2b-b3b1-5e181baf52f1@github.com> On Wed, 3 Apr 2024 13:47:08 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback from Zhao > > Marked as reviewed by erikj (Lead). Thanks for reviewing @erikj79 and @zhaosongzs! ------------- PR Comment: https://git.openjdk.org/skara/pull/1627#issuecomment-2035350431 From ehelin at openjdk.org Wed Apr 3 18:52:39 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 18:52:39 GMT Subject: RFR: 2218: Automate execution of integration tests [v2] In-Reply-To: References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: <0VT2ID24D_MlHN2GkUiTGpzTyQUF5udBBjFVjElnSNs=.c7324075-3cdd-477a-8a26-968af636202d@github.com> On Wed, 3 Apr 2024 17:25:17 GMT, Zhao Song wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback from Zhao > > forge/src/test/java/org/openjdk/skara/forge/github/GitHubIntegrationTests.java line 26: > >> 24: >> 25: import java.time.Duration; >> 26: import java.util.Properties; > > No longer need "import java.util.Properties" Thanks, fixed in latest! > forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabIntegrationTests.java line 28: > >> 26: import java.time.ZonedDateTime; >> 27: import java.util.Arrays; >> 28: import java.util.Properties; > > No longer need "import java.util.Properties" Thanks, fixed in latest! > forge/src/test/java/org/openjdk/skara/forge/gitlab/GitLabIntegrationTests.java line 331: > >> 329: @Test >> 330: @EnabledIfTestProperties({"gitlab.user", "gitlab.pat", "gitlab.uri", "gitlab.group", >> 331: "gitlab.user"}) > > "gitlab.user" is duplicated Thanks, fixed in latest commit. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550288211 PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550287944 PR Review Comment: https://git.openjdk.org/skara/pull/1627#discussion_r1550287786 From ehelin at openjdk.org Wed Apr 3 18:52:40 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 18:52:40 GMT Subject: Integrated: 2218: Automate execution of integration tests In-Reply-To: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> References: <0tPD1m3jGxQy6tOBzgtFh-_hgZs5vAYqvMpcWmWuW8I=.d2e67462-9496-4c03-b391-f5584b36808e@github.com> Message-ID: On Wed, 3 Apr 2024 09:04:28 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that automates the execution of integration tests _if_ the required properties for the integration test are configured. Prior to this patch one would have to comment out the `@Disabled` notation and then make sure that all properties for all test methods where configured. It was also hard to see all properties required for a given test function to run. With this patch all properties are declared in an annotation and test functions whose properties are configured will be run automatically (no need to comment out any annotation). > > I have also renamed these tests to end with the suffix `IntegrationTests.java`. For unit tests we use the suffix `Tests.java` and for tests that require properties to be configured we should use the suffix `IntegrationTests.javaa` (since that is what those tests are). > > I also choose a different name for the file containing the properties required for a test to run, the file is now named `test.properties` instead of `manual-test-settings.properties`. The new name is quite a bit shorter and the tests are also no longer manual, they are run automatically as long the required properties for a given test are present. > > I also added support for including test properties from another file to allow test properties to be shared among multiple developers. Included files must be specified with an absolute path since it is hard to figure out the current working directory that tests are being run from (it also make the configuration more explicit). > > Lastly I have slightly refactored the integration tests so that they all follow a similar pattern. There quite a bit more work that needs to be done here: test properties use different naming schemes (camel case vs dot), not all test properties are prefix with the test suite name (could result in name clashes) and some of the test code could use some tender, love and care. This can be taken care of the later, this patch is already quite big. > > Thanks, > Erik > > ### Testing > - [x] Verified that tests are *not* run when properties are missing > - [x] Verified that tests *are* run when properties are present > - [x] Verified that tests are *not* run when no `test.properties` file is present > - [x] Verified that all JIRA integration tests still pass This pull request has now been integrated. Changeset: 64aaee86 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/64aaee8693c1ff74bafca06909afdc6fd74a6201 Stats: 2277 lines in 12 files changed: 1227 ins; 1049 del; 1 mod 2218: Automate execution of integration tests Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1627 From ehelin at openjdk.org Wed Apr 3 19:50:06 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 3 Apr 2024 19:50:06 GMT Subject: RFR: 2222: Remove JbsVault Message-ID: Hi all, please review this patch that removes the class `JbsVault`. `JbsVault` is a duplicate of `JiraVault` and was once added because there was no way to create a backport issue outside of the `org.openjdk.skara.issuetracker` module (the interface `IssueProject` does not contain any functionality for creating a backport). So the `JIraVault` was copied to `JbsVault` (which was in the `org.openjdk.skara.bots.notify` module). This patch instead tries to make it explicit that an `IssueTracker` can support "extensions" in the form of custom REST endpoints. Code outside of `org.openjdk.skara.issuetracker` can query an `IssueTracker` to check if it supports a particular endpoint. While the approach is nice (and much better than `JbsVault`) there is still some knowledge left in `JiraHost` about backports: this is because of the field `defaultSecurity`. The `security` property is a JBS extension to JIRA and shouldn't really be in `JiraHost`. I have a draft patch that adds support for custom properties to an issue tracker, but that patch is huge (and not finished) and I would like to get this one integrated first. I added support for a "backport endpoint" to `TestHost` as well so now all the unit tests are using the same code path as the production code (which means we can remove the method `createBackportIssue` from `JbsBackport`). I also added an integration test for `JbsBackport` to ensure that the endpoint works. Thanks, Erik ### Testing - [x] Added an integration test for REST endpoint used - [x] Added unit test support and all unit tests pass ------------- Commit messages: - skara-2222 Changes: https://git.openjdk.org/skara/pull/1628/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1628&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2222 Stats: 458 lines in 10 files changed: 288 ins; 140 del; 30 mod Patch: https://git.openjdk.org/skara/pull/1628.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1628/head:pull/1628 PR: https://git.openjdk.org/skara/pull/1628 From zsong at openjdk.org Wed Apr 3 22:51:19 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 3 Apr 2024 22:51:19 GMT Subject: RFR: 2222: Remove JbsVault In-Reply-To: References: Message-ID: On Wed, 3 Apr 2024 19:47:35 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsVault`. `JbsVault` is a duplicate of `JiraVault` and was once added because there was no way to create a backport issue outside of the `org.openjdk.skara.issuetracker` module (the interface `IssueProject` does not contain any functionality for creating a backport). So the `JIraVault` was copied to `JbsVault` (which was in the `org.openjdk.skara.bots.notify` module). > > This patch instead tries to make it explicit that an `IssueTracker` can support "extensions" in the form of custom REST endpoints. Code outside of `org.openjdk.skara.issuetracker` can query an `IssueTracker` to check if it supports a particular endpoint. While the approach is nice (and much better than `JbsVault`) there is still some knowledge left in `JiraHost` about backports: this is because of the field `defaultSecurity`. The `security` property is a JBS extension to JIRA and shouldn't really be in `JiraHost`. I have a draft patch that adds support for custom properties to an issue tracker, but that patch is huge (and not finished) and I would like to get this one integrated first. > > I added support for a "backport endpoint" to `TestHost` as well so now all the unit tests are using the same code path as the production code (which means we can remove the method `createBackportIssue` from `JbsBackport`). I also added an integration test for `JbsBackport` to ensure that the endpoint works. > > Thanks, > Erik > > ### Testing > - [x] Added an integration test for REST endpoint used > - [x] Added unit test support and all unit tests pass Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1628#pullrequestreview-1978236260 From erikj at openjdk.org Wed Apr 3 23:11:18 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 3 Apr 2024 23:11:18 GMT Subject: RFR: 2222: Remove JbsVault In-Reply-To: References: Message-ID: On Wed, 3 Apr 2024 19:47:35 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsVault`. `JbsVault` is a duplicate of `JiraVault` and was once added because there was no way to create a backport issue outside of the `org.openjdk.skara.issuetracker` module (the interface `IssueProject` does not contain any functionality for creating a backport). So the `JIraVault` was copied to `JbsVault` (which was in the `org.openjdk.skara.bots.notify` module). > > This patch instead tries to make it explicit that an `IssueTracker` can support "extensions" in the form of custom REST endpoints. Code outside of `org.openjdk.skara.issuetracker` can query an `IssueTracker` to check if it supports a particular endpoint. While the approach is nice (and much better than `JbsVault`) there is still some knowledge left in `JiraHost` about backports: this is because of the field `defaultSecurity`. The `security` property is a JBS extension to JIRA and shouldn't really be in `JiraHost`. I have a draft patch that adds support for custom properties to an issue tracker, but that patch is huge (and not finished) and I would like to get this one integrated first. > > I added support for a "backport endpoint" to `TestHost` as well so now all the unit tests are using the same code path as the production code (which means we can remove the method `createBackportIssue` from `JbsBackport`). I also added an integration test for `JbsBackport` to ensure that the endpoint works. > > Thanks, > Erik > > ### Testing > - [x] Added an integration test for REST endpoint used > - [x] Added unit test support and all unit tests pass This is a nice refactorization. Getting rid of the JbsVault is very appreciated. Approving this with a comment about a comment. Please fix that if you agree. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssueTrackerFactory.java line 53: > 51: } else { > 52: if (credential.username().isEmpty() && !credential.password().isEmpty()) { > 53: return createWithPat(uri, credential.password()); The comment on this method needs to be updated as it's now called from non test code. Even if we are only using it for tests in practice, that isn't enforced anywhere, so the current comment is misleading. ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1628#pullrequestreview-1978260747 PR Review Comment: https://git.openjdk.org/skara/pull/1628#discussion_r1550625517 From ehelin at openjdk.org Thu Apr 4 07:42:34 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 4 Apr 2024 07:42:34 GMT Subject: RFR: 2222: Remove JbsVault [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this patch that removes the class `JbsVault`. `JbsVault` is a duplicate of `JiraVault` and was once added because there was no way to create a backport issue outside of the `org.openjdk.skara.issuetracker` module (the interface `IssueProject` does not contain any functionality for creating a backport). So the `JIraVault` was copied to `JbsVault` (which was in the `org.openjdk.skara.bots.notify` module). > > This patch instead tries to make it explicit that an `IssueTracker` can support "extensions" in the form of custom REST endpoints. Code outside of `org.openjdk.skara.issuetracker` can query an `IssueTracker` to check if it supports a particular endpoint. While the approach is nice (and much better than `JbsVault`) there is still some knowledge left in `JiraHost` about backports: this is because of the field `defaultSecurity`. The `security` property is a JBS extension to JIRA and shouldn't really be in `JiraHost`. I have a draft patch that adds support for custom properties to an issue tracker, but that patch is huge (and not finished) and I would like to get this one integrated first. > > I added support for a "backport endpoint" to `TestHost` as well so now all the unit tests are using the same code path as the production code (which means we can remove the method `createBackportIssue` from `JbsBackport`). I also added an integration test for `JbsBackport` to ensure that the endpoint works. > > Thanks, > Erik > > ### Testing > - [x] Added an integration test for REST endpoint used > - [x] Added unit test support and all unit tests pass Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: Update comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1628/files - new: https://git.openjdk.org/skara/pull/1628/files/7cfacece..dac23a32 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1628&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1628&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1628.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1628/head:pull/1628 PR: https://git.openjdk.org/skara/pull/1628 From ehelin at openjdk.org Thu Apr 4 07:42:35 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 4 Apr 2024 07:42:35 GMT Subject: RFR: 2222: Remove JbsVault [v2] In-Reply-To: References: Message-ID: On Wed, 3 Apr 2024 23:05:11 GMT, Erik Joelsson wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment > > issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssueTrackerFactory.java line 53: > >> 51: } else { >> 52: if (credential.username().isEmpty() && !credential.password().isEmpty()) { >> 53: return createWithPat(uri, credential.password()); > > The comment on this method needs to be updated as it's now called from non test code. Even if we are only using it for tests in practice, that isn't enforced anywhere, so the current comment is misleading. I agree, I updated the comment both for the `createWithPat` method and added a comment in the `if`-branch. Fixed in latest. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1628#discussion_r1551090556 From ehelin at openjdk.org Thu Apr 4 07:56:16 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 4 Apr 2024 07:56:16 GMT Subject: RFR: 2222: Remove JbsVault [v2] In-Reply-To: References: Message-ID: <8OS4Xjuz8nL5vrWBRaViI4le_zpJNdtwNYN6l9XfQps=.bec0d7d9-bbb2-4ccf-bbdc-e66e81873ecf@github.com> On Wed, 3 Apr 2024 22:49:06 GMT, Zhao Song wrote: >> Erik Duveblad has updated the pull request incrementally with one additional commit since the last revision: >> >> Update comment > > Looks good! Thanks @zhaosongzs and @erikj79 for quick reviews! ------------- PR Comment: https://git.openjdk.org/skara/pull/1628#issuecomment-2036443752 From ehelin at openjdk.org Thu Apr 4 07:56:17 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 4 Apr 2024 07:56:17 GMT Subject: Integrated: 2222: Remove JbsVault In-Reply-To: References: Message-ID: On Wed, 3 Apr 2024 19:47:35 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsVault`. `JbsVault` is a duplicate of `JiraVault` and was once added because there was no way to create a backport issue outside of the `org.openjdk.skara.issuetracker` module (the interface `IssueProject` does not contain any functionality for creating a backport). So the `JIraVault` was copied to `JbsVault` (which was in the `org.openjdk.skara.bots.notify` module). > > This patch instead tries to make it explicit that an `IssueTracker` can support "extensions" in the form of custom REST endpoints. Code outside of `org.openjdk.skara.issuetracker` can query an `IssueTracker` to check if it supports a particular endpoint. While the approach is nice (and much better than `JbsVault`) there is still some knowledge left in `JiraHost` about backports: this is because of the field `defaultSecurity`. The `security` property is a JBS extension to JIRA and shouldn't really be in `JiraHost`. I have a draft patch that adds support for custom properties to an issue tracker, but that patch is huge (and not finished) and I would like to get this one integrated first. > > I added support for a "backport endpoint" to `TestHost` as well so now all the unit tests are using the same code path as the production code (which means we can remove the method `createBackportIssue` from `JbsBackport`). I also added an integration test for `JbsBackport` to ensure that the endpoint works. > > Thanks, > Erik > > ### Testing > - [x] Added an integration test for REST endpoint used > - [x] Added unit test support and all unit tests pass This pull request has now been integrated. Changeset: 42cae169 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/42cae169dc11af2c38db4faf81480a7756e96c73 Stats: 463 lines in 10 files changed: 291 ins; 140 del; 32 mod 2222: Remove JbsVault Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1628 From zsong at openjdk.org Thu Apr 4 20:43:41 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 Apr 2024 20:43:41 GMT Subject: RFR: 1919: Make it possible to disable the "/clean" command per repository Message-ID: This patch is trying to make it possible to configure the "/clean" command to be disabled on a repository. ------------- Commit messages: - update factory test - SKARA-1919 Changes: https://git.openjdk.org/skara/pull/1629/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1629&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1919 Stats: 101 lines in 6 files changed: 94 ins; 0 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1629.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1629/head:pull/1629 PR: https://git.openjdk.org/skara/pull/1629 From erikj at openjdk.org Thu Apr 4 22:15:17 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 4 Apr 2024 22:15:17 GMT Subject: RFR: 1919: Make it possible to disable the "/clean" command per repository In-Reply-To: References: Message-ID: On Thu, 4 Apr 2024 20:30:33 GMT, Zhao Song wrote: > This patch is trying to make it possible to configure the "/clean" command to be disabled on a repository. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1629#pullrequestreview-1981284260 From zsong at openjdk.org Thu Apr 4 22:53:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 Apr 2024 22:53:07 GMT Subject: Integrated: 1919: Make it possible to disable the "/clean" command per repository In-Reply-To: References: Message-ID: On Thu, 4 Apr 2024 20:30:33 GMT, Zhao Song wrote: > This patch is trying to make it possible to configure the "/clean" command to be disabled on a repository. This pull request has now been integrated. Changeset: 7b71ff00 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/7b71ff00ea74548da97690832bc4feee1d5435dd Stats: 101 lines in 6 files changed: 94 ins; 0 del; 7 mod 1919: Make it possible to disable the "/clean" command per repository Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1629 From zsong at openjdk.org Thu Apr 4 22:53:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 4 Apr 2024 22:53:07 GMT Subject: RFR: 1919: Make it possible to disable the "/clean" command per repository In-Reply-To: References: Message-ID: <6IVoqR9GVaYVGierI1trVTGtOGai-BIceczNM_8VyYU=.9043906d-fd19-4455-9f75-317fc587c907@github.com> On Thu, 4 Apr 2024 20:30:33 GMT, Zhao Song wrote: > This patch is trying to make it possible to configure the "/clean" command to be disabled on a repository. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1629#issuecomment-2038404136 From aph-open at littlepinkcloud.com Tue Apr 9 07:50:55 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 9 Apr 2024 08:50:55 +0100 Subject: Adding a co-author Message-ID: I'm looking at Skara docs, and I can't find what I'm looking for. I know that Skara has the concept of co-ownership, but how do I add a co-author to a PR? Thanks, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Tue Apr 9 08:04:42 2024 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 09 Apr 2024 10:04:42 +0200 Subject: Adding a co-author In-Reply-To: References: Message-ID: <87y19n9d2d.fsf@redhat.com> > I know that Skara has the concept of co-ownership, but how do I add a > co-author to a PR? https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor is what I used. Roland. From aph-open at littlepinkcloud.com Tue Apr 9 12:04:37 2024 From: aph-open at littlepinkcloud.com (Andrew Haley) Date: Tue, 9 Apr 2024 13:04:37 +0100 Subject: Adding a co-author In-Reply-To: <87y19n9d2d.fsf@redhat.com> References: <87y19n9d2d.fsf@redhat.com> Message-ID: <37b8f224-620c-4f92-9e2d-0da44bdb48bf@littlepinkcloud.com> On 4/9/24 09:04, Roland Westrelin wrote: > >> I know that Skara has the concept of co-ownership, but how do I add a >> co-author to a PR? > > https://wiki.openjdk.org/display/SKARA/Pull+Request+Commands#PullRequestCommands-/contributor Oh LOL, thank you! I was looking for "co-author", of course. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ehelin at openjdk.org Tue Apr 9 21:08:13 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Tue, 9 Apr 2024 21:08:13 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" Message-ID: Hi all, please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. There is one detail in the patch that might look weird: issue.get().setProperty("fixVersions", JSON.array().add(targetFixVersion.get().raw())); In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. Thanks, Erik ------------- Commit messages: - whitespace - 2226 Changes: https://git.openjdk.org/skara/pull/1630/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1630&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2226 Stats: 867 lines in 19 files changed: 679 ins; 161 del; 27 mod Patch: https://git.openjdk.org/skara/pull/1630.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1630/head:pull/1630 PR: https://git.openjdk.org/skara/pull/1630 From zsong at openjdk.org Tue Apr 9 23:25:10 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 9 Apr 2024 23:25:10 GMT Subject: RFR: 1553: Update PR titles automatically from JBS Message-ID: As Magnus and Erik proposed, Skara bot should rewrite PR titles to a canonical form(numbers for the bugId, followed by a ':' and then the bug title, e.g. "1: This is an issue"). Especially, Skara bot should rewrite PR title in the form of "JDK-1 This is an issue" or "JDK-1: This is an issue" to the canonical form. Furthermore, sometimes, a user would update the issue title in JBS and forget updating the pr title. With this patch, If the change is minor like changing the case of some characters or adding/removing spaces, Skara bot will update it automatically for the user, otherwise, Skara bot would still add an integration blocker " ?? Title mismatch between PR and JBS.", ------------- Commit messages: - SKARA-1553 Changes: https://git.openjdk.org/skara/pull/1631/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1631&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-1553 Stats: 51 lines in 4 files changed: 41 ins; 3 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1631.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1631/head:pull/1631 PR: https://git.openjdk.org/skara/pull/1631 From erikj at openjdk.org Wed Apr 10 17:49:50 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Apr 2024 17:49:50 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 21:03:32 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). > > For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. > > There is one detail in the patch that might look weird: > > issue.get().setProperty("fixVersions", > JSON.array().add(targetFixVersion.get().raw())); > > In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. > > I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. > > Thanks, > Erik bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 660: > 658: } > 659: > 660: Did you intend double newlines here? bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 669: > 667: var m = ISSUE_ID_PATTERN.matcher(pr.title()); > 668: Optional issue = m.matches() ? issueTrackerIssue(getMatchGroup(m, "id")) : Optional.empty(); > 669: if (issue.isPresent()) { Don't we need to check that the main issue is open? bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 691: > 689: var issueFixVersion = Backports.mainFixVersion(issue.get()); > 690: if (issueFixVersion.isPresent() && > 691: targetFixVersion.get().compareTo(issueFixVersion.get()) > 0) { This check should be made before `willCreateBackport` as it's much cheaper. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 702: > 700: var backport = assignees.isEmpty() ? > 701: Backports.createBackport(issue.get(), issueFixVersion.get().raw()) : > 702: Backports.createBackport(issue.get(), issueFixVersion.get().raw(), assignees.get(0).username()); The order of operations here risks leaving a mess if the bot is interrupted at some point. The fixVersion could be updated in the bug, but no backport created and no comment posted. On a rerun nothing would happen. The backport could be created but no comment be posted. On a rerun, no comment would be posted. Operations like this need to be carefully crafted to guarantee that the end state is eventually reached. The simplest fix would be to create the backport first. Then we would also need to check for a backport with the same fixVersion as the main bug and only create the backport if that doesn't already exist. After that we change the fixVersion of the main bug. That still won't guarantee that we will post the comment. For a complete solution we will need to post an interim comment with the wording "going to" added before performing any operations. We can look for this comment in addition to the other conditions to detect an incomplete existing attempt. Then when we have performed all operations, we finalize the comment by rewriting it. We also need tests that verify that the end state is reached when the bot is presented with a PR in any of these incomplete states. This may seem pedantic, but I'm very sure this will actually happen, more often than one might think. I went through a similar exercise with the /integrate command soon after taking over Skara because it was rather common for the bot to be interrupted mid integration. bots/pr/src/main/java/org/openjdk/skara/bots/pr/OverridingJCheckConfigurationParser.java line 39: > 37: private final List overridingConf; > 38: > 39: OverridingJCheckConfigurationParser(Repository localRepo, Optional overridingRepository, Using Optional as a parameter isn't considered good form. I would rather have a null check in the constructor below. Another option is for the constructors to take a PullRequestBot instance which this class can extract the override config from. All uses of this class fetch all three parameters from the PullRequestBot instance anyway. Or if we really want to go the extra mile, the three override options always go together, and are only ever consumed by this class, so maybe a single carrier class for the config that this class can consume would make more sense? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559528925 PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559833695 PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559838400 PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559825360 PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559522666 From erikj at openjdk.org Wed Apr 10 18:02:55 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Apr 2024 18:02:55 GMT Subject: RFR: 1553: Update PR titles automatically from JBS In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 22:50:38 GMT, Zhao Song wrote: > As Magnus and Erik proposed, Skara bot should rewrite PR titles to a canonical form(numbers for the bugId, followed by a ':' and then the bug title, e.g. "1: This is an issue"). > Especially, Skara bot should rewrite PR title in the form of "JDK-1 This is an issue" or "JDK-1: This is an issue" to the canonical form. > > Furthermore, sometimes, a user would update the issue title in JBS and forget updating the pr title. With this patch, If the change is minor like changing the case of some characters or adding/removing spaces, Skara bot will update it automatically for the user, otherwise, Skara bot would still add an integration blocker " ?? Title mismatch between PR and JBS.", Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1631#pullrequestreview-1992362802 From erikj at openjdk.org Wed Apr 10 18:23:44 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Apr 2024 18:23:44 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 21:03:32 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). > > For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. > > There is one detail in the patch that might look weird: > > issue.get().setProperty("fixVersions", > JSON.array().add(targetFixVersion.get().raw())); > > In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. > > I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. > > Thanks, > Erik Test comment, second comment @edvbld ------------- PR Comment: https://git.openjdk.org/skara/pull/1630#issuecomment-2048188570 From zsong at openjdk.org Wed Apr 10 18:31:10 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 Apr 2024 18:31:10 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 21:03:32 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). > > For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. > > There is one detail in the patch that might look weird: > > issue.get().setProperty("fixVersions", > JSON.array().add(targetFixVersion.get().raw())); > > In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. > > I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. > > Thanks, > Erik bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckRun.java line 112: > 110: workItem.bot.confOverrideRef()); > 111: checkablePullRequest = new CheckablePullRequest(pr, localRepo, ignoreStaleReviews, > 112: jcheckParser, Previously, for the type of parameter `confOverridingRepository` in `CheckablePullRequest`, we didn't use `Optional`, maybe it's better to still use `HostedRepository overridingRepository` as parameter in `OverridingJCheckConfiguration`. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 666: > 664: // > 665: // NOTE: The current implementation only works for the issue in the title, *NOT* for all issues solved by the PR > 666: if (bot.avoidForwardports()) { I am not sure if we should take action with forward port at this early stage. I mean if a user had a typo in the pr title(the issue id is wrong) and this made the pr like a forward port, then Skara bot would set the fixVersion to null for the incorrect issue and create a backport. Even if the user fixes the typo in the pr title, Skara bot will not withdraw the previous action. The user will need to fix it manually. I think maybe it's better to take action at least when the pr is marked as "ready". And if you want, I think we can make it work for all the issues associated with this pr. We can get all the issue ids via `BotUtils.parseAllIssues(prBody)`. I am also wondering why don't we put the whole logic of `avoidForwardports` in `issueNotifier`, it's where the backports will be created. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559857719 PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1559875296 From zsong at openjdk.org Wed Apr 10 18:49:59 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 Apr 2024 18:49:59 GMT Subject: RFR: 1553: Update PR titles automatically from JBS In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 22:50:38 GMT, Zhao Song wrote: > As Magnus and Erik proposed, Skara bot should rewrite PR titles to a canonical form(numbers for the bugId, followed by a ':' and then the bug title, e.g. "1: This is an issue"). > Especially, Skara bot should rewrite PR title in the form of "JDK-1 This is an issue" or "JDK-1: This is an issue" to the canonical form. > > Furthermore, sometimes, a user would update the issue title in JBS and forget updating the pr title. With this patch, If the change is minor like changing the case of some characters or adding/removing spaces, Skara bot will update it automatically for the user, otherwise, Skara bot would still add an integration blocker " ?? Title mismatch between PR and JBS.", Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1631#issuecomment-2048218678 From zsong at openjdk.org Wed Apr 10 18:49:59 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 Apr 2024 18:49:59 GMT Subject: Integrated: 1553: Update PR titles automatically from JBS In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 22:50:38 GMT, Zhao Song wrote: > As Magnus and Erik proposed, Skara bot should rewrite PR titles to a canonical form(numbers for the bugId, followed by a ':' and then the bug title, e.g. "1: This is an issue"). > Especially, Skara bot should rewrite PR title in the form of "JDK-1 This is an issue" or "JDK-1: This is an issue" to the canonical form. > > Furthermore, sometimes, a user would update the issue title in JBS and forget updating the pr title. With this patch, If the change is minor like changing the case of some characters or adding/removing spaces, Skara bot will update it automatically for the user, otherwise, Skara bot would still add an integration blocker " ?? Title mismatch between PR and JBS.", This pull request has now been integrated. Changeset: 7c01feb9 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/7c01feb91b4ae78cd88cc85f158ea5f800daf9a9 Stats: 51 lines in 4 files changed: 41 ins; 3 del; 7 mod 1553: Update PR titles automatically from JBS Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1631 From erikj at openjdk.org Wed Apr 10 21:02:07 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 10 Apr 2024 21:02:07 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Wed, 10 Apr 2024 18:09:08 GMT, Zhao Song wrote: >> Hi all, >> >> please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). >> >> For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. >> >> There is one detail in the patch that might look weird: >> >> issue.get().setProperty("fixVersions", >> JSON.array().add(targetFixVersion.get().raw())); >> >> In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. >> >> I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. >> >> Thanks, >> Erik > > bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 666: > >> 664: // >> 665: // NOTE: The current implementation only works for the issue in the title, *NOT* for all issues solved by the PR >> 666: if (bot.avoidForwardports()) { > > I am not sure if we should take action with forward port at this early stage. I mean if a user had a typo in the pr title(the issue id is wrong) and this made the pr like a forward port, then Skara bot would set the fixVersion to null for the incorrect issue and create a backport. Even if the user fixes the typo in the pr title, Skara bot will not withdraw the previous action. The user will need to fix it manually. > I think maybe it's better to take action at least when the pr is marked as "ready". > >> // NOTE: The current implementation only works for the issue in the title, *NOT* for all issues solved by the PR > > And if you want, I think we can make it work for all the issues associated with this pr. > We can get all the issue ids via `BotUtils.parseAllIssues(prBody)`. > > > I am also wondering why don't we put the whole logic of `avoidForwardports` in `issueNotifier`, it's where the backports will be created. You bring up a good point with user mistakes having the potential to create lots of bad backports without any automatic cleanup from the bot. We could potentially handle that by doing it in the `IssueNotifier::onNewIssue` and `::onRemovedIssue`, but it would be brittle. Their current use, which is to add links in the issue, is easily revertible, but backport creation is definitely messier. The core of the issue is that we are trying to create the backport at PR creation rather than at PR integration. This was a design decision we made a while back, before considering the implementation, as we thought it would be better from a JBS user point of view. The issues would be updated to reflect the correct fixVersion and backports earlier. @edvbld and I had a discussion and we think that it's probably better to instead do any backport creation at PR integration (which I think means in the `issueNotifier`). However, we need to make it clear to the user that this is going to happen, so the PR bot would still need to maintain comment (likely a section in the merge ready comment) describing exactly which fixVersion would be changed and what backports would be created. I think this description could be useful for all PRs, regardless of using this feature or not, so that users know what to expect with regards to fixVersion and backport creation. To achieve that, we probably need to implement some more common logic between the two bots. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1560049366 From zsong at openjdk.org Wed Apr 10 21:52:11 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 10 Apr 2024 21:52:11 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Wed, 10 Apr 2024 20:59:52 GMT, Erik Joelsson wrote: >> bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 666: >> >>> 664: // >>> 665: // NOTE: The current implementation only works for the issue in the title, *NOT* for all issues solved by the PR >>> 666: if (bot.avoidForwardports()) { >> >> I am not sure if we should take action with forward port at this early stage. I mean if a user had a typo in the pr title(the issue id is wrong) and this made the pr like a forward port, then Skara bot would set the fixVersion to null for the incorrect issue and create a backport. Even if the user fixes the typo in the pr title, Skara bot will not withdraw the previous action. The user will need to fix it manually. >> I think maybe it's better to take action at least when the pr is marked as "ready". >> >>> // NOTE: The current implementation only works for the issue in the title, *NOT* for all issues solved by the PR >> >> And if you want, I think we can make it work for all the issues associated with this pr. >> We can get all the issue ids via `BotUtils.parseAllIssues(prBody)`. >> >> >> I am also wondering why don't we put the whole logic of `avoidForwardports` in `issueNotifier`, it's where the backports will be created. > > You bring up a good point with user mistakes having the potential to create lots of bad backports without any automatic cleanup from the bot. We could potentially handle that by doing it in the `IssueNotifier::onNewIssue` and `::onRemovedIssue`, but it would be brittle. Their current use, which is to add links in the issue, is easily revertible, but backport creation is definitely messier. > > The core of the issue is that we are trying to create the backport at PR creation rather than at PR integration. This was a design decision we made a while back, before considering the implementation, as we thought it would be better from a JBS user point of view. The issues would be updated to reflect the correct fixVersion and backports earlier. > > @edvbld and I had a discussion and we think that it's probably better to instead do any backport creation at PR integration (which I think means in the `issueNotifier`). However, we need to make it clear to the user that this is going to happen, so the PR bot would still need to maintain comment (likely a section in the merge ready comment) describing exactly which fixVersion would be changed and what backports would be created. I think this description could be useful for all PRs, regardless of using this feature or not, so that users know what to expect with regards to fixVersion and backport creation. To achieve that, we probably need to implement some more common logic between the two bots. Thanks for the details! I was thinking the users might be confused when they found in forward port cases, backports are created at PR creation while they already got used to see backports created at PR integration when they are using /backport command. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1630#discussion_r1560096825 From ehelin at openjdk.org Thu Apr 11 08:37:01 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 08:37:01 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 21:03:32 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). > > For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. > > There is one detail in the patch that might look weird: > > issue.get().setProperty("fixVersions", > JSON.array().add(targetFixVersion.get().raw())); > > In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. > > I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. > > Thanks, > Erik @zhaosongzs and @erikj79 thanks for great reviews and discussion! I will split this work into two patches, one for [SKARA-2227 - Describe planned modifications to issues](https://bugs.openjdk.org/browse/SKARA-2227) and one for [SKARA-2226 - Make it possible to avoid "forward backports"](https://bugs.openjdk.org/browse/SKARA-2226). The implementation of [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226) will change to avoid the creation of "forward backports" _after_ a PR has been integrated (and yes, those changes will primarily be made to the `IssueNotifier`). As @erikj79 mentioned the concept of describing planned changes to issues is a general useful concept, so we can apply it to all issues (not only those that happen to have a fixVersiont that differs from the target repository's). That work will be done as part of [SKARA-2227](https://bugs.openjdk.org/browse/SKARA-2227). I will close this PR since it no longer represents how we want to solve [SKARA-2226](https://bugs.openjdk.org/browse/SKARA-2226) and will open a new one PR with a solution focused on avoiding "forward backports" after a PR has been integrated. ------------- PR Comment: https://git.openjdk.org/skara/pull/1630#issuecomment-2049197605 From ehelin at openjdk.org Thu Apr 11 08:37:01 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 08:37:01 GMT Subject: Withdrawn: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Tue, 9 Apr 2024 21:03:32 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that makes it possible to configure the PR bot to avoid creating a "forward backport" when integrating a pull request. A "forward backport" gets created when the issue being fixed a PR has a `fixVersion` that is less than the `fixVersion` for the repository (which is specified by `.jcheck/conf`). This patch detects this scenario and instead sets the `fixVersion` for the issue to the repository's `fixVersion` and creates a backport with the `fixVersion` of the original issue. Avoiding "forward backport"s is configurable and will only be enabled for the [jdk](https://github.com/openjdk/jdk) repository (it would be a bug to have this behaviour for update release repositories). > > For the patch itself, there are two larger changes that are almost just moving code: the creation of the new class `OverridingJCheckConfigurationParser` and the addition of `createBackport` to `Backports` (and the removal of `JbsBackports`). `OverridingJCheckConfigurationParser` is useful for parsing a `.jcheck/conf` that can be overridden _without_ a local repository (only with a `HostedRepository`). `Backports.createBackport` is almost a clean refactoring of `JbsBackport` - no functionality has been changed. > > There is one detail in the patch that might look weird: > > issue.get().setProperty("fixVersions", > JSON.array().add(targetFixVersion.get().raw())); > > In `IssueNotifier` the code is setting `fixVersions` to a value of a single JSON string. However, this value gets transformed by `JiraProject.encodeProperty`. The problem with not using an array (which the property value should be) is that tests gets confused (since `TestIssueTrackerIssue.setProperty` is *not* transforming its input). I therefore opted to use an array in the production code to make it easier to test. > > I also added a bunch of new unit tests as well as slightly updated the integration tests for backports. > > Thanks, > Erik This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/skara/pull/1630 From ehelin at openjdk.org Thu Apr 11 09:20:51 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 09:20:51 GMT Subject: RFR: 2228: Remove JbsBackports Message-ID: Hi all, please review this patch that removes the class `JbsBackports`. The class `JbsBackports` was created because the `Backports` class in the `org.openjdk.skara.jbs` module did not have a way to create a backport via an `IssueTracker` instance. Thanks to 42cae169d it is now possible to create a backport using only an `IssueTracker` instance, so the creation of backports can now be moved to the `Backports` class where it belongs. I also moved the integration test `JbsBackportIntegrationTests` to `BackportsIntegrationTests` and changed the properties to start with `jbs.*` instead of `jira.*` (because this about testing a JBS instance, not a general JIRA instance). I have run the the integration tests and they are passing. Thanks, Erik ------------- Commit messages: - 2228 Changes: https://git.openjdk.org/skara/pull/1632/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1632&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2228 Stats: 284 lines in 7 files changed: 132 ins; 149 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1632.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1632/head:pull/1632 PR: https://git.openjdk.org/skara/pull/1632 From ehelin at openjdk.org Thu Apr 11 09:28:44 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 09:28:44 GMT Subject: RFR: 2229: TestHost propagates too many properties to backports Message-ID: Hi all. please review this small patch that fixes an issue with how `TestHost` creates "backports". The problem is that the current implementation propagates too many properties from the primary issue to the backport (including for example `"issuetype"` which causes the backport to become a bug/enhancement ? ). This patch also set `fixVersions` properly for the created "backport" - the `fixVersions` property is of type `Array`, not `String`. Thanks, Erik ------------- Commit messages: - 2229 Changes: https://git.openjdk.org/skara/pull/1633/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1633&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2229 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1633.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1633/head:pull/1633 PR: https://git.openjdk.org/skara/pull/1633 From ehelin at openjdk.org Thu Apr 11 09:47:05 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 09:47:05 GMT Subject: RFR: 2230: IssueNotifier should use array for fixVersions Message-ID: Hi all, please review this small patch that makes `IssueNotifier` use an array when setting the `fixVersions` property of an issue. There is currently code in `JiraProject.encodeProperty` that enables production code to use a plain string fox `fixVersions`, but such code will then break when using a `TestIssueTrackerIssue` (that does not feature any special encoding of the fixVersion). To allow the production code to work with both unit tests and production JIRA instances the production code should use an array and not a string when setting `fixVersions`. >From a production code point of view this change will not cause any change in behaviour as `JiraProject.encodeProperty` calls `stream()` on its argument, which for `JSONString` is a stream of the string itself and for a `JSONArray` with one item is a stream of the single item (so the resulting streams are identical). The reason the tests are working today is because no test code is directly reading the `fixVersions` property, all test code (and production code) immediately calls `.stream` on the `JSONValue` for the `"fixVersions"` key (which as described results in identical streams for a `JSONString` and `JSONArray` instance with exactly one value). All test code that is setting the `fixVersions` property are correctly using a `JSONArray` as the value. Thanks, Erik ------------- Commit messages: - 2230 Changes: https://git.openjdk.org/skara/pull/1634/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1634&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2230 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1634.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1634/head:pull/1634 PR: https://git.openjdk.org/skara/pull/1634 From erikj at openjdk.org Thu Apr 11 13:12:29 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 Apr 2024 13:12:29 GMT Subject: RFR: 2228: Remove JbsBackports In-Reply-To: References: Message-ID: <3pX5_bdT1bEH4jf3Rc_U1OD611xFm7auesVXnotQocQ=.635d05fc-2644-4e0b-9059-3edf809fded2@github.com> On Thu, 11 Apr 2024 09:17:08 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsBackports`. The class `JbsBackports` was created because the `Backports` class in the `org.openjdk.skara.jbs` module did not have a way to create a backport via an `IssueTracker` instance. Thanks to 42cae169d it is now possible to create a backport using only an `IssueTracker` instance, so the creation of backports can now be moved to the `Backports` class where it belongs. > > I also moved the integration test `JbsBackportIntegrationTests` to `BackportsIntegrationTests` and changed the properties to start with `jbs.*` instead of `jira.*` (because this about testing a JBS instance, not a general JIRA instance). I have run the the integration tests and they are passing. > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1632#pullrequestreview-1994150162 From erikj at openjdk.org Thu Apr 11 13:13:18 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 Apr 2024 13:13:18 GMT Subject: RFR: 2229: TestHost propagates too many properties to backports In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 09:24:54 GMT, Erik Duveblad wrote: > Hi all. > > please review this small patch that fixes an issue with how `TestHost` creates "backports". The problem is that the current implementation propagates too many properties from the primary issue to the backport (including for example `"issuetype"` which causes the backport to become a bug/enhancement ? ). > > This patch also set `fixVersions` properly for the created "backport" - the `fixVersions` property is of type `Array`, not `String`. > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1633#pullrequestreview-1994151966 From erikj at openjdk.org Thu Apr 11 13:13:59 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 11 Apr 2024 13:13:59 GMT Subject: RFR: 2230: IssueNotifier should use array for fixVersions In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 09:44:01 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `IssueNotifier` use an array when setting the `fixVersions` property of an issue. There is currently code in `JiraProject.encodeProperty` that enables production code to use a plain string fox `fixVersions`, but such code will then break when using a `TestIssueTrackerIssue` (that does not feature any special encoding of the fixVersion). To allow the production code to work with both unit tests and production JIRA instances the production code should use an array and not a string when setting `fixVersions`. > > From a production code point of view this change will not cause any change in behaviour as `JiraProject.encodeProperty` calls `stream()` on its argument, which for `JSONString` is a stream of the string itself and for a `JSONArray` with one item is a stream of the single item (so the resulting streams are identical). The reason the tests are working today is because no test code is directly reading the `fixVersions` property, all test code (and production code) immediately calls `.stream` on the `JSONValue` for the `"fixVersions"` key (which as described results in identical streams for a `JSONString` and `JSONArray` instance with exactly one value). All test code that is setting the `fixVersions` property are correctly using a `JSONArray` as the value. > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1634#pullrequestreview-1994153382 From zsong at openjdk.org Thu Apr 11 16:55:13 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Apr 2024 16:55:13 GMT Subject: RFR: 2228: Remove JbsBackports In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 09:17:08 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsBackports`. The class `JbsBackports` was created because the `Backports` class in the `org.openjdk.skara.jbs` module did not have a way to create a backport via an `IssueTracker` instance. Thanks to 42cae169d it is now possible to create a backport using only an `IssueTracker` instance, so the creation of backports can now be moved to the `Backports` class where it belongs. > > I also moved the integration test `JbsBackportIntegrationTests` to `BackportsIntegrationTests` and changed the properties to start with `jbs.*` instead of `jira.*` (because this about testing a JBS instance, not a general JIRA instance). I have run the the integration tests and they are passing. > > Thanks, > Erik Looks good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1632#pullrequestreview-1994713213 From zsong at openjdk.org Thu Apr 11 17:08:03 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Apr 2024 17:08:03 GMT Subject: RFR: 2229: TestHost propagates too many properties to backports In-Reply-To: References: Message-ID: <8D0uay0ISNXwAtvpPIpjsZSUvUdyrkGeXxc6V9eWNX0=.0775397a-9dab-4abc-8cd0-bf68677b3af3@github.com> On Thu, 11 Apr 2024 09:24:54 GMT, Erik Duveblad wrote: > Hi all. > > please review this small patch that fixes an issue with how `TestHost` creates "backports". The problem is that the current implementation propagates too many properties from the primary issue to the backport (including for example `"issuetype"` which causes the backport to become a bug/enhancement ? ). > > This patch also set `fixVersions` properly for the created "backport" - the `fixVersions` property is of type `Array`, not `String`. > > Thanks, > Erik Marked as reviewed by zsong (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1633#pullrequestreview-1994736229 From zsong at openjdk.org Thu Apr 11 17:26:26 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Apr 2024 17:26:26 GMT Subject: RFR: 2230: IssueNotifier should use array for fixVersions In-Reply-To: References: Message-ID: <8LAOMfSQ2VpwKoGn9HrKmvDpMs8EUlZIl0FuIZPPlZs=.c94d4d1e-b98c-43e7-9fa0-e84c6a88117c@github.com> On Thu, 11 Apr 2024 09:44:01 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `IssueNotifier` use an array when setting the `fixVersions` property of an issue. There is currently code in `JiraProject.encodeProperty` that enables production code to use a plain string fox `fixVersions`, but such code will then break when using a `TestIssueTrackerIssue` (that does not feature any special encoding of the fixVersion). To allow the production code to work with both unit tests and production JIRA instances the production code should use an array and not a string when setting `fixVersions`. > > From a production code point of view this change will not cause any change in behaviour as `JiraProject.encodeProperty` calls `stream()` on its argument, which for `JSONString` is a stream of the string itself and for a `JSONArray` with one item is a stream of the single item (so the resulting streams are identical). The reason the tests are working today is because no test code is directly reading the `fixVersions` property, all test code (and production code) immediately calls `.stream` on the `JSONValue` for the `"fixVersions"` key (which as described results in identical streams for a `JSONString` and `JSONArray` instance with exactly one value). All test code that is setting the `fixVersions` property are correctly using a `JSONArray` as the value. > > Thanks, > Erik Marked as reviewed by zsong (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1634#pullrequestreview-1994767513 From ehelin at openjdk.org Thu Apr 11 18:02:02 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:02 GMT Subject: RFR: 2228: Remove JbsBackports In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 16:53:00 GMT, Zhao Song wrote: >> Hi all, >> >> please review this patch that removes the class `JbsBackports`. The class `JbsBackports` was created because the `Backports` class in the `org.openjdk.skara.jbs` module did not have a way to create a backport via an `IssueTracker` instance. Thanks to 42cae169d it is now possible to create a backport using only an `IssueTracker` instance, so the creation of backports can now be moved to the `Backports` class where it belongs. >> >> I also moved the integration test `JbsBackportIntegrationTests` to `BackportsIntegrationTests` and changed the properties to start with `jbs.*` instead of `jira.*` (because this about testing a JBS instance, not a general JIRA instance). I have run the the integration tests and they are passing. >> >> Thanks, >> Erik > > Looks good! Thanks @zhaosongzs and @erikj79 for reviewing! ------------- PR Comment: https://git.openjdk.org/skara/pull/1632#issuecomment-2050221023 From ehelin at openjdk.org Thu Apr 11 18:02:02 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:02 GMT Subject: Integrated: 2228: Remove JbsBackports In-Reply-To: References: Message-ID: <-ylBMVOlKpbJaHOlCKvtLu_ux9zwihMqO9rZudvttRw=.419230d6-90be-43d4-bc8e-e98f2dc27c89@github.com> On Thu, 11 Apr 2024 09:17:08 GMT, Erik Duveblad wrote: > Hi all, > > please review this patch that removes the class `JbsBackports`. The class `JbsBackports` was created because the `Backports` class in the `org.openjdk.skara.jbs` module did not have a way to create a backport via an `IssueTracker` instance. Thanks to 42cae169d it is now possible to create a backport using only an `IssueTracker` instance, so the creation of backports can now be moved to the `Backports` class where it belongs. > > I also moved the integration test `JbsBackportIntegrationTests` to `BackportsIntegrationTests` and changed the properties to start with `jbs.*` instead of `jira.*` (because this about testing a JBS instance, not a general JIRA instance). I have run the the integration tests and they are passing. > > Thanks, > Erik This pull request has now been integrated. Changeset: efe600c3 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/efe600c3834da9c70caca9e214d6afeae13c674d Stats: 284 lines in 7 files changed: 132 ins; 149 del; 3 mod 2228: Remove JbsBackports Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1632 From ehelin at openjdk.org Thu Apr 11 18:02:17 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:17 GMT Subject: RFR: 2229: TestHost propagates too many properties to backports In-Reply-To: <8D0uay0ISNXwAtvpPIpjsZSUvUdyrkGeXxc6V9eWNX0=.0775397a-9dab-4abc-8cd0-bf68677b3af3@github.com> References: <8D0uay0ISNXwAtvpPIpjsZSUvUdyrkGeXxc6V9eWNX0=.0775397a-9dab-4abc-8cd0-bf68677b3af3@github.com> Message-ID: On Thu, 11 Apr 2024 17:05:49 GMT, Zhao Song wrote: >> Hi all. >> >> please review this small patch that fixes an issue with how `TestHost` creates "backports". The problem is that the current implementation propagates too many properties from the primary issue to the backport (including for example `"issuetype"` which causes the backport to become a bug/enhancement ? ). >> >> This patch also set `fixVersions` properly for the created "backport" - the `fixVersions` property is of type `Array`, not `String`. >> >> Thanks, >> Erik > > Marked as reviewed by zsong (Reviewer). Thanks @zhaosongzs and @erikj79 for reviewing! ------------- PR Comment: https://git.openjdk.org/skara/pull/1633#issuecomment-2050221374 From ehelin at openjdk.org Thu Apr 11 18:02:18 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:18 GMT Subject: Integrated: 2229: TestHost propagates too many properties to backports In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 09:24:54 GMT, Erik Duveblad wrote: > Hi all. > > please review this small patch that fixes an issue with how `TestHost` creates "backports". The problem is that the current implementation propagates too many properties from the primary issue to the backport (including for example `"issuetype"` which causes the backport to become a bug/enhancement ? ). > > This patch also set `fixVersions` properly for the created "backport" - the `fixVersions` property is of type `Array`, not `String`. > > Thanks, > Erik This pull request has now been integrated. Changeset: 4f951262 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/4f9512625d80f13d824895b450dcf0ed7f2c372e Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 2229: TestHost propagates too many properties to backports Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1633 From ehelin at openjdk.org Thu Apr 11 18:02:43 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:43 GMT Subject: RFR: 2230: IssueNotifier should use array for fixVersions In-Reply-To: <8LAOMfSQ2VpwKoGn9HrKmvDpMs8EUlZIl0FuIZPPlZs=.c94d4d1e-b98c-43e7-9fa0-e84c6a88117c@github.com> References: <8LAOMfSQ2VpwKoGn9HrKmvDpMs8EUlZIl0FuIZPPlZs=.c94d4d1e-b98c-43e7-9fa0-e84c6a88117c@github.com> Message-ID: <0MjvDBuCAFScd0r58Zlre20mJUYcL-nJs6CXOkT8p-I=.53573729-7185-4657-9f58-5ed44264664a@github.com> On Thu, 11 Apr 2024 17:24:17 GMT, Zhao Song wrote: >> Hi all, >> >> please review this small patch that makes `IssueNotifier` use an array when setting the `fixVersions` property of an issue. There is currently code in `JiraProject.encodeProperty` that enables production code to use a plain string fox `fixVersions`, but such code will then break when using a `TestIssueTrackerIssue` (that does not feature any special encoding of the fixVersion). To allow the production code to work with both unit tests and production JIRA instances the production code should use an array and not a string when setting `fixVersions`. >> >> From a production code point of view this change will not cause any change in behaviour as `JiraProject.encodeProperty` calls `stream()` on its argument, which for `JSONString` is a stream of the string itself and for a `JSONArray` with one item is a stream of the single item (so the resulting streams are identical). The reason the tests are working today is because no test code is directly reading the `fixVersions` property, all test code (and production code) immediately calls `.stream` on the `JSONValue` for the `"fixVersions"` key (which as described results in identical streams for a `JSONString` and `JSONArray` instance with exactly one value). All test code that is setting the `fixVersions` property are correctly using a `JSONArray` as the value. >> >> Thanks, >> Erik > > Marked as reviewed by zsong (Reviewer). Thanks @zhaosongzs and @erikj79 for reviewing! ------------- PR Comment: https://git.openjdk.org/skara/pull/1634#issuecomment-2050221768 From ehelin at openjdk.org Thu Apr 11 18:02:43 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Thu, 11 Apr 2024 18:02:43 GMT Subject: Integrated: 2230: IssueNotifier should use array for fixVersions In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 09:44:01 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `IssueNotifier` use an array when setting the `fixVersions` property of an issue. There is currently code in `JiraProject.encodeProperty` that enables production code to use a plain string fox `fixVersions`, but such code will then break when using a `TestIssueTrackerIssue` (that does not feature any special encoding of the fixVersion). To allow the production code to work with both unit tests and production JIRA instances the production code should use an array and not a string when setting `fixVersions`. > > From a production code point of view this change will not cause any change in behaviour as `JiraProject.encodeProperty` calls `stream()` on its argument, which for `JSONString` is a stream of the string itself and for a `JSONArray` with one item is a stream of the single item (so the resulting streams are identical). The reason the tests are working today is because no test code is directly reading the `fixVersions` property, all test code (and production code) immediately calls `.stream` on the `JSONValue` for the `"fixVersions"` key (which as described results in identical streams for a `JSONString` and `JSONArray` instance with exactly one value). All test code that is setting the `fixVersions` property are correctly using a `JSONArray` as the value. > > Thanks, > Erik This pull request has now been integrated. Changeset: 863ac20d Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/863ac20d360031af136695738bd24e27d97a1e3c Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2230: IssueNotifier should use array for fixVersions Reviewed-by: erikj, zsong ------------- PR: https://git.openjdk.org/skara/pull/1634 From zsong at openjdk.org Thu Apr 11 20:36:13 2024 From: zsong at openjdk.org (Zhao Song) Date: Thu, 11 Apr 2024 20:36:13 GMT Subject: RFR: 2231: JCheck ran twice unnecessarily Message-ID: Recently, I found sometimes JCheck ran twice unnecessarily in some prs. For example: https://github.com/openjdk/jdk/pull/16005 https://github.com/openjdk/jdk/pull/14586 In the above prs, the authors didn't update .jcheck/conf in the source branch, but skara executed jcheck twice with the jcheck config in the merged commit(merged target branch and source branch). After investigation,l found that in this case, skara bot will make a mistake. Let's say we have two branches: Target branch: initialCommit <-- updateJCheckCommit <-- latestCommit Source Branch: initialCommit <-- editCommit In CheckRun, Skara bot would create a squashed commit(final head is editCommit and parent is latestCommit), and the squashed commit would include diffs in updateJCheckCommit, latestCommit, editCommit. Later, Skara bot would use CheckRun#isFileUpdated to check if .jcheck/conf is updated in the squashed commit and it will return true, therefore run jcheck twice. To resolve this problem, I think we should rewrite isFileUpdated, skara bot should find the common ancestor of target branch and source branch first, then check if the file is updated between mergeBase and the head of source branch. ------------- Commit messages: - update - SKARA-2231 Changes: https://git.openjdk.org/skara/pull/1635/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1635&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2231 Stats: 78 lines in 2 files changed: 61 ins; 10 del; 7 mod Patch: https://git.openjdk.org/skara/pull/1635.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1635/head:pull/1635 PR: https://git.openjdk.org/skara/pull/1635 From erikj at openjdk.org Fri Apr 12 02:45:17 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 12 Apr 2024 02:45:17 GMT Subject: RFR: 2231: JCheck ran twice unnecessarily In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 20:19:42 GMT, Zhao Song wrote: > Recently, I found sometimes JCheck ran twice unnecessarily in some prs. > For example: > https://github.com/openjdk/jdk/pull/16005 > https://github.com/openjdk/jdk/pull/14586 > > In the above prs, the authors didn't update .jcheck/conf in the source branch, but skara executed jcheck twice with the jcheck config in the merged commit(merged target branch and source branch). > > After investigation,l found that in this case, skara bot will make a mistake. > Let's say we have two branches: > Target branch: initialCommit <-- updateJCheckCommit <-- latestCommit > Source Branch: initialCommit <-- editCommit > In CheckRun, Skara bot would create a squashed commit(final head is editCommit and parent is latestCommit), and the squashed commit would include diffs in updateJCheckCommit, latestCommit, editCommit. Later, Skara bot would use CheckRun#isFileUpdated to check if .jcheck/conf is updated in the squashed commit and it will return true, therefore run jcheck twice. > > To resolve this problem, I think we should rewrite isFileUpdated, skara bot should find the common ancestor of target branch and source branch first, then check if the file is updated between mergeBase and the head of source branch. I think this makes sense. Good find. ------------- Marked as reviewed by erikj (Lead). PR Review: https://git.openjdk.org/skara/pull/1635#pullrequestreview-1995775112 From ehelin at openjdk.org Fri Apr 12 08:47:38 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 12 Apr 2024 08:47:38 GMT Subject: RFR: 2233: TestHost does not set assignees correctly for backports Message-ID: Hi all, please review this small patch that makes `TestHost` set assignees correctly for any backport it creates. For now have I opted to just throw if the `HostUser` isn't found. In the future we could instead invoke the `RestRequest.ErrorTransform` if we ever have a need to test what happens when the value for the `assignee` property in the body to the backports endpoint contains an unknown username (we currently do not have that need). Thanks, Erik ------------- Commit messages: - skara-2233 Changes: https://git.openjdk.org/skara/pull/1636/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1636&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2233 Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1636.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1636/head:pull/1636 PR: https://git.openjdk.org/skara/pull/1636 From ehelin at openjdk.org Fri Apr 12 08:56:38 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Fri, 12 Apr 2024 08:56:38 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" Message-ID: Hi all, please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. Thanks, Erik ------------- Depends on: https://git.openjdk.org/skara/pull/1636 Commit messages: - skara-2226 Changes: https://git.openjdk.org/skara/pull/1637/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1637&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2226 Stats: 284 lines in 4 files changed: 280 ins; 0 del; 4 mod Patch: https://git.openjdk.org/skara/pull/1637.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1637/head:pull/1637 PR: https://git.openjdk.org/skara/pull/1637 From zsong at openjdk.org Fri Apr 12 16:12:49 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 12 Apr 2024 16:12:49 GMT Subject: RFR: 2231: JCheck ran twice unnecessarily In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 20:19:42 GMT, Zhao Song wrote: > Recently, I found sometimes JCheck ran twice unnecessarily in some prs. > For example: > https://github.com/openjdk/jdk/pull/16005 > https://github.com/openjdk/jdk/pull/14586 > > In the above prs, the authors didn't update .jcheck/conf in the source branch, but skara executed jcheck twice with the jcheck config in the merged commit(merged target branch and source branch). > > After investigation,l found that in this case, skara bot will make a mistake. > Let's say we have two branches: > Target branch: initialCommit <-- updateJCheckCommit <-- latestCommit > Source Branch: initialCommit <-- editCommit > In CheckRun, Skara bot would create a squashed commit(final head is editCommit and parent is latestCommit), and the squashed commit would include diffs in updateJCheckCommit, latestCommit, editCommit. Later, Skara bot would use CheckRun#isFileUpdated to check if .jcheck/conf is updated in the squashed commit and it will return true, therefore run jcheck twice. > > To resolve this problem, I think we should rewrite isFileUpdated, skara bot should find the common ancestor of target branch and source branch first, then check if the file is updated between mergeBase and the head of source branch. Thank you for the quick review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1635#issuecomment-2052056464 From zsong at openjdk.org Fri Apr 12 16:12:49 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 12 Apr 2024 16:12:49 GMT Subject: Integrated: 2231: JCheck ran twice unnecessarily In-Reply-To: References: Message-ID: On Thu, 11 Apr 2024 20:19:42 GMT, Zhao Song wrote: > Recently, I found sometimes JCheck ran twice unnecessarily in some prs. > For example: > https://github.com/openjdk/jdk/pull/16005 > https://github.com/openjdk/jdk/pull/14586 > > In the above prs, the authors didn't update .jcheck/conf in the source branch, but skara executed jcheck twice with the jcheck config in the merged commit(merged target branch and source branch). > > After investigation,l found that in this case, skara bot will make a mistake. > Let's say we have two branches: > Target branch: initialCommit <-- updateJCheckCommit <-- latestCommit > Source Branch: initialCommit <-- editCommit > In CheckRun, Skara bot would create a squashed commit(final head is editCommit and parent is latestCommit), and the squashed commit would include diffs in updateJCheckCommit, latestCommit, editCommit. Later, Skara bot would use CheckRun#isFileUpdated to check if .jcheck/conf is updated in the squashed commit and it will return true, therefore run jcheck twice. > > To resolve this problem, I think we should rewrite isFileUpdated, skara bot should find the common ancestor of target branch and source branch first, then check if the file is updated between mergeBase and the head of source branch. This pull request has now been integrated. Changeset: 894690e9 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/894690e9bbb3a6b6473f599fb374a402edc4076c Stats: 78 lines in 2 files changed: 61 ins; 10 del; 7 mod 2231: JCheck ran twice unnecessarily Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1635 From zsong at openjdk.org Fri Apr 12 16:33:00 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 12 Apr 2024 16:33:00 GMT Subject: RFR: 2233: TestHost does not set assignees correctly for backports In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 08:43:51 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `TestHost` set assignees correctly for any backport it creates. For now have I opted to just throw if the `HostUser` isn't found. In the future we could instead invoke the `RestRequest.ErrorTransform` if we ever have a need to test what happens when the value for the `assignee` property in the body to the backports endpoint contains an unknown username (we currently do not have that need). > > Thanks, > Erik Looks good ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1636#pullrequestreview-1997888893 From zsong at openjdk.org Fri Apr 12 18:18:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 12 Apr 2024 18:18:40 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 08:54:03 GMT, Erik Duveblad wrote: > Hi all, > > please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. > > The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. > > I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. > > Thanks, > Erik Overall this patch looks good! I believe the issueNotifier would work well even when the bot gets interrupted. Will approve it after SKARA-2233 gets integrated and all the GitHub actions pass. bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 2330: > 2328: issue.setProperty("priority", JSON.of("1")); > 2329: issue.addLabel("test"); > 2330: issue.addLabel("temporary"); In this case, maybe it's better to set the main issue as RESOLVED bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 2462: > 2460: issue.addLabel("temporary"); > 2461: > 2462: // Create an explicit "forwardport" Should be `Create an explicit "backport"` ------------- PR Review: https://git.openjdk.org/skara/pull/1637#pullrequestreview-1998153887 PR Review Comment: https://git.openjdk.org/skara/pull/1637#discussion_r1562975306 PR Review Comment: https://git.openjdk.org/skara/pull/1637#discussion_r1562978528 From zsong at openjdk.org Tue Apr 16 18:01:54 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 16 Apr 2024 18:01:54 GMT Subject: RFR: 2234: /reviewers N should remove ready status for merge pull requests Message-ID: In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. ------------- Commit messages: - update - SKARA-2234 Changes: https://git.openjdk.org/skara/pull/1639/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1639&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2234 Stats: 77 lines in 2 files changed: 75 ins; 2 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1639.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1639/head:pull/1639 PR: https://git.openjdk.org/skara/pull/1639 From zsong at openjdk.org Wed Apr 17 18:55:32 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 17 Apr 2024 18:55:32 GMT Subject: RFR: 2170: Warn on trailing period in PR titles Message-ID: This patch is trying to add a new jcheck called "issuestitle". This jcheck would check if the issue's title has a trailing period. And we would like to configure "issuestitle" jcheck as warning in the repos since in some cases, trailing periods are valid. When implementing this, I found that although we can configure a jcheck as warning in the jcheck configuration file(.jcheck/conf), we fail to differentiate between jchecks as error and jchecks as warning. When jchecks fail as warnings, they cause the local jcheck to exit with a status code of 1. Also, they will be integration blockers when Skara bots evaluate pull requests. Therefore, in this patch, I also make Skara CLI and Skara bots be able to handle jcheck warnings properly. ------------- Commit messages: - update - add Warnings to pr body - SKARA-2170 Changes: https://git.openjdk.org/skara/pull/1638/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1638&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2170 Stats: 361 lines in 11 files changed: 256 ins; 10 del; 95 mod Patch: https://git.openjdk.org/skara/pull/1638.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1638/head:pull/1638 PR: https://git.openjdk.org/skara/pull/1638 From ihse at openjdk.org Wed Apr 17 18:55:32 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 17 Apr 2024 18:55:32 GMT Subject: RFR: 2170: Warn on trailing period in PR titles In-Reply-To: References: Message-ID: On Mon, 15 Apr 2024 22:45:30 GMT, Zhao Song wrote: > This patch is trying to add a new jcheck called "issuestitle". This jcheck would check if the issue's title has a trailing period. And we would like to configure "issuestitle" jcheck as warning in the repos since in some cases, trailing periods are valid. > > When implementing this, I found that although we can configure a jcheck as warning in the jcheck configuration file(.jcheck/conf), we fail to differentiate between jchecks as error and jchecks as warning. When jchecks fail as warnings, they cause the local jcheck to exit with a status code of 1. Also, they will be integration blockers when Skara bots evaluate pull requests. Therefore, in this patch, I also make Skara CLI and Skara bots be able to handle jcheck warnings properly. I looked at the code to try to answer my own question, but could not find out an easy answer, so I'll say it out loud instead: How do you make it so that this is a warning only, and not a blocking error? ------------- PR Comment: https://git.openjdk.org/skara/pull/1638#issuecomment-2058531054 From zsong at openjdk.org Wed Apr 17 18:55:32 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 17 Apr 2024 18:55:32 GMT Subject: RFR: 2170: Warn on trailing period in PR titles In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024 08:28:37 GMT, Magnus Ihse Bursie wrote: > I looked at the code to try to answer my own question, but could not find out an easy answer, so I'll say it out loud instead: > > How do you make it so that this is a warning only, and not a blocking error? Hi Magnus, I haven't finished this patch... So it's still in the draft state. I will finish it today. ------------- PR Comment: https://git.openjdk.org/skara/pull/1638#issuecomment-2059378654 From erikj at openjdk.org Fri Apr 19 14:17:36 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 Apr 2024 14:17:36 GMT Subject: RFR: 2233: TestHost does not set assignees correctly for backports In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 08:43:51 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `TestHost` set assignees correctly for any backport it creates. For now have I opted to just throw if the `HostUser` isn't found. In the future we could instead invoke the `RestRequest.ErrorTransform` if we ever have a need to test what happens when the value for the `assignee` property in the body to the backports endpoint contains an unknown username (we currently do not have that need). > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1636#pullrequestreview-2011556602 From erikj at openjdk.org Fri Apr 19 14:24:11 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 Apr 2024 14:24:11 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 08:54:03 GMT, Erik Duveblad wrote: > Hi all, > > please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. > > The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. > > I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. > > Thanks, > Erik Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1637#pullrequestreview-2011572403 From erikj at openjdk.org Fri Apr 19 14:25:55 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 Apr 2024 14:25:55 GMT Subject: RFR: 2234: /reviewers N should remove ready status for merge pull requests In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024 17:30:56 GMT, Zhao Song wrote: > In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. > > Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). > > To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. This will work, but there is no way back after you issue the `/reviewers` command, which may be unfortunate. Lets wait for @kevinrushforth to weigh in on if this is what he would expect. ------------- PR Comment: https://git.openjdk.org/skara/pull/1639#issuecomment-2066696237 From zsong at openjdk.org Fri Apr 19 17:50:15 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 Apr 2024 17:50:15 GMT Subject: RFR: 2239: Stop logging "issue: bad whitespace" Message-ID: There is no point to log "issue: bad whitespace" in whitespace jcheck. ------------- Commit messages: - SKARA-2239 Changes: https://git.openjdk.org/skara/pull/1640/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1640&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2239 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1640.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1640/head:pull/1640 PR: https://git.openjdk.org/skara/pull/1640 From erikj at openjdk.org Fri Apr 19 18:14:07 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 19 Apr 2024 18:14:07 GMT Subject: RFR: 2239: Stop logging "issue: bad whitespace" In-Reply-To: References: Message-ID: <_5PvktpH-tg_sEaBWVFNhs6jLOwvSiROT7C8MUgPxgE=.c98b0a32-39af-4a0a-9610-f315e7557e6a@github.com> On Fri, 19 Apr 2024 17:46:25 GMT, Zhao Song wrote: > There is no point to log "issue: bad whitespace" in whitespace jcheck. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1640#pullrequestreview-2012067833 From zsong at openjdk.org Fri Apr 19 18:43:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 Apr 2024 18:43:06 GMT Subject: RFR: 2239: Stop logging "issue: bad whitespace" In-Reply-To: References: Message-ID: On Fri, 19 Apr 2024 17:46:25 GMT, Zhao Song wrote: > There is no point to log "issue: bad whitespace" in whitespace jcheck. Thanks for the quick review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1640#issuecomment-2067104271 From zsong at openjdk.org Fri Apr 19 18:43:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 19 Apr 2024 18:43:06 GMT Subject: Integrated: 2239: Stop logging "issue: bad whitespace" In-Reply-To: References: Message-ID: <9-If1pEK5jVJ6FYzKYvjhPlYgzMK2GPrfzpFgBY5y0U=.ad249ef8-a8d2-4d58-82ce-2e036339f3da@github.com> On Fri, 19 Apr 2024 17:46:25 GMT, Zhao Song wrote: > There is no point to log "issue: bad whitespace" in whitespace jcheck. This pull request has now been integrated. Changeset: c69015f7 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/c69015f7fc0b63d6c121ebbd743ca39e15ab224e Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 2239: Stop logging "issue: bad whitespace" Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1640 From duke at openjdk.org Tue Apr 23 17:24:28 2024 From: duke at openjdk.org (duke) Date: Tue, 23 Apr 2024 17:24:28 GMT Subject: Withdrawn: 2167: Unify search methods in IssueProject In-Reply-To: References: Message-ID: On Tue, 30 Jan 2024 13:47:34 GMT, Erik Duveblad wrote: > Hi all, > > this patch unifies the various ways of searching that exist within `JiraProejct`. I also chose to expose the `search` method in the `IssueProject` since I will make use of it in later patches. This is the first patch of _many_ that will extract the JBS specific parts from `JiraProject` so that `JiraProject` will be about JIRA and JBS specific functionality will be moved elsewhere. This refactoring is needed to allow other parts of the Skara to use JBS functionality with only an `IssueProject` instance (without turning `JiraProject` into effectively `JbsProject`). > > Thanks, > Erik This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/skara/pull/1610 From ehelin at openjdk.org Wed Apr 24 14:37:21 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 24 Apr 2024 14:37:21 GMT Subject: RFR: 2233: TestHost does not set assignees correctly for backports In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 16:30:45 GMT, Zhao Song wrote: >> Hi all, >> >> please review this small patch that makes `TestHost` set assignees correctly for any backport it creates. For now have I opted to just throw if the `HostUser` isn't found. In the future we could instead invoke the `RestRequest.ErrorTransform` if we ever have a need to test what happens when the value for the `assignee` property in the body to the backports endpoint contains an unknown username (we currently do not have that need). >> >> Thanks, >> Erik > > Looks good Thanks @zhaosongzs and @erikj79 for reviewing! ------------- PR Comment: https://git.openjdk.org/skara/pull/1636#issuecomment-2075100495 From ehelin at openjdk.org Wed Apr 24 14:37:21 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 24 Apr 2024 14:37:21 GMT Subject: Integrated: 2233: TestHost does not set assignees correctly for backports In-Reply-To: References: Message-ID: <-VMdWNBp0jw1arH7Zs74FzmAe-iSN0XrGWyL1nLZsu0=.4c8fb7dd-b0bc-4730-bfc8-8bf77428a66b@github.com> On Fri, 12 Apr 2024 08:43:51 GMT, Erik Duveblad wrote: > Hi all, > > please review this small patch that makes `TestHost` set assignees correctly for any backport it creates. For now have I opted to just throw if the `HostUser` isn't found. In the future we could instead invoke the `RestRequest.ErrorTransform` if we ever have a need to test what happens when the value for the `assignee` property in the body to the backports endpoint contains an unknown username (we currently do not have that need). > > Thanks, > Erik This pull request has now been integrated. Changeset: 1dfc1aea Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/1dfc1aea12e7f334af142bbddc1f5e9db61ce38a Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod 2233: TestHost does not set assignees correctly for backports Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1636 From ehelin at openjdk.org Wed Apr 24 14:45:37 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 24 Apr 2024 14:45:37 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: On Fri, 12 Apr 2024 18:08:17 GMT, Zhao Song wrote: >> Hi all, >> >> please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. >> >> The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. >> >> I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. >> >> Thanks, >> Erik > > bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 2330: > >> 2328: issue.setProperty("priority", JSON.of("1")); >> 2329: issue.addLabel("test"); >> 2330: issue.addLabel("temporary"); > > In this case, maybe it's better to set the main issue as RESOLVED Why? I want to check that the main issue remains open and that a backport is created? The `RESOLVED_IN_BUILD` property is set to verify that certain custom properties aren't propagating IIRC. > bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 2462: > >> 2460: issue.addLabel("temporary"); >> 2461: >> 2462: // Create an explicit "forwardport" > > Should be `Create an explicit "backport"` Thanks, will fix ? ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1637#discussion_r1578016169 PR Review Comment: https://git.openjdk.org/skara/pull/1637#discussion_r1578016745 From ehelin at openjdk.org Wed Apr 24 14:54:38 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Wed, 24 Apr 2024 14:54:38 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" [v2] In-Reply-To: References: Message-ID: > Hi all, > > please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. > > The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. > > I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. > > Thanks, > Erik Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into issue-notifier-avoid-forwardport - Fix comment in test - skara-2226 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1637/files - new: https://git.openjdk.org/skara/pull/1637/files/26b3bf4c..ba5ba6ba Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1637&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1637&range=00-01 Stats: 88 lines in 5 files changed: 65 ins; 14 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1637.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1637/head:pull/1637 PR: https://git.openjdk.org/skara/pull/1637 From zsong at openjdk.org Wed Apr 24 19:37:46 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 24 Apr 2024 19:37:46 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" [v2] In-Reply-To: References: Message-ID: On Wed, 24 Apr 2024 14:54:38 GMT, Erik Duveblad wrote: >> Hi all, >> >> please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. >> >> The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. >> >> I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. >> >> Thanks, >> Erik > > Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into issue-notifier-avoid-forwardport > - Fix comment in test > - skara-2226 Marked as reviewed by zsong (Reviewer). ------------- PR Review: https://git.openjdk.org/skara/pull/1637#pullrequestreview-2020767563 From zsong at openjdk.org Wed Apr 24 19:37:46 2024 From: zsong at openjdk.org (Zhao Song) Date: Wed, 24 Apr 2024 19:37:46 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" [v2] In-Reply-To: References: Message-ID: On Wed, 24 Apr 2024 14:43:09 GMT, Erik Duveblad wrote: >> bots/notify/src/test/java/org/openjdk/skara/bots/notify/issue/IssueNotifierTests.java line 2330: >> >>> 2328: issue.setProperty("priority", JSON.of("1")); >>> 2329: issue.addLabel("test"); >>> 2330: issue.addLabel("temporary"); >> >> In this case, maybe it's better to set the main issue as RESOLVED > > Why? I want to check that the main issue remains open and that a backport is created? The `RESOLVED_IN_BUILD` property is set to verify that certain custom properties aren't propagating IIRC. Ah, got it. NVM ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1637#discussion_r1578419275 From johan.vos at gluonhq.com Thu Apr 25 07:25:02 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 25 Apr 2024 09:25:02 +0200 Subject: Bot reusing branch names? Message-ID: Until recently, all PR's from the openjdk-bots that were created to allow solving conflicts when merging commits from openjdk/jdk:HEAD into openjdk/mobile:HEAD went fine. The last PR that was created though [1], seems to be weird and I wonder if there is something wrong with the PR generation. >From the github website, it seems there are 25 files with a conflict, although that does not seem to be true when I compared them manually. The usual process of fixing the merge conflicts and pushing them to the openjdk-bots/mobile:+2 branch did not trigger the next steps in the PR on openjdk/mobile. What surprises me is that the latest branch in the openjdk-bots/mobile repository has the name "2". In the past, those branches had incremental names, and the previous branch was named "14". I expected to see a branch named "15" but the PR was raised from a branch named "2" which is 27772 commits behind the master of openjdk/mobile. - Johan [1] https://github.com/openjdk/mobile/pull/22 [2] https://github.com/openjdk-bot/mobile/tree/14 -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Apr 25 12:34:20 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 25 Apr 2024 05:34:20 -0700 Subject: Bot reusing branch names? In-Reply-To: References: Message-ID: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Hello Johan, (I finally had some time to look at this today) I recently changed the fork repository that the bot should be creating these PRs from. It used to be "openjdk-bot/" but it's now "openjdk-bots/", note the "s". In this PR the actual source repo is the old "openjdk-bot" but the body text has "openjdk-bots" in the instructions. The branch name is calculated based on the number of branches present in the fork, so the number 2 indicates that it was based on the new "openjdk-bots" repo, but still the PR has "openjdk-bot/mobile" as the source. I'm puzzled and don't know how this could have happened. /Erik On 4/25/24 00:25, Johan Vos wrote: > Until recently, all PR's from the openjdk-bots that were created to > allow solving conflicts when merging commits from openjdk/jdk:HEAD > into openjdk/mobile:HEAD went fine. > The last PR that was created though [1], seems to be weird and I > wonder if there is something wrong with the PR generation. > > From the github website, it seems there are 25 files with a conflict, > although that does not seem to be true when I compared them manually. > The usual process of fixing the merge conflicts and pushing them to > the openjdk-bots/mobile:+2 branch did not trigger the next steps in > the PR on openjdk/mobile. > > What surprises me is that the latest branch in the openjdk-bots/mobile > repository has the name "2". In the past, those branches had > incremental names, and the previous branch was named "14". I expected > to see a branch named "15" but the PR was raised from a branch named > "2" which is 27772 commits behind the master of openjdk/mobile. > > - Johan > > [1] https://github.com/openjdk/mobile/pull/22 > [2] https://github.com/openjdk-bot/mobile/tree/14 From erik.joelsson at oracle.com Thu Apr 25 12:40:06 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 25 Apr 2024 05:40:06 -0700 Subject: Bot reusing branch names? In-Reply-To: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Message-ID: On 4/25/24 05:34, erik.joelsson at oracle.com wrote: > Hello Johan, > > (I finally had some time to look at this today) > > I recently changed the fork repository that the bot should be creating > these PRs from. It used to be "openjdk-bot/" but it's now > "openjdk-bots/", note the "s". In this PR the actual source repo > is the old "openjdk-bot" but the body text has "openjdk-bots" in the > instructions. The branch name is calculated based on the number of > branches present in the fork, so the number 2 indicates that it was > based on the new "openjdk-bots" repo, but still the PR has > "openjdk-bot/mobile" as the source. I'm puzzled and don't know how > this could have happened. > I believe this was caused by me changing the bot configuration, but this bot had cached local repositories in its private scratch work area, and those cached repositories had remotes still pointing to the old fork. I have deleted all cached data, and restarted the bot, but this PR is still broken and need to be closed. /Erik > /Erik > > On 4/25/24 00:25, Johan Vos wrote: >> Until recently, all PR's from the openjdk-bots that were created to >> allow solving conflicts when merging commits from openjdk/jdk:HEAD >> into openjdk/mobile:HEAD went fine. >> The last PR that was created though [1], seems to be weird and I >> wonder if there is something wrong with the PR generation. >> >> From the github website, it seems there are 25 files with a conflict, >> although that does not seem to be true when I compared them manually. >> The usual process of fixing the merge conflicts and pushing them to >> the openjdk-bots/mobile:+2 branch did not trigger the next steps in >> the PR on openjdk/mobile. >> >> What surprises me is that the latest branch in the >> openjdk-bots/mobile repository has the name "2". In the past, those >> branches had incremental names, and the previous branch was named >> "14". I expected to see a branch named "15" but the PR was raised >> from a branch named "2" which is 27772 commits behind the master of >> openjdk/mobile. >> >> - Johan >> >> [1] https://github.com/openjdk/mobile/pull/22 >> [2] https://github.com/openjdk-bot/mobile/tree/14 From erik.joelsson at oracle.com Thu Apr 25 13:11:35 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 25 Apr 2024 06:11:35 -0700 Subject: Bot reusing branch names? In-Reply-To: References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Message-ID: Found the issue, filed https://bugs.openjdk.org/browse/SKARA-2242 /Erik On 4/25/24 05:40, erik.joelsson at oracle.com wrote: > On 4/25/24 05:34, erik.joelsson at oracle.com wrote: >> Hello Johan, >> >> (I finally had some time to look at this today) >> >> I recently changed the fork repository that the bot should be >> creating these PRs from. It used to be "openjdk-bot/" but it's >> now "openjdk-bots/", note the "s". In this PR the actual source >> repo is the old "openjdk-bot" but the body text has "openjdk-bots" in >> the instructions. The branch name is calculated based on the number >> of branches present in the fork, so the number 2 indicates that it >> was based on the new "openjdk-bots" repo, but still the PR has >> "openjdk-bot/mobile" as the source. I'm puzzled and don't know how >> this could have happened. >> > I believe this was caused by me changing the bot configuration, but > this bot had cached local repositories in its private scratch work > area, and those cached repositories had remotes still pointing to the > old fork. I have deleted all cached data, and restarted the bot, but > this PR is still broken and need to be closed. > > /Erik > >> /Erik >> >> On 4/25/24 00:25, Johan Vos wrote: >>> Until recently, all PR's from the openjdk-bots that were created to >>> allow solving conflicts when merging commits from openjdk/jdk:HEAD >>> into openjdk/mobile:HEAD went fine. >>> The last PR that was created though [1], seems to be weird and I >>> wonder if there is something wrong with the PR generation. >>> >>> From the github website, it seems there are 25 files with a >>> conflict, although that does not seem to be true when I compared >>> them manually. >>> The usual process of fixing the merge conflicts and pushing them to >>> the openjdk-bots/mobile:+2 branch did not trigger the next steps in >>> the PR on openjdk/mobile. >>> >>> What surprises me is that the latest branch in the >>> openjdk-bots/mobile repository has the name "2". In the past, those >>> branches had incremental names, and the previous branch was named >>> "14". I expected to see a branch named "15" but the PR was raised >>> from a branch named "2" which is 27772 commits behind the master of >>> openjdk/mobile. >>> >>> - Johan >>> >>> [1] https://github.com/openjdk/mobile/pull/22 >>> [2] https://github.com/openjdk-bot/mobile/tree/14 From johan.vos at gluonhq.com Thu Apr 25 17:05:02 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Thu, 25 Apr 2024 19:05:02 +0200 Subject: Bot reusing branch names? In-Reply-To: References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Message-ID: Thanks for the investigation. That makes sense indeed, I didn't spot the openjdk-bot versus openjdk-bots difference. I see that the previous PR (22) has been closed, and a new PR (23) is created, but that is still created from https://github.com/openjdk-bot/mobile/tree/3 (without s) . The instructions mention the repository at openjdk-bots (with s), so I assume I should also close this PR? (I'm not in a hurry so I'll not touch it as to not confuse the bot). Thanks a lot! - Johan On Thu, Apr 25, 2024 at 2:40?PM wrote: > On 4/25/24 05:34, erik.joelsson at oracle.com wrote: > > Hello Johan, > > > > (I finally had some time to look at this today) > > > > I recently changed the fork repository that the bot should be creating > > these PRs from. It used to be "openjdk-bot/" but it's now > > "openjdk-bots/", note the "s". In this PR the actual source repo > > is the old "openjdk-bot" but the body text has "openjdk-bots" in the > > instructions. The branch name is calculated based on the number of > > branches present in the fork, so the number 2 indicates that it was > > based on the new "openjdk-bots" repo, but still the PR has > > "openjdk-bot/mobile" as the source. I'm puzzled and don't know how > > this could have happened. > > > I believe this was caused by me changing the bot configuration, but this > bot had cached local repositories in its private scratch work area, and > those cached repositories had remotes still pointing to the old fork. I > have deleted all cached data, and restarted the bot, but this PR is > still broken and need to be closed. > > /Erik > > > /Erik > > > > On 4/25/24 00:25, Johan Vos wrote: > >> Until recently, all PR's from the openjdk-bots that were created to > >> allow solving conflicts when merging commits from openjdk/jdk:HEAD > >> into openjdk/mobile:HEAD went fine. > >> The last PR that was created though [1], seems to be weird and I > >> wonder if there is something wrong with the PR generation. > >> > >> From the github website, it seems there are 25 files with a conflict, > >> although that does not seem to be true when I compared them manually. > >> The usual process of fixing the merge conflicts and pushing them to > >> the openjdk-bots/mobile:+2 branch did not trigger the next steps in > >> the PR on openjdk/mobile. > >> > >> What surprises me is that the latest branch in the > >> openjdk-bots/mobile repository has the name "2". In the past, those > >> branches had incremental names, and the previous branch was named > >> "14". I expected to see a branch named "15" but the PR was raised > >> from a branch named "2" which is 27772 commits behind the master of > >> openjdk/mobile. > >> > >> - Johan > >> > >> [1] https://github.com/openjdk/mobile/pull/22 > >> [2] https://github.com/openjdk-bot/mobile/tree/14 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Apr 25 18:46:33 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 25 Apr 2024 11:46:33 -0700 Subject: [External] : Re: Bot reusing branch names? In-Reply-To: References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Message-ID: On 4/25/24 10:05, Johan Vos wrote: > Thanks for the investigation. That makes sense indeed, I didn't spot > the openjdk-bot versus openjdk-bots difference. > I see that the previous PR (22) has been closed, and a new PR (23) is > created, but that is still created from > https://github.com/openjdk-bot/mobile/tree/3 > > (without s) . > The instructions mention the repository at openjdk-bots (with s), so I > assume I should also close this PR? (I'm not in a hurry so I'll not > touch it as to not confuse the bot). > I tried closing 22 to see if the bot would generate the next one correctly. When it generated 23 with the same issue still present I dug deeper into the source code and found the actual problem (detailed below). Closing 23 will not help at this point. We need to fix SKARA-2242. /Erik > Thanks a lot! > > - Johan > > On Thu, Apr 25, 2024 at 2:40?PM wrote: > > On 4/25/24 05:34, erik.joelsson at oracle.com wrote: > > Hello Johan, > > > > (I finally had some time to look at this today) > > > > I recently changed the fork repository that the bot should be > creating > > these PRs from. It used to be "openjdk-bot/" but it's now > > "openjdk-bots/", note the "s". In this PR the actual > source repo > > is the old "openjdk-bot" but the body text has "openjdk-bots" in > the > > instructions. The branch name is calculated based on the number of > > branches present in the fork, so the number 2 indicates that it was > > based on the new "openjdk-bots" repo, but still the PR has > > "openjdk-bot/mobile" as the source. I'm puzzled and don't know how > > this could have happened. > > > I believe this was caused by me changing the bot configuration, > but this > bot had cached local repositories in its private scratch work > area, and > those cached repositories had remotes still pointing to the old > fork. I > have deleted all cached data, and restarted the bot, but this PR is > still broken and need to be closed. > > /Erik > > > /Erik > > > > On 4/25/24 00:25, Johan Vos wrote: > >> Until recently, all PR's from the openjdk-bots that were > created to > >> allow solving conflicts when merging commits from openjdk/jdk:HEAD > >> into openjdk/mobile:HEAD went fine. > >> The last PR that was created though [1], seems to be weird and I > >> wonder if there is something wrong with the PR generation. > >> > >> From the github website, it seems there are 25 files with a > conflict, > >> although that does not seem to be true when I compared them > manually. > >> The usual process of fixing the merge conflicts and pushing > them to > >> the openjdk-bots/mobile:+2 branch did not trigger the next > steps in > >> the PR on openjdk/mobile. > >> > >> What surprises me is that the latest branch in the > >> openjdk-bots/mobile repository has the name "2". In the past, > those > >> branches had incremental names, and the previous branch was named > >> "14". I expected to see a branch named "15" but the PR was raised > >> from a branch named "2" which is 27772 commits behind the > master of > >> openjdk/mobile. > >> > >> - Johan > >> > >> [1] https://github.com/openjdk/mobile/pull/22 > > >> [2] https://github.com/openjdk-bot/mobile/tree/14 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Thu Apr 25 21:39:53 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 25 Apr 2024 21:39:53 GMT Subject: RFR: 2242: Creating pull request on github assumes source is personal fork of user Message-ID: This patch fixes the behavior of `GitHubRepository::createPullRequest`. The API pretty clearly indicates that it's meant to create a pull request from the called repository, to the target repository provided as argument. Instead it creates a pull request from the fork owned by the current user to the target repository provided as argument. If the current user has `[bot]` in the name, then the PR will be created using the target repository as source instead. In either case, the called repository is ignored and sometimes just happens to coincide with the fork of the current user. The existing behavior is perplexing but I'm pretty sure I'm right. I'm changing it to explicitly take the "group" value of the called repository as "namespace" instead. This will equal the username when the called repository is a user fork, or the group/org if the called repository is in a GitHub org. In the case where source and target are the same repo, it will also do the right thing. In addition to this error, I noted that the returned PullRequest instance is inconsistent. It is given the HostedRepository of the target, which is correct, but the `request` object of the called repository, which is wrong. This caused all calls to the returned PullRequest object to return 404. In MergeBot, this was worked around by explicitly fetching a new instance from the target repository. By fixing this, that workaround in MergeBot could be removed. I added three manual/integration tests for this that I have manually verified using the playground repository, my personal fork of the same and the fork in the openjdk-bots org. ------------- Commit messages: - SKARA-2242 Changes: https://git.openjdk.org/skara/pull/1641/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1641&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2242 Stats: 84 lines in 3 files changed: 73 ins; 3 del; 8 mod Patch: https://git.openjdk.org/skara/pull/1641.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1641/head:pull/1641 PR: https://git.openjdk.org/skara/pull/1641 From zsong at openjdk.org Fri Apr 26 00:59:39 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 00:59:39 GMT Subject: RFR: 2242: Creating pull request on github assumes source is personal fork of user In-Reply-To: References: Message-ID: On Thu, 25 Apr 2024 21:35:43 GMT, Erik Joelsson wrote: > This patch fixes the behavior of `GitHubRepository::createPullRequest`. The API pretty clearly indicates that it's meant to create a pull request from the called repository, to the target repository provided as argument. Instead it creates a pull request from the fork owned by the current user to the target repository provided as argument. If the current user has `[bot]` in the name, then the PR will be created using the target repository as source instead. In either case, the called repository is ignored and sometimes just happens to coincide with the fork of the current user. > > The existing behavior is perplexing but I'm pretty sure I'm right. I'm changing it to explicitly take the "group" value of the called repository as "namespace" instead. This will equal the username when the called repository is a user fork, or the group/org if the called repository is in a GitHub org. In the case where source and target are the same repo, it will also do the right thing. > > In addition to this error, I noted that the returned PullRequest instance is inconsistent. It is given the HostedRepository of the target, which is correct, but the `request` object of the called repository, which is wrong. This caused all calls to the returned PullRequest object to return 404. In MergeBot, this was worked around by explicitly fetching a new instance from the target repository. By fixing this, that workaround in MergeBot could be removed. > > I added three manual/integration tests for this that I have manually verified using the playground repository, my personal fork of the same and the fork in the openjdk-bots org. Looks pretty good! ------------- Marked as reviewed by zsong (Reviewer). PR Review: https://git.openjdk.org/skara/pull/1641#pullrequestreview-2023853494 From erikj at openjdk.org Fri Apr 26 12:45:59 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 26 Apr 2024 12:45:59 GMT Subject: Integrated: 2242: Creating pull request on github assumes source is personal fork of user In-Reply-To: References: Message-ID: On Thu, 25 Apr 2024 21:35:43 GMT, Erik Joelsson wrote: > This patch fixes the behavior of `GitHubRepository::createPullRequest`. The API pretty clearly indicates that it's meant to create a pull request from the called repository, to the target repository provided as argument. Instead it creates a pull request from the fork owned by the current user to the target repository provided as argument. If the current user has `[bot]` in the name, then the PR will be created using the target repository as source instead. In either case, the called repository is ignored and sometimes just happens to coincide with the fork of the current user. > > The existing behavior is perplexing but I'm pretty sure I'm right. I'm changing it to explicitly take the "group" value of the called repository as "namespace" instead. This will equal the username when the called repository is a user fork, or the group/org if the called repository is in a GitHub org. In the case where source and target are the same repo, it will also do the right thing. > > In addition to this error, I noted that the returned PullRequest instance is inconsistent. It is given the HostedRepository of the target, which is correct, but the `request` object of the called repository, which is wrong. This caused all calls to the returned PullRequest object to return 404. In MergeBot, this was worked around by explicitly fetching a new instance from the target repository. By fixing this, that workaround in MergeBot could be removed. > > I added three manual/integration tests for this that I have manually verified using the playground repository, my personal fork of the same and the fork in the openjdk-bots org. This pull request has now been integrated. Changeset: ac3c81f0 Author: Erik Joelsson URL: https://git.openjdk.org/skara/commit/ac3c81f05fbe2d7ef5b690ca0819a3e1cb96340e Stats: 84 lines in 3 files changed: 73 ins; 3 del; 8 mod 2242: Creating pull request on github assumes source is personal fork of user Reviewed-by: zsong ------------- PR: https://git.openjdk.org/skara/pull/1641 From erik.joelsson at oracle.com Fri Apr 26 13:32:07 2024 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 26 Apr 2024 06:32:07 -0700 Subject: [External] : Re: Bot reusing branch names? In-Reply-To: References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> Message-ID: <294c3dda-164f-48cd-8a62-121783c71e61@oracle.com> On 4/25/24 11:46, erik.joelsson at oracle.com wrote: > > > On 4/25/24 10:05, Johan Vos wrote: >> Thanks for the investigation. That makes sense indeed, I didn't spot >> the openjdk-bot versus openjdk-bots difference. >> I see that the previous PR (22) has been closed, and a new PR (23) is >> created, but that is still created from >> https://github.com/openjdk-bot/mobile/tree/3 >> >> (without s) . >> The instructions mention the repository at openjdk-bots (with s), so >> I assume I should also close this PR? (I'm not in a hurry so I'll not >> touch it as to not confuse the bot). >> > I tried closing 22 to see if the bot would generate the next one > correctly. When it generated 23 with the same issue still present I > dug deeper into the source code and found the actual problem (detailed > below). Closing 23 will not help at this point. We need to fix SKARA-2242. > I have deployed the fix to SKARA-2242, closed pull 23 and the bot has now created pull 24 which looks correct. There are just a few conflicts. /Erik > /Erik > >> Thanks a lot! >> >> - Johan >> >> On Thu, Apr 25, 2024 at 2:40?PM wrote: >> >> On 4/25/24 05:34, erik.joelsson at oracle.com wrote: >> > Hello Johan, >> > >> > (I finally had some time to look at this today) >> > >> > I recently changed the fork repository that the bot should be >> creating >> > these PRs from. It used to be "openjdk-bot/" but it's now >> > "openjdk-bots/", note the "s". In this PR the actual >> source repo >> > is the old "openjdk-bot" but the body text has "openjdk-bots" >> in the >> > instructions. The branch name is calculated based on the number of >> > branches present in the fork, so the number 2 indicates that it >> was >> > based on the new "openjdk-bots" repo, but still the PR has >> > "openjdk-bot/mobile" as the source. I'm puzzled and don't know how >> > this could have happened. >> > >> I believe this was caused by me changing the bot configuration, >> but this >> bot had cached local repositories in its private scratch work >> area, and >> those cached repositories had remotes still pointing to the old >> fork. I >> have deleted all cached data, and restarted the bot, but this PR is >> still broken and need to be closed. >> >> /Erik >> >> > /Erik >> > >> > On 4/25/24 00:25, Johan Vos wrote: >> >> Until recently, all PR's from the openjdk-bots that were >> created to >> >> allow solving conflicts when merging commits from >> openjdk/jdk:HEAD >> >> into openjdk/mobile:HEAD went fine. >> >> The last PR that was created though [1], seems to be weird and I >> >> wonder if there is something wrong with the PR generation. >> >> >> >> From the github website, it seems there are 25 files with a >> conflict, >> >> although that does not seem to be true when I compared them >> manually. >> >> The usual process of fixing the merge conflicts and pushing >> them to >> >> the openjdk-bots/mobile:+2 branch did not trigger the next >> steps in >> >> the PR on openjdk/mobile. >> >> >> >> What surprises me is that the latest branch in the >> >> openjdk-bots/mobile repository has the name "2". In the past, >> those >> >> branches had incremental names, and the previous branch was named >> >> "14". I expected to see a branch named "15" but the PR was raised >> >> from a branch named "2" which is 27772 commits behind the >> master of >> >> openjdk/mobile. >> >> >> >> - Johan >> >> >> >> [1] https://github.com/openjdk/mobile/pull/22 >> >> >> [2] https://github.com/openjdk-bot/mobile/tree/14 >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From zsong at openjdk.org Fri Apr 26 19:27:50 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 19:27:50 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless Message-ID: SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. ------------- Commit messages: - SKARA-2244 Changes: https://git.openjdk.org/skara/pull/1642/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1642&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2244 Stats: 234 lines in 7 files changed: 0 ins; 221 del; 13 mod Patch: https://git.openjdk.org/skara/pull/1642.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1642/head:pull/1642 PR: https://git.openjdk.org/skara/pull/1642 From erikj at openjdk.org Fri Apr 26 19:48:21 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 26 Apr 2024 19:48:21 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless In-Reply-To: References: Message-ID: <2d_6HmRFjjJJx9PNXsy5JZ2qJ5C_neQgoOA3IHjj90E=.9f9239c0-dd95-4cde-bcf2-53cbc9583151@github.com> On Fri, 26 Apr 2024 19:22:45 GMT, Zhao Song wrote: > SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. > > There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 42: > 40: private final RestRequest request; > 41: private final JSONValue json; > 42: private final boolean needSecurity; I think we should keep this boolean and use `jiraProject.jiraHost().visibilityRole().isPresent()` to initialize it. Preventing editing of title and body is still relevant. issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 90: > 88: public void setTitle(String title) { > 89: if (needSecurity) { > 90: log.warning("Issue title does not support setting a security level - ignoring"); Keep this, but change log message to "...setting a visibility role...". ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1642#discussion_r1581466727 PR Review Comment: https://git.openjdk.org/skara/pull/1642#discussion_r1581467817 From zsong at openjdk.org Fri Apr 26 19:54:48 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 19:54:48 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless In-Reply-To: <2d_6HmRFjjJJx9PNXsy5JZ2qJ5C_neQgoOA3IHjj90E=.9f9239c0-dd95-4cde-bcf2-53cbc9583151@github.com> References: <2d_6HmRFjjJJx9PNXsy5JZ2qJ5C_neQgoOA3IHjj90E=.9f9239c0-dd95-4cde-bcf2-53cbc9583151@github.com> Message-ID: On Fri, 26 Apr 2024 19:44:05 GMT, Erik Joelsson wrote: >> SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. >> >> There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. > > issuetracker/src/main/java/org/openjdk/skara/issuetracker/jira/JiraIssue.java line 90: > >> 88: public void setTitle(String title) { >> 89: if (needSecurity) { >> 90: log.warning("Issue title does not support setting a security level - ignoring"); > > Keep this, but change log message to "...setting a visibility role...". Ok, I removed this because I found it's never used. But yes, it's better to keep it ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1642#discussion_r1581474193 From zsong at openjdk.org Fri Apr 26 20:00:55 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 20:00:55 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless [v2] In-Reply-To: References: Message-ID: > SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. > > There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1642/files - new: https://git.openjdk.org/skara/pull/1642/files/af736f5d..7ba90afa Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1642&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1642&range=00-01 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1642.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1642/head:pull/1642 PR: https://git.openjdk.org/skara/pull/1642 From zsong at openjdk.org Fri Apr 26 20:04:58 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 20:04:58 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless [v3] In-Reply-To: References: Message-ID: <0lp05etS6x_iOA_y5sKFAnefwWEKU2E-kpxohKB8fXU=.33c759eb-d05d-48bc-8594-2dd4688be1ce@github.com> > SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. > > There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/skara/pull/1642/files - new: https://git.openjdk.org/skara/pull/1642/files/7ba90afa..ece8d34e Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1642&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1642&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1642.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1642/head:pull/1642 PR: https://git.openjdk.org/skara/pull/1642 From erikj at openjdk.org Fri Apr 26 20:37:20 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 26 Apr 2024 20:37:20 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless [v3] In-Reply-To: <0lp05etS6x_iOA_y5sKFAnefwWEKU2E-kpxohKB8fXU=.33c759eb-d05d-48bc-8594-2dd4688be1ce@github.com> References: <0lp05etS6x_iOA_y5sKFAnefwWEKU2E-kpxohKB8fXU=.33c759eb-d05d-48bc-8594-2dd4688be1ce@github.com> Message-ID: <9VSQc76Vv9YcXpEswcQtJmIoSTD5qTRQInIoANnArgw=.54024812-6e6d-4c95-b047-91df2b4500d0@github.com> On Fri, 26 Apr 2024 20:04:58 GMT, Zhao Song wrote: >> SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. >> >> There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1642#pullrequestreview-2025825800 From zsong at openjdk.org Fri Apr 26 21:02:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 21:02:40 GMT Subject: RFR: 2244: SecurityLevel in JiraHost is useless [v3] In-Reply-To: <0lp05etS6x_iOA_y5sKFAnefwWEKU2E-kpxohKB8fXU=.33c759eb-d05d-48bc-8594-2dd4688be1ce@github.com> References: <0lp05etS6x_iOA_y5sKFAnefwWEKU2E-kpxohKB8fXU=.33c759eb-d05d-48bc-8594-2dd4688be1ce@github.com> Message-ID: <9UTD5c1Flk-vANVUKmIWRMXlFy17MHuyClZ1E-ClwFw=.9999649e-b2cd-461e-a45b-78b12a6c0c67@github.com> On Fri, 26 Apr 2024 20:04:58 GMT, Zhao Song wrote: >> SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. >> >> There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > update Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1642#issuecomment-2080112268 From zsong at openjdk.org Fri Apr 26 21:02:40 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 21:02:40 GMT Subject: Integrated: 2244: SecurityLevel in JiraHost is useless In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 19:22:45 GMT, Zhao Song wrote: > SecurityLevel in JiraHost is rarely used and sometimes it will conflict with the security configuration of issueNotifier. So there is no point to keep it. Also, I removed the support of `/issue create` command in this patch as ErikJ suggested. > > There is one useful usage of `securityLevel`, it's in `JiraIssue#addWebLink`, skara bot uses the security to determine if the link should be posted as a comment. But I think it can be replaced by checking the visibilityRole of the jiraHost. This pull request has now been integrated. Changeset: a13dcde9 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/a13dcde9bc5f9c3575a6839957ee483ac00d7cc3 Stats: 228 lines in 7 files changed: 2 ins; 211 del; 15 mod 2244: SecurityLevel in JiraHost is useless Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1642 From zsong at openjdk.org Fri Apr 26 21:50:06 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 21:50:06 GMT Subject: Integrated: 2245: Don't check security in JiraIssueTrackerFactory Message-ID: In [SKARA-2244](https://bugs.openjdk.org/browse/SKARA-2244), we removed security in JiraHost but I forget to remove the condition of 'configuration.contains("security")' in JiraIssueTrackerFactory. So currently, if there is no security field in the configuration file, the factory would also ignore the visibility. ------------- Commit messages: - SKARA-2245 Changes: https://git.openjdk.org/skara/pull/1643/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1643&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2245 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1643.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1643/head:pull/1643 PR: https://git.openjdk.org/skara/pull/1643 From erikj at openjdk.org Fri Apr 26 21:50:07 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 26 Apr 2024 21:50:07 GMT Subject: Integrated: 2245: Don't check security in JiraIssueTrackerFactory In-Reply-To: References: Message-ID: <-T-jsEXZbQm0Nkp_VqT7705dmSPVOE9LpQqZsOJFTns=.edf86bcf-5652-455a-8d6f-edc1270ff407@github.com> On Fri, 26 Apr 2024 21:43:22 GMT, Zhao Song wrote: > In [SKARA-2244](https://bugs.openjdk.org/browse/SKARA-2244), we removed security in JiraHost but I forget to remove the condition of 'configuration.contains("security")' in JiraIssueTrackerFactory. > So currently, if there is no security field in the configuration file, the factory would also ignore the visibility. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1643#pullrequestreview-2025915631 From zsong at openjdk.org Fri Apr 26 21:50:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 21:50:07 GMT Subject: Integrated: 2245: Don't check security in JiraIssueTrackerFactory In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 21:43:22 GMT, Zhao Song wrote: > In [SKARA-2244](https://bugs.openjdk.org/browse/SKARA-2244), we removed security in JiraHost but I forget to remove the condition of 'configuration.contains("security")' in JiraIssueTrackerFactory. > So currently, if there is no security field in the configuration file, the factory would also ignore the visibility. This pull request has now been integrated. Changeset: 2372cbbc Author: Zhao Song URL: https://git.openjdk.org/skara/commit/2372cbbcc5d5b66715b8e0469b6ed798404435c8 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2245: Don't check security in JiraIssueTrackerFactory Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1643 From zsong at openjdk.org Fri Apr 26 21:50:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Fri, 26 Apr 2024 21:50:07 GMT Subject: Integrated: 2245: Don't check security in JiraIssueTrackerFactory In-Reply-To: References: Message-ID: On Fri, 26 Apr 2024 21:43:22 GMT, Zhao Song wrote: > In [SKARA-2244](https://bugs.openjdk.org/browse/SKARA-2244), we removed security in JiraHost but I forget to remove the condition of 'configuration.contains("security")' in JiraIssueTrackerFactory. > So currently, if there is no security field in the configuration file, the factory would also ignore the visibility. Thanks for the quick review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1643#issuecomment-2080159219 From ehelin at openjdk.org Sat Apr 27 13:46:47 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Sat, 27 Apr 2024 13:46:47 GMT Subject: RFR: 2226: Make it possible to avoid "forward backports" [v2] In-Reply-To: References: Message-ID: On Wed, 24 Apr 2024 19:35:42 GMT, Zhao Song wrote: >> Erik Duveblad has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into issue-notifier-avoid-forwardport >> - Fix comment in test >> - skara-2226 > > Marked as reviewed by zsong (Reviewer). Thanks @zhaosongzs and @erikj79 for reviewing! ------------- PR Comment: https://git.openjdk.org/skara/pull/1637#issuecomment-2080695474 From ehelin at openjdk.org Sat Apr 27 13:46:47 2024 From: ehelin at openjdk.org (Erik Duveblad) Date: Sat, 27 Apr 2024 13:46:47 GMT Subject: Integrated: 2226: Make it possible to avoid "forward backports" In-Reply-To: References: Message-ID: <_5G8iUNAuiE15Tnq0RqCTRuS1M5XZwBINsEOJkr5Ems=.db32a0f3-b79d-4826-897c-e01b7542be60@github.com> On Fri, 12 Apr 2024 08:54:03 GMT, Erik Duveblad wrote: > Hi all, > > please review this re-implementation of avoiding so called "forward backports", this time around in the `IssueNotifier`, meaning that Skara will avoid to create a "forward backport" _after_ a pull request has been integrated. Solving the problem in the `IssueNotifier` turned out to be a much more natural fit, so thanks @zhaosongzs and @erikj79 for the discussion in #1630. > > The new implementation will avoid creating a "foward backport" if _no_ suitable backport (or "forward backport") is found. That is, if JBS already contains a backport (or "forward backport") that can be used, then that backport (or "forward backport") will be used. This makes sense to me because in this scenario the user has (most likely) set up the issues in JBS for this to happen. But when Skara decides to create a _new_ backport, then (if `"avoidforwardports"` is `true` in the configuration) the code will never create "forward backport", instead opting to create a backport with the primary issue's `fixVersions` and setting `fixVersions` of the primary issue to the value found in the repository's `.jcheck/conf`. > > I also added a number of new unit tests. Note that this pull request depends on #1636 in order for the tests to pass, so the tests will fail until #1636 is integrated. > > Thanks, > Erik This pull request has now been integrated. Changeset: 052f7e01 Author: Erik Duveblad URL: https://git.openjdk.org/skara/commit/052f7e0132a18f369164ca5c613df3be93eb80d4 Stats: 284 lines in 4 files changed: 280 ins; 0 del; 4 mod 2226: Make it possible to avoid "forward backports" Reviewed-by: zsong, erikj ------------- PR: https://git.openjdk.org/skara/pull/1637 From johan.vos at gluonhq.com Sat Apr 27 19:41:22 2024 From: johan.vos at gluonhq.com (Johan Vos) Date: Sat, 27 Apr 2024 21:41:22 +0200 Subject: [External] : Re: Bot reusing branch names? In-Reply-To: <294c3dda-164f-48cd-8a62-121783c71e61@oracle.com> References: <098bf22c-e484-4bb8-acd6-d35098d9100a@oracle.com> <294c3dda-164f-48cd-8a62-121783c71e61@oracle.com> Message-ID: Thanks Erik, I can confirm the issue is fixed. - Johan On Fri, Apr 26, 2024 at 3:32?PM wrote: > On 4/25/24 11:46, erik.joelsson at oracle.com wrote: > > > On 4/25/24 10:05, Johan Vos wrote: > > Thanks for the investigation. That makes sense indeed, I didn't spot the > openjdk-bot versus openjdk-bots difference. > I see that the previous PR (22) has been closed, and a new PR (23) is > created, but that is still created from > https://github.com/openjdk-bot/mobile/tree/3 > > (without s) . > The instructions mention the repository at openjdk-bots (with s), so I > assume I should also close this PR? (I'm not in a hurry so I'll not touch > it as to not confuse the bot). > > I tried closing 22 to see if the bot would generate the next one > correctly. When it generated 23 with the same issue still present I dug > deeper into the source code and found the actual problem (detailed below). > Closing 23 will not help at this point. We need to fix SKARA-2242 > . > > I have deployed the fix to SKARA-2242, closed pull 23 and the bot has now > created pull 24 which looks correct. There are just a few conflicts. > > /Erik > > /Erik > > Thanks a lot! > > - Johan > > On Thu, Apr 25, 2024 at 2:40?PM wrote: > >> On 4/25/24 05:34, erik.joelsson at oracle.com wrote: >> > Hello Johan, >> > >> > (I finally had some time to look at this today) >> > >> > I recently changed the fork repository that the bot should be creating >> > these PRs from. It used to be "openjdk-bot/" but it's now >> > "openjdk-bots/", note the "s". In this PR the actual source repo >> > is the old "openjdk-bot" but the body text has "openjdk-bots" in the >> > instructions. The branch name is calculated based on the number of >> > branches present in the fork, so the number 2 indicates that it was >> > based on the new "openjdk-bots" repo, but still the PR has >> > "openjdk-bot/mobile" as the source. I'm puzzled and don't know how >> > this could have happened. >> > >> I believe this was caused by me changing the bot configuration, but this >> bot had cached local repositories in its private scratch work area, and >> those cached repositories had remotes still pointing to the old fork. I >> have deleted all cached data, and restarted the bot, but this PR is >> still broken and need to be closed. >> >> /Erik >> >> > /Erik >> > >> > On 4/25/24 00:25, Johan Vos wrote: >> >> Until recently, all PR's from the openjdk-bots that were created to >> >> allow solving conflicts when merging commits from openjdk/jdk:HEAD >> >> into openjdk/mobile:HEAD went fine. >> >> The last PR that was created though [1], seems to be weird and I >> >> wonder if there is something wrong with the PR generation. >> >> >> >> From the github website, it seems there are 25 files with a conflict, >> >> although that does not seem to be true when I compared them manually. >> >> The usual process of fixing the merge conflicts and pushing them to >> >> the openjdk-bots/mobile:+2 branch did not trigger the next steps in >> >> the PR on openjdk/mobile. >> >> >> >> What surprises me is that the latest branch in the >> >> openjdk-bots/mobile repository has the name "2". In the past, those >> >> branches had incremental names, and the previous branch was named >> >> "14". I expected to see a branch named "15" but the PR was raised >> >> from a branch named "2" which is 27772 commits behind the master of >> >> openjdk/mobile. >> >> >> >> - Johan >> >> >> >> [1] https://github.com/openjdk/mobile/pull/22 >> >> >> [2] https://github.com/openjdk-bot/mobile/tree/14 >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kcr at openjdk.org Mon Apr 29 21:13:02 2024 From: kcr at openjdk.org (Kevin Rushforth) Date: Mon, 29 Apr 2024 21:13:02 GMT Subject: RFR: 2234: /reviewers N should remove ready status for merge pull requests In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024 17:30:56 GMT, Zhao Song wrote: > In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. > > Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). > > To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. I think this is OK, since the situations where we would want to issue the `/reviewer` command are when we do want to make it blocking (if we don't want to make it blocking, we can ask for a review without bumping the minimum). ------------- PR Comment: https://git.openjdk.org/skara/pull/1639#issuecomment-2083669533 From zsong at openjdk.org Mon Apr 29 21:26:27 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 21:26:27 GMT Subject: RFR: 2246: Check if the pull request is still open before issuing "integrate" automatically Message-ID: IntegrateCommand has feature which is "/integrate auto". This command could make the pull request be automatically integrated when it is ready. But there is a bug. Let's say we have a merge pull request, it has the auto label and it has the merge-conflict label(the pr has some merge conflicts need to be resolved manually). 1. A user pushes a commit to the source branch , it resolves the merge conflict 2. In CheckWorkItem#1, the new commit triggers CheckRun, so pull request bot removes merge-conflict label and added clean and ready 3. The user uses ?Merge? button to merge the source branch into target branch in GitHub/GitLab 4. In the end of CheckWorkItem#1, pull request bot finds auto label and ready label, then issues ?/integrate? command 5. When processing the /integrate command, pull request bot finds it?s not able to merge. 6. In another CheckWorkItem#2, nothing in the pull request has changed, so CheckRun will be skipped. But in the end of CheckWorkItem#2, pr bot will find auto label and ready label, and will issue another?/integrate? command So the pull request bot will be stuck in a loop of step 4,5,6. To resolve this issue, as Erik suggested, in step4, we should check if the pr is still open. ------------- Commit messages: - SKARA-2246 Changes: https://git.openjdk.org/skara/pull/1644/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1644&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2246 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1644.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1644/head:pull/1644 PR: https://git.openjdk.org/skara/pull/1644 From erikj at openjdk.org Mon Apr 29 21:29:13 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 29 Apr 2024 21:29:13 GMT Subject: RFR: 2234: /reviewers N should remove ready status for merge pull requests In-Reply-To: References: Message-ID: <40mSlSAODXScZ0S3K6vf0GUTHO_vlFQhtZ13CYsa7SY=.e48149c9-cf22-4a2b-9b8a-f43109414766@github.com> On Tue, 16 Apr 2024 17:30:56 GMT, Zhao Song wrote: > In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. > > Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). > > To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1639#pullrequestreview-2029677348 From erikj at openjdk.org Mon Apr 29 21:30:03 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 29 Apr 2024 21:30:03 GMT Subject: RFR: 2246: Check if the pull request is still open before issuing "integrate" automatically In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 21:14:24 GMT, Zhao Song wrote: > IntegrateCommand has feature which is "/integrate auto". This command could make the pull request be automatically integrated when it is ready. But there is a bug. > > Let's say we have a merge pull request, it has the auto label and it has the merge-conflict label(the pr has some merge conflicts need to be resolved manually). > 1. A user pushes a commit to the source branch , it resolves the merge conflict > 2. In CheckWorkItem#1, the new commit triggers CheckRun, so pull request bot removes merge-conflict label and added clean and ready > 3. The user uses ?Merge? button to merge the source branch into target branch in GitHub/GitLab > 4. In the end of CheckWorkItem#1, pull request bot finds auto label and ready label, then issues ?/integrate? command > 5. When processing the /integrate command, pull request bot finds it?s not able to merge. > 6. In another CheckWorkItem#2, nothing in the pull request has changed, so CheckRun will be skipped. But in the end of CheckWorkItem#2, pr bot will find auto label and ready label, and will issue another?/integrate? command > > So the pull request bot will be stuck in a loop of step 4,5,6. > > To resolve this issue, as Erik suggested, in step4, we should check if the pr is still open. Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1644#pullrequestreview-2029678361 From zsong at openjdk.org Mon Apr 29 22:04:27 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:04:27 GMT Subject: RFR: 2234: /reviewers N should remove ready status for merge pull requests In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024 17:30:56 GMT, Zhao Song wrote: > In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. > > Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). > > To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1639#issuecomment-2083759192 From zsong at openjdk.org Mon Apr 29 22:04:41 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:04:41 GMT Subject: Integrated: 2246: Check if the pull request is still open before issuing "integrate" automatically In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 21:14:24 GMT, Zhao Song wrote: > IntegrateCommand has feature which is "/integrate auto". This command could make the pull request be automatically integrated when it is ready. But there is a bug. > > Let's say we have a merge pull request, it has the auto label and it has the merge-conflict label(the pr has some merge conflicts need to be resolved manually). > 1. A user pushes a commit to the source branch , it resolves the merge conflict > 2. In CheckWorkItem#1, the new commit triggers CheckRun, so pull request bot removes merge-conflict label and added clean and ready > 3. The user uses ?Merge? button to merge the source branch into target branch in GitHub/GitLab > 4. In the end of CheckWorkItem#1, pull request bot finds auto label and ready label, then issues ?/integrate? command > 5. When processing the /integrate command, pull request bot finds it?s not able to merge. > 6. In another CheckWorkItem#2, nothing in the pull request has changed, so CheckRun will be skipped. But in the end of CheckWorkItem#2, pr bot will find auto label and ready label, and will issue another?/integrate? command > > So the pull request bot will be stuck in a loop of step 4,5,6. > > To resolve this issue, as Erik suggested, in step4, we should check if the pr is still open. This pull request has now been integrated. Changeset: d8a8a24d Author: Zhao Song URL: https://git.openjdk.org/skara/commit/d8a8a24d35b1ee461e42364d8d6c2a1215a8ca8f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2246: Check if the pull request is still open before issuing "integrate" automatically Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1644 From zsong at openjdk.org Mon Apr 29 22:04:41 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:04:41 GMT Subject: RFR: 2246: Check if the pull request is still open before issuing "integrate" automatically In-Reply-To: References: Message-ID: <9FdpyPj6TYPLWGeYz4FeGoGslAURyMgx7a37VRgI3Hw=.542ee361-81e3-44a6-9751-414d3a187f70@github.com> On Mon, 29 Apr 2024 21:14:24 GMT, Zhao Song wrote: > IntegrateCommand has feature which is "/integrate auto". This command could make the pull request be automatically integrated when it is ready. But there is a bug. > > Let's say we have a merge pull request, it has the auto label and it has the merge-conflict label(the pr has some merge conflicts need to be resolved manually). > 1. A user pushes a commit to the source branch , it resolves the merge conflict > 2. In CheckWorkItem#1, the new commit triggers CheckRun, so pull request bot removes merge-conflict label and added clean and ready > 3. The user uses ?Merge? button to merge the source branch into target branch in GitHub/GitLab > 4. In the end of CheckWorkItem#1, pull request bot finds auto label and ready label, then issues ?/integrate? command > 5. When processing the /integrate command, pull request bot finds it?s not able to merge. > 6. In another CheckWorkItem#2, nothing in the pull request has changed, so CheckRun will be skipped. But in the end of CheckWorkItem#2, pr bot will find auto label and ready label, and will issue another?/integrate? command > > So the pull request bot will be stuck in a loop of step 4,5,6. > > To resolve this issue, as Erik suggested, in step4, we should check if the pr is still open. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/skara/pull/1644#issuecomment-2083759637 From zsong at openjdk.org Mon Apr 29 22:04:27 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:04:27 GMT Subject: Integrated: 2234: /reviewers N should remove ready status for merge pull requests In-Reply-To: References: Message-ID: On Tue, 16 Apr 2024 17:30:56 GMT, Zhao Song wrote: > In this pr https://github.com/openjdk/jfx22u/pull/26, Kevin issued "/reviewers 1" in the merge pull request but skara didn't remove the ready label. > > Jfx22u was not configured with ?reviewMerge?, so the reviewers jcheck were skipped. The reason we can see `Change must be properly reviewed (1 review required, with at least 1 Reviewer)` in the PR body is because of [SKARA-1824](https://bugs.openjdk.org/browse/SKARA-1824). > > To resolve this issue, we should enable `reviewMerge` when a reviewers command is issued in a merge pull request. This pull request has now been integrated. Changeset: 7e810cac Author: Zhao Song URL: https://git.openjdk.org/skara/commit/7e810cac854f2f55cc7fb85f76b4ebc6cabaf2c6 Stats: 77 lines in 2 files changed: 75 ins; 2 del; 0 mod 2234: /reviewers N should remove ready status for merge pull requests Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1639 From zsong at openjdk.org Mon Apr 29 22:11:26 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:11:26 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing Message-ID: Kevin Rushforth found this GitLab issue few years ago. Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. ------------- Commit messages: - SKARA-2247 Changes: https://git.openjdk.org/skara/pull/1645/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2247 Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/skara/pull/1645.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/skara/pull/1645 From erikj at openjdk.org Mon Apr 29 22:48:21 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 29 Apr 2024 22:48:21 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 22:01:27 GMT, Zhao Song wrote: > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 436: > 434: String text = "The head hash of this pull request is missing.\n" + > 435: "Until this is resolved, this pull request cannot be processed.\n" + > 436: "Please try to use the following command to push an empty commit.\n" + Suggestion: "This is likely caused by a caching problem in the server and can usually be worked around by pushing another commit to the pull request branch. The commit can be empty. Example:\n" + I also recommend removing all the explicit single line breaks. Single linebreaks will not be honored when formatting anyway and we don't want these sentences in separate paragraphs. bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 441: > 439: "$ git push\n" + > 440: "```\n" + > 441: "If the issue still exists, please notify skara admins."; Suggestion: "If the issue still exists, please notify Skara admins."; ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1645#discussion_r1583860437 PR Review Comment: https://git.openjdk.org/skara/pull/1645#discussion_r1583859717 From zsong at openjdk.org Mon Apr 29 22:54:48 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 22:54:48 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v2] In-Reply-To: References: Message-ID: <_1lH_XQ4Did0G2DWLjn89KMc7m113ROsxeABui3sYXg=.d366c904-0cd4-4bc5-8c03-b3d901fd58f8@github.com> > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> - Update bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1645/files - new: https://git.openjdk.org/skara/pull/1645/files/61ae8b5d..a3945c42 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/skara/pull/1645.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/skara/pull/1645 From zsong at openjdk.org Mon Apr 29 23:00:27 2024 From: zsong at openjdk.org (Zhao Song) Date: Mon, 29 Apr 2024 23:00:27 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v3] In-Reply-To: References: Message-ID: > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1645/files - new: https://git.openjdk.org/skara/pull/1645/files/a3945c42..66359318 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/skara/pull/1645.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/skara/pull/1645 From erikj at openjdk.org Mon Apr 29 23:22:24 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 29 Apr 2024 23:22:24 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v3] In-Reply-To: References: Message-ID: <4gsN_6y9GdZAdBHZQNcelrQL6ljZx8za_EyuF4rwmdw=.f231c41d-dbc4-4fb0-a0d5-6e7b6fdc3f5e@github.com> On Mon, 29 Apr 2024 23:00:27 GMT, Zhao Song wrote: >> Kevin Rushforth found this GitLab issue few years ago. >> >> Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". >> >> In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. >> >> To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 434: > 432: > 433: if (pr.headHash().hex() == null) { > 434: String text = "The head hash of this pull request is missing." + Suggestion: String text = "The head hash of this pull request is missing. " + bots/pr/src/main/java/org/openjdk/skara/bots/pr/CheckWorkItem.java line 436: > 434: String text = "The head hash of this pull request is missing." + > 435: "Until this is resolved, this pull request cannot be processed." + > 436: "This is likely caused by a caching problem in the server and can usually be worked around by pushing another commit to the pull request branch. " + Probably break this line a bit. ------------- PR Review Comment: https://git.openjdk.org/skara/pull/1645#discussion_r1583892217 PR Review Comment: https://git.openjdk.org/skara/pull/1645#discussion_r1583892431 From zsong at openjdk.org Tue Apr 30 00:00:19 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 00:00:19 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v4] In-Reply-To: References: Message-ID: > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. 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/CheckWorkItem.java Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/skara/pull/1645/files - new: https://git.openjdk.org/skara/pull/1645/files/66359318..f1e3d713 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=03 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1645.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/skara/pull/1645 From zsong at openjdk.org Tue Apr 30 00:04:07 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 00:04:07 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v5] In-Reply-To: References: Message-ID: <3JeNsHxxxVQw7W3k6KpA-UBgbG-E1ROlPj_JE-r_A2o=.8ed8771a-3c30-4008-912d-5aab8f6bcea1@github.com> > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: review comment ------------- Changes: - all: https://git.openjdk.org/skara/pull/1645/files - new: https://git.openjdk.org/skara/pull/1645/files/f1e3d713..e5222f61 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=04 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1645&range=03-04 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1645.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1645/head:pull/1645 PR: https://git.openjdk.org/skara/pull/1645 From erikj at openjdk.org Tue Apr 30 12:26:13 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 30 Apr 2024 12:26:13 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v5] In-Reply-To: <3JeNsHxxxVQw7W3k6KpA-UBgbG-E1ROlPj_JE-r_A2o=.8ed8771a-3c30-4008-912d-5aab8f6bcea1@github.com> References: <3JeNsHxxxVQw7W3k6KpA-UBgbG-E1ROlPj_JE-r_A2o=.8ed8771a-3c30-4008-912d-5aab8f6bcea1@github.com> Message-ID: On Tue, 30 Apr 2024 00:04:07 GMT, Zhao Song wrote: >> Kevin Rushforth found this GitLab issue few years ago. >> >> Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". >> >> In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. >> >> To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1645#pullrequestreview-2031173262 From zsong at openjdk.org Tue Apr 30 16:05:14 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 16:05:14 GMT Subject: RFR: 2247: When pr's headHash is missing, stop further processing [v5] In-Reply-To: <3JeNsHxxxVQw7W3k6KpA-UBgbG-E1ROlPj_JE-r_A2o=.8ed8771a-3c30-4008-912d-5aab8f6bcea1@github.com> References: <3JeNsHxxxVQw7W3k6KpA-UBgbG-E1ROlPj_JE-r_A2o=.8ed8771a-3c30-4008-912d-5aab8f6bcea1@github.com> Message-ID: On Tue, 30 Apr 2024 00:04:07 GMT, Zhao Song wrote: >> Kevin Rushforth found this GitLab issue few years ago. >> >> Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". >> >> In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. >> >> To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. > > Zhao Song has updated the pull request incrementally with one additional commit since the last revision: > > review comment Thanks! ------------- PR Comment: https://git.openjdk.org/skara/pull/1645#issuecomment-2085782694 From zsong at openjdk.org Tue Apr 30 16:05:14 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 16:05:14 GMT Subject: Integrated: 2247: When pr's headHash is missing, stop further processing In-Reply-To: References: Message-ID: On Mon, 29 Apr 2024 22:01:27 GMT, Zhao Song wrote: > Kevin Rushforth found this GitLab issue few years ago. > > Sometimes, pull requests in GitLab would be stuck. When it happens, it shows the number of commits as "0". Clicking on the "Changes" tab shows no diffs, and displays a warning banner: "Something went wrong on our end. Please try again!" This requires action on user's part to get them "unstuck". > > In Skara side, when it happens, pull request bot would not be able to get the headHash of this pull request and then throw an exception and trigger an other round of CheckWorkItem. If the user doesn't fix it, skara bot will continuously work on the pull request. > > To resolve it, we should try to make pull request bot be able to identify this situation and provide some guidance to the users. This pull request has now been integrated. Changeset: 695dbc6b Author: Zhao Song URL: https://git.openjdk.org/skara/commit/695dbc6b9603b5c1b4237ce24d4aacf9d1461d1d Stats: 15 lines in 1 file changed: 15 ins; 0 del; 0 mod 2247: When pr's headHash is missing, stop further processing Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1645 From zsong at openjdk.org Tue Apr 30 19:44:58 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 19:44:58 GMT Subject: RFR: 2249: serviceability mailing list should be notified of changes to heapdumper and diagnostic files Message-ID: The serviceability mailing list should be notified of changes to the following files: src/hotspot/share/services/heapDumper.cpp src/hotspot/share/services/heapDumper.hpp src/hotspot/share/services/heapDumperCompression.cpp src/hotspot/share/services/heapDumperCompression.hpp src/hotspot/share/services/diagnosticArgument.cpp src/hotspot/share/services/diagnosticArgument.hpp src/hotspot/share/services/diagnosticCommand.cpp src/hotspot/share/services/diagnosticCommand.hpp src/hotspot/share/services/diagnosticFramework.cpp src/hotspot/share/services/diagnosticFramework.hpp ------------- Commit messages: - SKARA-2249 Changes: https://git.openjdk.org/skara/pull/1646/files Webrev: https://webrevs.openjdk.org/?repo=skara&pr=1646&range=00 Issue: https://bugs.openjdk.org/browse/SKARA-2249 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1646.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1646/head:pull/1646 PR: https://git.openjdk.org/skara/pull/1646 From erikj at openjdk.org Tue Apr 30 20:15:53 2024 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 30 Apr 2024 20:15:53 GMT Subject: RFR: 2249: serviceability mailing list should be notified of changes to heapdumper and diagnostic files In-Reply-To: References: Message-ID: <13Kg4AcDt6cUrE18ZSS8gG9MgdkPuqcjKyMNBRUH4Yc=.192babfd-b18e-4ba7-83b4-3c10a7fdd7ff@github.com> On Tue, 30 Apr 2024 19:39:42 GMT, Zhao Song wrote: > The serviceability mailing list should be notified of changes to the following files: > > src/hotspot/share/services/heapDumper.cpp > src/hotspot/share/services/heapDumper.hpp > src/hotspot/share/services/heapDumperCompression.cpp > src/hotspot/share/services/heapDumperCompression.hpp > src/hotspot/share/services/diagnosticArgument.cpp > src/hotspot/share/services/diagnosticArgument.hpp > src/hotspot/share/services/diagnosticCommand.cpp > src/hotspot/share/services/diagnosticCommand.hpp > src/hotspot/share/services/diagnosticFramework.cpp > src/hotspot/share/services/diagnosticFramework.hpp Marked as reviewed by erikj (Lead). ------------- PR Review: https://git.openjdk.org/skara/pull/1646#pullrequestreview-2032440898 From zsong at openjdk.org Tue Apr 30 20:27:05 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 20:27:05 GMT Subject: Integrated: 2249: serviceability mailing list should be notified of changes to heapdumper and diagnostic files In-Reply-To: References: Message-ID: <2Sh7u0EZn1jXdDyFWb5DPjNbI7yFM2d224pg9Ic0RgQ=.4b36b0cf-97ba-490d-80b0-c7af91a6e1df@github.com> On Tue, 30 Apr 2024 19:39:42 GMT, Zhao Song wrote: > The serviceability mailing list should be notified of changes to the following files: > > src/hotspot/share/services/heapDumper.cpp > src/hotspot/share/services/heapDumper.hpp > src/hotspot/share/services/heapDumperCompression.cpp > src/hotspot/share/services/heapDumperCompression.hpp > src/hotspot/share/services/diagnosticArgument.cpp > src/hotspot/share/services/diagnosticArgument.hpp > src/hotspot/share/services/diagnosticCommand.cpp > src/hotspot/share/services/diagnosticCommand.hpp > src/hotspot/share/services/diagnosticFramework.cpp > src/hotspot/share/services/diagnosticFramework.hpp This pull request has now been integrated. Changeset: 53f65c29 Author: Zhao Song URL: https://git.openjdk.org/skara/commit/53f65c291fb28d2b5f9c6244d4d7f9319500587f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 2249: serviceability mailing list should be notified of changes to heapdumper and diagnostic files Reviewed-by: erikj ------------- PR: https://git.openjdk.org/skara/pull/1646 From zsong at openjdk.org Tue Apr 30 21:53:49 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 21:53:49 GMT Subject: RFR: 2170: Warn on trailing period in PR titles [v2] In-Reply-To: References: Message-ID: > This patch is trying to add a new jcheck called "issuestitle". This jcheck would check if the issue's title has a trailing period or leading lowercase letter. And we would like to configure "issuestitle" jcheck as warning in the repos since in some cases, trailing periods are valid. > > When implementing this, I found that although we can configure a jcheck as warning in the jcheck configuration file(.jcheck/conf), we fail to differentiate between jchecks as error and jchecks as warning. When jchecks fail as warnings, they cause the local jcheck to exit with a status code of 1. Also, they will be integration blockers when Skara bots evaluate pull requests. Therefore, in this patch, I also make Skara CLI and Skara bots be able to handle jcheck warnings properly. Zhao Song has updated the pull request incrementally with two additional commits since the last revision: - update tests - SKARA-2248 ------------- Changes: - all: https://git.openjdk.org/skara/pull/1638/files - new: https://git.openjdk.org/skara/pull/1638/files/4c6364b7..2a4e6ee0 Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1638&range=01 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1638&range=00-01 Stats: 33 lines in 5 files changed: 24 ins; 0 del; 9 mod Patch: https://git.openjdk.org/skara/pull/1638.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1638/head:pull/1638 PR: https://git.openjdk.org/skara/pull/1638 From zsong at openjdk.org Tue Apr 30 22:29:04 2024 From: zsong at openjdk.org (Zhao Song) Date: Tue, 30 Apr 2024 22:29:04 GMT Subject: RFR: 2170: Warn on trailing period in PR titles [v3] In-Reply-To: References: Message-ID: <3rnG3w4iXYWydAwmYEXvwMXesC7SzveuGYZGVJpy480=.3bf184c7-7586-4df1-aec3-760c753d7af1@github.com> > This patch is trying to add a new jcheck called "issuestitle". This jcheck would check if the issue's title has a trailing period or leading lowercase letter. And we would like to configure "issuestitle" jcheck as warning in the repos since in some cases, trailing periods are valid. > > When implementing this, I found that although we can configure a jcheck as warning in the jcheck configuration file(.jcheck/conf), we fail to differentiate between jchecks as error and jchecks as warning. When jchecks fail as warnings, they cause the local jcheck to exit with a status code of 1. Also, they will be integration blockers when Skara bots evaluate pull requests. Therefore, in this patch, I also make Skara CLI and Skara bots be able to handle jcheck warnings properly. Zhao Song has updated the pull request incrementally with one additional commit since the last revision: fix test ------------- Changes: - all: https://git.openjdk.org/skara/pull/1638/files - new: https://git.openjdk.org/skara/pull/1638/files/2a4e6ee0..584bcbfe Webrevs: - full: https://webrevs.openjdk.org/?repo=skara&pr=1638&range=02 - incr: https://webrevs.openjdk.org/?repo=skara&pr=1638&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/skara/pull/1638.diff Fetch: git fetch https://git.openjdk.org/skara.git pull/1638/head:pull/1638 PR: https://git.openjdk.org/skara/pull/1638