RFR: 8350443: GHA: Split static-libs-bundles into a separate job [v3]

[Erik Joelsson]

On Fri, 21 Feb 2025 08:35:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Noticed this when reviewing [JDK-8349399](https://bugs.openjdk.org/browse/JDK-8349399), which had to kludgy workaround the hunk introduced by `static-libs-bundles` addition ([JDK-8337265](https://bugs.openjdk.org/browse/JDK-8337265)). I am somewhat surprised we even have `static-libs-bundles` as additional target in what I would consider a generic build-linux job! It looks cleaner to yank `static-libs-bundles` into a separate build job.
>> 
>> This effectively reverts parts of the original change, and does a few modifications:
>>  - I see no reason to store the bundles, and continuing to do so would effectively overwrite `linux-x64-bundles` when we split the static build into another job, breaking tests. Not sure why we had to publish those bundles, @dougxc? They are not used in current JDK tests, I think?
>>  - The matrix definition in `build-linux.xml` unconditionally includes `debug` configuration to override flags and suffix, I had to redo this with inline variables
>> 
>> Named the new job `linux-x64-static`, since I expect @jianglizhou to slide https://github.com/openjdk/jdk/pull/23471 just there by adding another `make-target` into that job definition.
>> 
>> I did a partial GHA run already, and I expect full run to complete without errors.
>> 
>> Testing:
>>  - [x] GHA
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Touch up comment

I'm not sure splitting static out into it's own task is the right long term direction we should be heading in. Magnus is working on reducing the duplicated work needed to build both a regular JDK and static libs at the same time, by reusing all the object files. 

I would also argue that there is a big difference between the old static-libs-bundle and the new static JDK distribution conceptually, so bunching them up in the same "static" category doesn't make much sense to me, other than as a (misguided) attempt at optimizing GHA compute resources. The old static-libs-bundle is static versions of JDK libs needed by certain downstream consumers of the regular JDK distribution (Graal). This is essentially an extension of the regular JDK. The new static JDK distro that @jianglizhou and @magicus are working on is a complete separate JDK variant that replaces the regular JDK.

Having one build task produce more than one JDK for testing can cause a challenge in the model for a build and test system, so for that reason it makes sense having a separate build task for the static JDK. That would also isolate build problems with the static JDK and avoid having them block test results for the regular JDK. I never delved deep enough into GHA to know if this would cause an issue here or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/23715#issuecomment-2674635422