On Tue, 7 Jun 2022 22:47:32 GMT, Jonathan Gibbons <j...@openjdk.org> wrote:
>> make/conf/github-actions.conf line 31: >> >>> 29: >>> 30: >>> JTREG_URL=https://ci.adoptopenjdk.net/view/Dependencies/job/dependency_pipeline/330/artifact/jtreg/jtreg-6.1+1.tar.gz >>> 31: >>> JTREG_SHA256=ccfa21f54bb173f818a5a8d93f77d49301f275f0677c9f914297046c910c5129 >> >> This seems questionable, and adds a very suspect blocking dependency on that >> website for when we want to update the version of jtreg to be used. > > There are many issues at play in this PR. Can we handle "where to get jtreg" > separately from the other issues here: rewriting the actions, and whether to > switch to use MSYS2 instead of Cygwin. I reverted to the old method of building jtreg locally, with some changes. I do not attempt to build it before starting all runs, but instead each build job will start by building it if it is not in the cache. This adds < 60 seconds of build time so I think this is fully acceptable to avoid the complexity of the old solution. Most of the time a cache hit is likely to happen. GHA caches are indirectly keyed on runner OS (this also means that the explicit `runner.os` in the cache key for bootjdk is not strictly necessary, but only there to make it more obvious), so in theory this needs to be built at least once for Windows, macOS and Linux. After this, it is cached, and only removed from the cache if not having been accessed for 7 days. The 6.1+1 release of jtreg can not be built on msys2. There is a PR open (https://github.com/openjdk/jtreg/pull/87) with a fix. For the time being, while I address some additional issues in this PR, I have set the JTReg ref to checkout to this PR. Hopefully this fix will be included in a proper JTReg release when this PR is ready for integration. I still think it would be superior to download a prebuilt binary, though. ------------- PR: https://git.openjdk.java.net/jdk/pull/9063
