-
-
Notifications
You must be signed in to change notification settings - Fork 249
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
Enable reproducible comparing tests on jdk21+ macos #3844
base: master
Are you sure you want to change the base?
Conversation
5dd3e43
to
4e6a29f
Compare
I have tried both static mac and orka. Both no jq installed. https://ci.adoptium.net/view/Test_grinder/job/Grinder/10327/console
Might be easy to install jq on static mac and orka? |
https://ci.adoptium.net/view/Test_grinder/job/Grinder/10427/
Does this mean we can't do reproducing on this environment https://ci.adoptium.net/computer/test-macstadium-macos1014-x64-1/ due to the Xcode version not matching. @steelhead31 ? |
Yup, that machines OS I think is too old for Xcode 15.2, and I think it has to be the same version of Xcode for reproducibility to work, @andrew-m-leonard can confirm this I think :) |
Yes, correct Xcode 15.2 requires MacOS 13.5 minimum : https://developer.apple.com/support/xcode/ |
So we need extra label for macos to ensure the reproducing tests run on correct environment. Ether xcode15.2 or sw.os.osx.13_5. Two Mac static agents wont work for reproducing tests. https://ci.adoptium.net/label/ci.role.test&&hw.arch.x86&&%28sw.os.osx%7C%7Csw.os.mac%29/ Current orka ones are label as xcode15.0.1&&build&&mac&&x64 so can't work for reproducing either. Should we open an issue in infra to see if it's possible to update orka's os version? |
Interesting orka ones with label |
@sophia-guo so the Orka nodes are using Xcode 15.2, the 15.0.1 label has not been changed just because of the hassle involved! should have been called Xcode15 ! |
orka updated with jq rerun adoptium/infrastructure#3593 https://ci.adoptium.net/view/Test_grinder/job/Grinder/10470/console |
parsing issue as SBOM --configure-args value format updated with double quotes. Parsing in mac script also need to update. |
a8cf660
to
524ffcb
Compare
New grinder with latest and label https://ci.adoptium.net/label/ci.role.test&&sw.os.osx&&orka&&hw.arch.x86/ to make sure running on orka https://ci.adoptium.net/view/Test_grinder/job/Grinder/10769/ - waiting |
0bc4005
to
3132741
Compare
Running with orka, issue message complains the Xcode can't be found. Test is running on orka node , which should have Xcode 15.2 available #3844 (comment)
|
@steelhead31 If it's related with how the Xcode installation is checked? #3844 (comment) |
rerun on build orka node https://ci.adoptium.net/label/xcode15.0.1&&build&&mac&&x64/ got different error from running on test orka node https://ci.adoptium.net/label/ci.role.test&&sw.os.osx&&orka&&hw.arch.x86/ https://ci.adoptium.net/view/Test_grinder/job/Grinder/10775/console
|
@sophia-guo I've put some debugging in, and it does appear the script is checking correctly, but not finding an Xcode installation on that Orka node..
|
@sophia-guo I've run a grinder here https://ci.adoptium.net/view/Test_grinder/job/Grinder/10782/console with these labels.. ( borrowed from a build job )
So this issue is down to the orka test nodes not having Xcode installed... I'll take a look at the other issue now |
@sophia-guo I've fixed the issue with the repro script, and it now attempts to build, but its complaining about a missing SPEC.mk file..
@andrew-m-leonard may also be able to help in my absence. See the grinder https://ci.adoptium.net/view/Test_grinder/job/Grinder/10791/console |
ef05815
to
ec43d00
Compare
I have updated the parsing of makejdk_any_platform_args to align with linux. It seems no issue with the arguments. but I got
https://ci.adoptium.net/view/Test_grinder/job/Grinder/10836/consoleFull @andrew-m-leonard any idea about this? I haven't tried to reset SPEC, if reset what should be the correct value SPEC=osx_aarch64 for cross compiling? |
For an OpenJDK make, SPEC is not set, so in reproducible.mk trying unsetting it ? |
5a2bd7f
to
2b72104
Compare
@andrew-m-leonard what should we do with option |
https://ci.adoptium.net/view/Test_grinder/job/Grinder/10922/console @andrew-m-leonard . This is the results by reproduced on arm64 by comparing with repro_compare.sh. Anything wrong? Regarding to run this x64 tests on arm64, I haven't got a good solution for this. Right now we can enable as part of dev.system and set a special rule like dev.system on mac only run on arm64, as there is no other tests in this group right now. But going forward this is not correct. |
@sophia-guo It looks like it's not picking up a good JDK for running the Java compare classes:
|
Signed-off-by: Sophia Guo <sophia.gwf@gmail.com>
Signed-off-by: Sophia Guo <sophia.gwf@gmail.com>
Signed-off-by: Sophia Guo <sophia.gwf@gmail.com>
Signed-off-by: Sophia Guo <sophia.gwf@gmail.com>
Signed-off-by: Sophia Guo <sophia.gwf@gmail.com>
@andrew-m-leonard I don't quite understand this. Source jdk is copied from build https://ci.adoptium.net/job/build-scripts/job/jobs/job/jdk23/job/jdk23-mac-x64-temurin/16/artifact/workspace/target/OpenJDK23U-jdk_x64_mac_hotspot_23_37-ea.tar.gz. We can successfully rebuild the compared one. Both have this issue But the compare results is exactly same as when we use the independent jenkins job (thought it's jdk21) https://ci.adoptium.net/view/ReproducibleBuild/job/jdk21u-mac-x64-temurin_reproduce_compare/74/consoleFull So I'm thinking this might not be issues from test view? |
The problem is occuring invoking "javap" to process the System*.class files, here:
The System*.class will be compiled with the given JDK internal class version, so for jdk-23 that is "67". I would guess the "javap" being picked up off PATH by the test is not jdk-23, so it will not know how to read a jdk-23(67) class file. The reason it works for jdk21u is probably because the test is picking up a jdk-21 jdk in the PATH? To resolve, I think we need to put a copy of the source or target JDK in the PATH, to resolve to a version of "javap" that knows how to process class files of the same internal version. |
For cross compiling issue discussion is here adoptium/TKG#618 |
Enable aarch64_mac https://ci.adoptium.net/view/Test_grinder/job/Grinder/11050/console #3972 Interesting , test will archive the reproduced jdk and compare result. For other platform it's around 260M, but Mac_aarch64 is around 4.57G. Will download to see what's the difference and cause such a large aritfact. Caused by wrong workdir, updated. |
Update all javap with testJDK. Also there are 150 dylib differences, which seems removeMacOSNonComparableData() ( remove the macos dylib non-compararable data) was not called at all. Updated to call removeMacOSNonComparableData() and removeWindowsNonComparableData() before the final patchManifests step. @andrew-m-leonard removeMacOSNonComparableData() get the error, what's the issue here?
https://ci.adoptium.net/view/Test_grinder/job/Grinder/11059/console |
No description provided.