-
-
Notifications
You must be signed in to change notification settings - Fork 257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JDK23 Linux reproducible comparing tests failure #3920
Comments
A few comments/questions:
|
FYI I got the same results running the jdk23 job on an Ubuntu 24.04 host in this job, which eliminates the older kernel version on the ubuntu 16.04 machine as the cause of the differences: |
Yes, this is for jdk23, jdk21 I haven't got the chance to rerun due to the centos OEL issue.
I'm working on this #3921 to ignore the debuginfo
Jobs are here https://ci.adoptium.net/view/ReproducibleBuild/, but we didn't enable for jdk22+, as suppose those jobs will be disabled. adoptium/ci-jenkins-pipelines#1093 |
Yeah unfortunately they only have up to jdk21u and you're currently using 23 in the new runs so the output isn't directly comparable (Also the jdk21u for xLinux seems to have been a bit broken on those for a while). It might be worth trying a |
@sophia-guo a couple of things, it seems the /home/jenkins/jdkbinary contains .debuginfo files, however the actual JDK being reproduced (https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk23/job/jdk23-linux-x64-temurin/19/artifact/workspace/target/OpenJDK23U-jdk_x64_linux_hotspot_23_37-ea.tar.gz) does not...? Which makes me think the /home/jenkins/jdkbinary is not what it is supposed to be? I also notice at the end of the console, that other processes are running on the same machine?
Could the /home/jenkins/jdkbinary folder be being populated from one of these other test jobs running on this host? |
@andrew-m-leonard it does appear to be a physical machine with docker installed, it doesn't host any static containers (in the way the dockerhost machines do ) but it does appear to create test containers to run tests dynamically. I wonder if we need a different way to identify machines suitable for reproducible build testing..?, |
There are a number of AQA tests (mostly in the external suite, but some have been added to the It looks like things are working as designed (other than some of the dev test jobs not clearing up after themselves). Note that @sophia-guo has access to that machine for debugging some permissions issues on there at the moment: adoptium/infrastructure#3722
Any machine that is tagged in a way that lets test use docker should be suitable for this, in the same way as they are for the dev and external ones referenced above - they all use the sw.tool.docker label to identify suitable ones. |
This is interesting. /home/jenkins/jdkbinary is the place of the untarred the jdk. The debuginfor comes from debugimage tar. Aqa-test job triggered by upstream will grab all available jar files and untar them including debugimage. https://github.com/adoptium/aqa-tests/blob/master/get.sh#L327-L343 The reason we didn't notice it before is when tests were enabled we use customized jdk ( jdk link and json link). Hence no this problem. Also our former reproducible jenkins jobs are setup to filter the unnecessary files and only grab the jdk and sbom files so no this issue either. So if we don't care about the debuginfo at all https://adoptium.net/docs/reproducible-verification-builds/reproduce-linux-x64/ the easiest way to do is ignore the debuginfo if they are available. https://github.com/adoptium/temurin-build/pull/3921/files#diff-65e4993f80b74f0a4078e853b798cbf6770215b4c31ae1377aa2704eec01ae16R340-R342 @andrew-m-leonard thoughts? As @sxa mentioned that linux reproducible comparison testing are under the category of special system so those leftover processes are other test jobs under same category, but reproducible comparing tests will by no mean be affected by them. |
I don't think we should be changing the reproducible compare logic to cater for whatever extra stuff maybe put into the JDK dir, if get.sh adds other stuff in the future we're back to the same problem. |
@sophia-guo it looks like it is only the debugimage that gets "overlaid" currently, so lets just add the remove logic in reproducible.mk
|
jdk23 linux reproducible comparing test failed with the diff https://ci.adoptium.net/job/Test_openjdk23_hs_special.system_x86-64_linux_testList_0/13/
The text was updated successfully, but these errors were encountered: