mingyen066 opened a new pull request, #20805:
URL: https://github.com/apache/kafka/pull/20805

   Currently, if we merge to the 4.0 branch, the `CI` workflow in branch 
**`4.0`** will be
   triggered. After the 4.0 `CI` finishes, it triggeres the
   `ci-complete.yml` workflow in the **`trunk`** branch. However, the JDK
   versions, Gradle version and the names of the build scan files differ
   (due to [KAFKA-18748](https://issues.apache.org/jira/browse/KAFKA-18748)), so
   the trunk `ci-complete.yml` cannot find the correct BuildScan files
   generated by `4.0` CI workflow to upload to Develocity.
   
   To address this, I added a job in `ci-complete` to first retrieve all build 
scan file names that start with `build-scan-`, then create a job for each file, 
extract the java version from the name, and finnaly upload the corresponding 
BuildScan.
   
   There is a potential issue with using Gradle 9 to upload Gradle 8
   buildScan archives to Develocity, I am not sure if it will work because
   I don't have access to a Develocity server to test it. I could only find the
   compatibility table for Develocity plugin and Gradle tools.
   https://docs.gradle.com/develocity/compatibility/#build_scans
   
   I have tested this in my forked repo. There are two `ci-complete` runs in 
the following, one for the `trunk` build, and the other for a PR merged into 
the `4.0` branch. Each run can upload different BuildScan files up to the 
Gradle task `buildScanPublishPrevious` which I could not test due to lacking a 
Develocity access token.
   * https://github.com/mingyen066/kafka/actions/runs/19000866672
   * https://github.com/mingyen066/kafka/actions/runs/18999744250


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to