Open sxa opened 2 months ago
@sxa thanks for this write up.
There hasn't been a huge flurry of activity on the riscv-port-jdk11u port, but I attribute it to a lack of demand. Having Adoptium drive such demand would be a useful boost.
Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.
Is that something that would need to happen on https://github.com/openjdk/riscv-port-jdk11u/ directly? Or is there something we can do on our mirror of that repo?
Remove this build from the pipelines (since they pass the tag through)
I'm not sure what you mean by "this build".
and look at just building that one periodically on a schedule.
Would we need the tag in order to release jdk11u? And would these tag required to be done automatically?
@sxa thanks for this write up.
There hasn't been a huge flurry of activity on the riscv-port-jdk11u port, but I attribute it to a lack of demand. Having Adoptium drive such demand would be a useful boost.
Hard to say - I'm not sure Adoptium would particularly want to actively encourage use of what is a relatively old version, so I feel that any demand should come from the user base (also on a purely personal note I'd rather have a headful jdk21 than a jdk11 for example, although that would generate extra work at release time, but bring consistency with other Linuxes - I feel that us releasing a headful riscv64 JDKis perhaps more using that a headful s390x build ;-) )
Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.
Is that something that would need to happen on https://github.com/openjdk/riscv-port-jdk11u/ directly? Or is there something we can do on our mirror of that repo?
Either should be feasible although my preference would be to have it upstream if possible. A comparable example is the jdk8/arm32 port which is also in a separate repository. In there we get similar tags to what we have in the jdk11/riscv64 repo, but there are additional ones with names like jdk8u422-ga-aarch32-20240725 that include the arm32 specific changes. I'll not that that's not ideal either since we have to initiate the pipelines separately due to the different tag, but that would perhaps be the easier option to go for if it was possible upstream.
Remove this build from the pipelines (since they pass the tag through)
I'm not sure what you mean by "this build".
Apologies for the lack of clarity - I mean remove jdk11u/riscv64 as one of the platforms that is kicked off automatically via evaluation-openjdk11-pipeline (defined in jdk11u_evaluation.groovy when there is a new tag in the upstream openjdk repository, since the tag cannot be built on that platform.
and look at just building that one periodically on a schedule.
Would we need the tag in order to release jdk11u? And would these tag required to be done automatically?
We've built off custom tags before, so for release purposes we could manually generate a tag in the adopt repository, but if we can avoid manual steps that would be preferable but not absolutely required..
This is being discussed on the riscv-port-jdk11u list at https://mail.openjdk.org/pipermail/riscv-port-dev/2024-August/001396.html
A tag has now been created upstream similar to how the aarch32 ports are done and the _adopt
version of that tag has been created automatically by the mirror scripts. I've kicked off a build with it here (SCM_REF
parameter) at https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/44/console (although the automation in the evaluation pipeline won't currently pick this up automatically in the future without additional modifications) but that has failed with:
12:45:18 checking if packaged modules are kept... yes (default)
12:45:18 configure: error: "4-riscv64-20240825" is not a valid numerical value for VERSION_BUILD
12:45:18 configure exiting with result code 1
So a bit of extra work is going to need to happen here before we can build this regularly.
Passes if I add -B 4
to the BUILD_ARGS
in the job to override the detected value.
I suspect it's somewhere around https://github.com/adoptium/temurin-build/blob/1f1cebf33c5fa42ba5b4da8d614709d5e4a8161a/sbin/build.sh#L418 that needs to be modified with a fix similar to https://github.com/adoptium/temurin-build/blob/1f1cebf33c5fa42ba5b4da8d614709d5e4a8161a/sbin/build.sh#L390 which is done for jdk8 to strip off the extra suffix.
That's interesting ... I haven't looked into it too closely by https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/46 which was automatically kicked off yesterday seemed to get through the build despite being run from jdk-11.0.25+5_adopt
and not the riscv64 specific tag.
Thank you for reporting a broken build! Please fill in the following details:
Ref: https://github.com/adoptium/infrastructure/issues/3693#issuecomment-2286200518
This may be related to how the tags are created. We are currently building from tags in the repository, and I suspect that these are being created only from the master branch and not picking up the fixes from the (default) riscv-port branch
Unless we can get suitable tags created with the changes from the riscv-port branch it is likely that these builds will be failing indefinitely.
Noting that @Haroon-Khel's build at https://ci.adoptium.net/job/build-scripts/job/jobs/job/evaluation/job/jobs/job/jdk11u/job/jdk11u-evaluation-linux-riscv64-temurin/40/parameters/ which did not include a tag (so will have built from the default riscv-port branch) succeeded. We have a couple of options:
The first option is potentially a good initial solution to allow the builds to run through, however since it won't be explicitly from an upstream tag we probably wouldn't want to publish it alongside the others since they are not exactly at a tag.