Added top-level comaprator script

[judovana]

# This is top level script for comparing two jdks.  It 
# This script expects exactly two args - tag:os.arch/dir/archive, two times
# eg: compare_builds.sh  /usr/lib/jvm/java-21-openjdk /my/home/my_custom_tarball.tar.xz
# eg: compare_builds.sh  /my/custom/dir/with_jdk jdk-21.0.4+7:windows.x64
# if the parameter is tag, the temurin jdk of given tag:os.arch is downloaded
# yo can omit the :os.arch part, then it will be guessed... but you may know better
# It copies and creates all in CWD!!!!
# Pass the files/dirs as absolute values, it should not be that hard
# It is useful to have JAVA_HOME pointing to some other JDK used to compile and run supporting files
# otherwise one of the provided JDKs will be duplicated, and used
# for your own safety, do not run it as root
#
# The JDK you are comparing is launched to get various info about itself
# If you need to compare jdks on different platform then they are for, you need to go manually.

[judovana]

I iwll add license header and do the linter exercise once we agree it is desirbale work to go in. TY!

[andrew-m-leonard]

this looks a little odd? "dead" ? why overwrite what is being compared?

[judovana]

The ${DO_BREAK:-}" block is serving to tempt your toolchain a bit. In the moment I saw it claims some buiilds to be comparable, I wanted to modify some parts to see if results are as they should be. At the end I left only this two simple modification as placeholder where to do something like that - or use as it is. I do not have hard feelings to remove it, but it was useful.

[karianna]

linter is upset :-)

[judovana]

linter is upset :-)

Linter is never upset, it just gently reminds!

[andrew-m-leonard]

I'm not sure at the moment we want to add this as another top-level script, which may just complicate things...

[judovana]

Sure. I have no objections to not include this one. But word "another" is interesting. I have not noticed anythig similar around. . I definitely do not want myself, nor anybody else to to keep "supporting" two top level wrappers, but would like to have one which do its job properly. So I would like to adjust the already existing to do what I need, or move workloads which are using the current one to this new one. Can you please pin point me?

[andrew-m-leonard]

Sure. I have no objections to not include this one. But word "another" is interesting. I have not noticed anythig similar around. . I definitely do not want myself, nor anybody else to to keep "supporting" two top level wrappers, but would like to have one which do its job properly. So I would like to adjust the already existing to do what I need, or move workloads which are using the current one to this new one. Can you please pin point me?

So "another" is actually relative to the "top level use case". We already have in this repo the new AQA rebuild tests here for example:

temurin-build/test/system/reproducibleCompare/playlist.xml

Line 22 in 5035fa3

docker run -v "$(TEST_RESROOT):/home/jenkins/test" -w "/home/jenkins/" -v "$(TEST_JDK_HOME):/home/jenkins/jdkbinary/" --name reproducibleCompare centos:7 /bin/bash /home/jenkins/test/linux_repro_build_compare.sh $(SBOM_FILE) /home/jenkins/jdkbinary; \

[smlambert]

I will close this PR as unnecessary/duplicate, especially as we prefer to use our existing approach and leverage existing AQAvit tools such as TRSS when running and monitoring comparisons and reproducible tests.

Also as a reminder, PRs should be related to existing issues which are either in backlog or accepted into a quarterly plan by component owners / PMC / project leads, so we can ensure that we are prioritizing our time and resources well.

[judovana]

Sure. I have no objections to not include this one. But word "another" is interesting. I have not noticed anythig similar around. . I definitely do not want myself, nor anybody else to to keep "supporting" two top level wrappers, but would like to have one which do its job properly. So I would like to adjust the already existing to do what I need, or move workloads which are using the current one to this new one. Can you please pin point me?

So "another" is actually relative to the "top level use case". We already have in this repo the new AQA rebuild tests here for example:

temurin-build/test/system/reproducibleCompare/playlist.xml

Line 22 in 5035fa3

docker run -v "$(TEST_RESROOT):/home/jenkins/test" -w "/home/jenkins/" -v "$(TEST_JDK_HOME):/home/jenkins/jdkbinary/" --name reproducibleCompare centos:7 /bin/bash /home/jenkins/test/linux_repro_build_compare.sh $(SBOM_FILE) /home/jenkins/jdkbinary; \

Yah, I have seen that playlist. It did not seems to be doing what I wanted. I will try to look again.

AQAvit tools such as TRSS when running and monitoring comparisons and reproducible tests.

Sure, but there is absiolutely no reason an testsuite could generate more types of results.

[judovana]

@smlambert Actually one more thing. Three weeks ago I wanted to run compare of one jdk against existing temurins. There was (and afaik still is) nothing which is helping to glue all the parts together to compare existing build against released temurins. Especially under cygwin.
So I wrote it, and it was well standalone be well reusable, tested in cygwin and fedora/rhel. So I have naturally offered it back to the project from which the individual parts, and a pretty long readme (which do not mention any top level wrapper) come from (I have searched for that, and found the playlists, and they do not supply what I needed). So I'm wondering, why it is so hard for you to be at least semi-welcoming, and jsut write. "sorry this is duplicated with already existing toolchain". And even better, to enhance readme how to use that if it is alrerady existing. Also I'm wondering why one needs a PMC/governing board/whatever agreement, to contribute already existing, simple script. Which dont take any time of your people. Except review which would not be that hard considering it is jsut top level glue only. And if so, then it can always go on hold.

[judovana]

here you go, #3998 hopefully it will pass through component owners / PMC / project leads