Closed patrikcerbak closed 2 months ago
major idea... Isnt worthy to do a separate backend for this? That would be new module - as is diff and comparator, and it will be new service endpoint. ANy shared code can go t the lib, and the only shared switch is --exact-test
anyway.
When I red the diff, I had issues to identify any reasn why it should stay in the comparator
Thanx a lot for rebasing. Few notes. To add links and texts to tooltip, it may be neough to modify https://github.com/jenkinsci/report-jtreg-plugin/commit/df848f449da197d31c360e8fd65ec78d92093fed#diff-4c0b2eb7d59022ddbf95f75466f335e65d68ad916feabc1d2dae42315960603bR117
please drop https://github.com/jenkinsci/report-jtreg-plugin/commit/df848f449da197d31c360e8fd65ec78d92093fed#diff-4c0b2eb7d59022ddbf95f75466f335e65d68ad916feabc1d2dae42315960603bR99 during implementation of links. It is there jsut for you to see how to use that.
major idea... Isnt worthy to do a separate backend for this? That would be new module - as is diff and comparator, and it will be new service endpoint. ANy shared code can go t the lib, and the only shared switch is
--exact-test
anyway. When I red the diff, I had issues to identify any reasn why it should stay in thecomparator
I can probably do that. I don't think that it would break anything and it should be easy hopefully
Thanx a lot for rebasing. Few notes. To add links and texts to tooltip, it may be neough to modify df848f4#diff-4c0b2eb7d59022ddbf95f75466f335e65d68ad916feabc1d2dae42315960603bR117
please drop df848f4#diff-4c0b2eb7d59022ddbf95f75466f335e65d68ad916feabc1d2dae42315960603bR99 during implementation of links. It is there jsut for you to see how to use that.
ok, I will take a look at that
major idea... Isnt worthy to do a separate backend for this? That would be new module - as is diff and comparator, and it will be new service endpoint. ANy shared code can go t the lib, and the only shared switch is
--exact-test
anyway. When I red the diff, I had issues to identify any reasn why it should stay in thecomparator
I can probably do that. I don't think that it would break anything and it should be easy hopefully
of course you can do that :) But do you agree... do you think it is good idea? I htink yes, but it is just 50% of current project crew :)
major idea... Isnt worthy to do a separate backend for this? That would be new module - as is diff and comparator, and it will be new service endpoint. ANy shared code can go t the lib, and the only shared switch is
--exact-test
anyway. When I red the diff, I had issues to identify any reasn why it should stay in thecomparator
I can probably do that. I don't think that it would break anything and it should be easy hopefully
of course you can do that :) But do you agree... do you think it is good idea? I htink yes, but it is just 50% of current project crew :)
I think it's a good idea, it makes sense to have it separately. If nothing else, then at least the code will be clearer :)
yah, the number of parametters may grow pretty much... unluckily, the haow to compare switches are shared with the comparator, pls, reuse the code. ALso the paarsing of the shared switches should go there.
major idea... Isnt worthy to do a separate backend for this? That would be new module - as is diff and comparator, and it will be new service endpoint. ANy shared code can go t the lib, and the only shared switch is
--exact-test
anyway. When I red the diff, I had issues to identify any reasn why it should stay in thecomparator
I can probably do that. I don't think that it would break anything and it should be easy hopefully
of course you can do that :) But do you agree... do you think it is good idea? I htink yes, but it is just 50% of current project crew :)
I think it's a good idea, it makes sense to have it separately. If nothing else, then at least the code will be clearer :)
The dealing with shared code wil be quite a pain and burden. but afaik still worthy.
yah, the number of parametters may grow pretty much... unluckily, the haow to compare switches are shared with the comparator, pls, reuse the code. ALso the paarsing of the shared switches should go there.
What switches do you mean? There are two, which both use:
--exact-tests
--formatting
So should I move them to lib (even the parsing)?
Yes please. The formatting is that type:howMuch thing?
No, that is another thing, but good catch, it also needs to be moved there.
I meant the --formatting html/color/plain
switch first.
No, that is another thing, but good catch, it also needs to be moved there. I meant the
--formatting html/color/plain
switch first.
And --path, --jenkins-url .. and so on :(
Do you recall how our discussion or removals of parts of the trace ended? HAve we agreed on some --clean-trace replaceRegex:by
argument?
I extracted the common argument parsing (and everything it needs) from comparator to the lib module. I also tried to make the argument parsing object oriented now. Apart from that, I created a new module called TraceDiff with the extracted stack trace diff tool from comparator. Since the service module is not setup yet for this new tool, I haven't created any links yet :(
It can be run by:
java -cp report-jtreg-tracediff/target/report-jtreg-tracediff.jar:\
report-jtreg-lib/target/report-jtreg-lib.jar:\
$HOME/.m2/repository/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar:\
$HOME/.m2/repository/io/github/java-diff-utils/java-diff-utils/4.12/java-diff-utils-4.12.jar \
io.jenkins.plugins.report.jtreg.main.tracediff.TraceDiff \
--path $HOME/.jenkins/jobs --trace-from "jenkins-test-project:210" --trace-to "jenkins-test-project:211" \
--exact-tests "runtime/modules/ModulesSymLink.java#ModulesSymLink" --formatting color --diff-format inline
You had merged in master:( Please do not do that, rebase on top of master.
I extracted the common argument parsing (and everything it needs) from comparator to the lib module. I also tried to make the argument parsing object oriented now. Apart from that, I created a new module called TraceDiff with the extracted stack trace diff tool from comparator. Since the service module is not setup yet for this new tool, I haven't created any links yet :(
It should be easy to enbale the service . Will you, or should I?
java -cp report-jtreg-tracediff/target/report-jtreg-tracediff.jar:\ report-jtreg-lib/target/report-jtreg-lib.jar:\ $HOME/.m2/repository/com/google/code/gson/gson/2.10.1/gson-2.10.1.jar:\ $HOME/.m2/repository/io/github/java-diff-utils/java-diff-utils/4.12/java-diff-utils-4.12.jar \ io.jenkins.plugins.report.jtreg.main.tracediff.TraceDiff \ --path $HOME/.jenkins/jobs --trace-from "jenkins-test-project:210" --trace-to "jenkins-test-project:211" \ --exact-tests "runtime/modules/ModulesSymLink.java#ModulesSymLink" --formatting color --diff-format inline
Thanx! The synax is surprisngly friendly at the end!
Plese add at least one test to th new module.
Even if we push under this name (traceDiff) we have to rename. My idea is:
report-jtreg-comparator -> report-jtreg-comparator
report-jtreg-diff -> report-jtreg-list
report-jtreg-tracediff -> report-jtreg-diff
wdyt? When to do so?
You had merged in master:( Please do not do that, rebase on top of master.
Sorry for that, I didn't notice
I extracted the common argument parsing (and everything it needs) from comparator to the lib module. I also tried to make the argument parsing object oriented now. Apart from that, I created a new module called TraceDiff with the extracted stack trace diff tool from comparator. Since the service module is not setup yet for this new tool, I haven't created any links yet :(
It should be easy to enbale the service . Will you, or should I?
I can try to take a look at that :)
Plese add at least one test to th new module.
ok, will do
Even if we push under this name (traceDiff) we have to rename. My idea is:
report-jtreg-comparator -> report-jtreg-comparator report-jtreg-diff -> report-jtreg-list report-jtreg-tracediff -> report-jtreg-diff
wdyt? When to do so?
I can do that in this PR if you want that
I can try to take a look at that :)
+
I can do that in this PR if you want that
== go for it, at least from scope of renaming the modules and variaous pom artifacts.
Me as downstream, will have a bit of fun with that, but it will be worthy. Also the links pointing to the current diff on hydra will needaadjsut (have we already made them adjsutable? If not, it will be mandatory work to do togehter with traceDiff links)
The name diff is used in the service wrapper scripts, and that will need to follow that too. Also it is used in the service endpint name, ut I'm +1 to fix that sooner rather then later.
So feel free to procedd with reanming up to where you feel safe, and then lts stop, merge, and continue separately.
The renaming of the modules is (hopefully correctly without any problems) done.
Also, the endpoint of the former diff's service was changed from /diff.html
to /list.html
.
Jsut recall me, current "list" is my old tool. Curren report-jtreg-comparator is your new comaprator which can comapre test results and traces. and current diff is the newest module, which is showing the diff between traes. oook?
If so, then lets keep it like that. Its good enough.
Jsut recall me, current "list" is my old tool. Curren report-jtreg-comparator is your new comaprator which can comapre test results and traces. and current diff is the newest module, which is showing the diff between traes. oook?
yes, exactly
ty!
Still work in progress, I need to set the links in the table to this first.
The comparator now supports creating a diff between two stack traces. It can be shown in multiple formats:
There are three new command line switches:
--trace-from jobName:buildNumber
-- for setting the first build--trace-to jobName:buildNumber
-- for setting the second build--diff-format patch/inline/sidebyside
-- for choosing the output format of the diffIt takes the set of tests to create the diff from the
--exact-tests ".*"
argument, so you also need to set it.