-
-
Notifications
You must be signed in to change notification settings - Fork 259
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
Add top-level comparator script #4008
base: master
Are you sure you want to change the base?
Conversation
Thje label is not correct this is cygwin (thus windows) and linux |
Hello good people. Anybody around? The #3991 was closed as duplicate, and there is no duplicate toolchain. All the tools are written, but the readme is quite complex, and one must follow it. In addition there are quite a few corenr cases. This script remains valid contribution, which is putting it all together. I found small intersection with detection of |
needs linter fixes to start with. |
@karianna the linter is all green, but the job never finishes and timeouts:( |
I see: File:[/github/workspace/tooling/compare-builds.sh] |
thanx.I had missed it.Fixed
…--
Mgr. Jiri Vanek
***@***.***
---------- Původní e-mail ----------
Od: Martijn Verburg ***@***.***>
Komu: adoptium/temurin-build ***@***.***>
Kopie: judovana ***@***.***>, Author ***@***.***>
Datum: 10. 11. 2024 3:06:44
Předmět: Re: [adoptium/temurin-build] Added top-level comaprator script (PR
#4008)
"
I see:
File:[/github/workspace/tooling/compare-builds.sh]
2024-11-10 01:46:57 [WARN] Warnings found in [bash-exec] linter!
2024-11-10 01:46:57 [WARN] Error: File:[/github/workspace/tooling/compare-
builds.sh] is not executable
—
Reply to this email directly, view it on GitHub
(#4008 (comment))
, or unsubscribe
(https://github.com/notifications/unsubscribe-auth/AAWFCSZB5U7GIOXAB7YSWHTZ725S3AVCNFSM6AAAAABQS6ZDBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRWGU2DQNRRGI)
.
You are receiving this because you authored the thread. Message ID: <
***@***.***>
"
|
OK so the linter fails on JSCPD, ew have a config file for this, have you tried running locally? |
Even the local the
Is malicious. That code is obviously so nasty it deadlocks the tool. I will decompose it a bit. |
On contrary, when rest of the file is removed, and only "that" code is left in, it is in few ms finsihed. |
No success to narrow it more. Filed kucherenko/jscpd#716 Will redactor the |
Since there is a lot of code here I haven't gone through everything that it has done yet, but can you clarify what the intent of this is and how it is different from the comparison tools we do after attempting a binary rebuild? For example we have the
|
Hi! thanx for reply. I definitely agree that there must be no duplicated code. If any "top level comparator" would just call set, or even only one, function(s) from various shared libraries, it would be ok. I was last checking the state of code in shared libraries, in earl October and all I needed for such code was missing. Maybe it already got better? Primarily, it should be calling the tools from Andrew(which requires some set-up and detection, which it must do too), which are checking not just identical state, but binary comparability - https://github.com/adoptium/temurin-build/blob/master/tooling/reproducible/ReproducibleBuilds.md#comparable-build-tools - optionally, why not. Sometimes you nedd them, sometimes not. As far as I can read it, those are still not called. Maybe there are similar functions already on place, but I do not see them. Quick check:
I found detection of I believe that standalone, reusable script, should be proudly presented, not hidden, and if it exists, it should be called from other work-horses, not the opposite - because the comparison of binary-comparable is standalone and tricky task, and it is super useful for much wider audience. |
Yeah I agree on that. We do have articles about running the stuff we have listed on https://adoptium.net/en-GB/blog/2024/08/adoptium-reproducible-verification-builds/ (and my now a little out of date as things have moved on videos such as this one which talks about the automation we have in place. On the specifics you mention:
|
I meant more via reusable script then via talk/readme:) But this is nice one.
Thanx! I had missed that one. So the script I'm proposing probably can lost some part of logic by calling several functions from various repro_comon (and maybe others, as some are in windows only script and so on). It is quite hard to read.
Yup, thas it, The identical logic is moreover indeed around, but the binary-comaprable logic is not. |
@sxa I just realised I did not asked one clarification: " two separate implementations ". I'm still failing to see the first one. I'm generally reading it, that there are some function, which have duplication inside this script. So if I remove the existing duplicated "bodies" (in this script) and replace them by existing functions, such a script should become acceptable? |
907db52
to
db5edd2
Compare
…hted "only in" files
identical is default
1ea10d7
to
659597a
Compare
I'm only holding off on a full formal review here because I want @andrew-m-leonard to have some input in this and confirm that it doesn't duplicate anything. Adding him as a reviewer. |
I think it currently duplicate detection of windows tools. I have to honestly admit that I gave up that it wille never go in, and was not working on the deduplication on meantime. |
# the result will be changed via tap plugin or jtreg plugin | ||
exit 0 | ||
else | ||
exit ${GLOABL_RESULT} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably ought to spell this?: GLOBAL_RESULT
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ouch. sure!
Linter needs fixing |
It needs more then fixing. The linter is deadlocking - kucherenko/jscpd#716. I will elaborate on it. |
export JAVA_HOME="${JAVA_HOME}" | ||
} | ||
|
||
function tapsAndJunits() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The original plan for this work (before judovana stepped in) was to run it as an AQAvit test target (like the reproducible tests), in which case, we would not want the test to generate TAP files, since TKG takes care of that. I prefer not to add wrapper scripts that duplicate functionality we already have in place, as it means more code to track and maintain. At very least, will need a flag to disable generation of this TAP file. Our Jenkins jobs and monitoring solutions will not 'appreciate' other tap files being present.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The flag is - as on all my PRs - is already there. If not, it would be a mistake I would be more then happy to fix. It is enabled by default, but it is single variable to turn it off. I have absolutely no issues to make it off by default . The script is designed as standalone, so it have to be able to produce some machine readable results better then just return value. But I also agree it should be optional and disabled by default. Will do. I did not stepped in with bad intention. I looked into code and found nothing similar. I'm rally sorry for any intrusion it caused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Off by default for tap files please.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup. Am on it. As jtreg results are generated by freshly cloned clone "https://github.com/rh-openjdk/run-folder-as-tests.git", that will be off by default too.
Hello! I believe the #3991 was closed due to not understanding waht it is doing.
This script is not doing any rebuild, and thus is not comparing on identity, but on binary identically builds only. As it is, it do ot have any similar work present in the toolchain. Can you please reconsider its inclusion?
maybe the in file/main readme:
is misleading?