[jdk11u-dev] RFR: 8342988: GHA: Build JTReg in single step

[Antonio Vieiro]

On Tue, 11 Mar 2025 13:14:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Backport of [JDK-8349829](https://bugs.openjdk.org/browse/JDK-8349829) from 17u to build jtreg and cache it for subsequent builds. Low risk (only GHA actions affected).
>> 
>> The backport is not clean as [JDK-8338286](https://bugs.openjdk.org/browse/JDK-8338286) has not been backported to JDK-11, on purpose.  Also `JAVA_HOME_11_X64`  is being used now to build `jtreg`.
>> 
>> As expected jtreg is now being built & cached in subsequent builds:
>> 
>> 
>> 2025-02-14T17:08:58.4041646Z Cache hit for: jtreg-7.3.1+1
>> 2025-02-14T17:08:58.6790456Z Received 9265658 of 9265658 (100.0%), 42.7 MBs/sec
>> 2025-02-14T17:08:58.6791682Z Cache Size: ~9 MB (9265658 B)
>> 2025-02-14T17:08:58.6819135Z [command]/usr/bin/tar -xf /home/runner/work/_temp/fe85d627-93f0-40be-9ba4-b41aadc9f6ed/cache.tzst -P -C /home/runner/work/jdk11u-dev/jdk11u-dev --use-compress-program unzstd
>> 2025-02-14T17:08:58.7115863Z Cache restored successfully
>> 2025-02-14T17:08:58.7298813Z Cache restored from key: jtreg-7.3.1+1
>> 
>> 
>> All tests pass but I detected an intermittent time- out in serviceability agent in macos (possibly because of [JDK-8260389](https://bugs.openjdk.org/browse/JDK-8260389)? despite JDK-8294316 having been already integrated. This is under investigation).
>> 
>> 
>> 2025-02-14T17:48:43.0846500Z --------------------------------------------------
>> 2025-02-14T17:48:46.6648080Z TEST: serviceability/sa/ClhsdbFindPC.java#id0
>> 2025-02-14T17:48:46.6661380Z   build: 0.886 seconds
>> 2025-02-14T17:48:46.6662400Z   compile: 0.886 seconds
>> 2025-02-14T17:48:46.6663300Z   main: 34.198 seconds
>> 2025-02-14T17:48:46.6664240Z TEST RESULT: Passed. Execution successful
>> 2025-02-14T17:48:46.6665470Z --------------------------------------------------
>> 2025-02-14T17:49:24.4350100Z TEST: serviceability/sa/ClhsdbFindPC.java#id2
>> 2025-02-14T17:49:24.4351780Z   build: 0.653 seconds
>> 2025-02-14T17:49:24.4352850Z   compile: 0.653 seconds
>> 2025-02-14T17:49:24.4353430Z   main: 31.826 seconds
>> 2025-02-14T17:49:24.4353820Z TEST RESULT: Passed. Execution successful
>> 2025-02-14T17:49:24.4354390Z --------------------------------------------------
>> 2025-02-14T17:50:36.6580860Z TEST: serviceability/sa/ClhsdbFindPC.java#id1
>> 2025-02-14T17:50:36.6582200Z TEST JDK: /Users/runner/work/jdk11u-dev/jdk11u-dev/bundles/jdk/jdk-11.0.27/fastdebug
>> ...
>> 2025-02-14T17:50:36.6836040Z TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Test ERROR java.io.IOException: App waiting timeou...
>
> .github/actions/get-jtreg/action.yml line 1:
> 
>> 1: #
> 
> This still builds jtreg? Shouldn't it use `actions/download-artifact at v4` to get the built version like is done on the JDK 17 version of this patch:
> https://github.com/openjdk/jdk17u-dev/commit/087e8a29f2aead8b31a71b144523810c8538388c#diff-3a815a14d4d572818da85d29537d07cf3199fc15a6db7eaa9427a73f024d23dcR42

Hi @jerboaa . Thanks for the review!

The cache is checked against using the `if: steps.get-cached-jtreg.outputs.cache-hit != 'true'` , so no rebuilds are required if cached. But we're indeed missing the `actions/download-artifact at v4` (even though the `upload-artifact at v4` is in place).

I tried to make a minimum-change PR, for an easier review, so I missed this thunk. 

Thinking of it I think I'll do a new PR with _all_ changes in JDK17 (for instance, renaming the `select` job in 11 to `prepare` in 17, instead of keeping the JDK11 version). This will make the PR slightly more difficult to review, but we'll be in-sync with JDK17, so _future_ changes will be easier to backport.

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

PR Review Comment: https://git.openjdk.org/jdk11u-dev/pull/2996#discussion_r2005305821