8342988: GHA: Build JTReg in single step

[vieiro]

Backport of 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 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? 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 timeout
2025-02-14T17:50:36.6837390Z --------------------------------------------------
2025-02-14T17:51:15.1063160Z TEST: serviceability/sa/ClhsdbFindPC.java#id3
2025-02-14T17:51:15.1461480Z   build: 2.91 seconds
2025-02-14T17:51:15.1520520Z   compile: 2.909 seconds
2025-02-14T17:51:15.1535170Z   main: 102.784 seconds
2025-02-14T17:51:15.1536860Z TEST RESULT: Passed. Execution successful

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• JDK-8342988 needs maintainer approval

Issue

• JDK-8342988: GHA: Build JTReg in single step (Enhancement - P4)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk11u-dev.git pull/2996/head:pull/2996
$ git checkout pull/2996

Update a local copy of the PR:
$ git checkout pull/2996
$ git pull https://git.openjdk.org/jdk11u-dev.git pull/2996/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 2996

View PR using the GUI difftool:
$ git pr show -t 2996

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk11u-dev/pull/2996.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back vieiro! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

This backport pull request has now been updated with issue from the original commit.

[mlbridge]

Webrevs

• 00: Full (0978adaa)

[jerboaa]

There seems to be a problem of still building JTREG if it's not found in the cache in actions/get-jreg/action.yml. Instead, we should not look in the cache but use download-artifact as is being done on the JDK 17 version of this. Am I missing something?

[jerboaa]

This still builds jtreg? Shouldn't it use actions/download-artifact@v4 to get the built version like is done on the JDK 17 version of this patch:
openjdk/jdk17u-dev@087e8a2#diff-3a815a14d4d572818da85d29537d07cf3199fc15a6db7eaa9427a73f024d23dcR42

[vieiro]

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@v4 (even though the upload-artifact@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.

[vieiro]

I'm afraid I won't be able to redo this anytime soon, so let's close it and reopen later on.