On 08/12/2013 02:58 PM, ogondza wrote:
> Thanks for the feedback. I guess we agreed that it would be an
> interesting feature for core provided we can implement it in a
> reasonably efficient way.
>
> @kpfleming: We can do better than re-runing JUnitResultArchiver. I have
> modified the parser to update result object incrementally in order _not_
> to parse the same report files over and over again. My draft invokes
> parsing JIT (but it is blocking the UI thread which probably could be
> eliminated using ajax) so there is no parsing as long as no one wants to
> see the results. Possible improvement we might be interested in is
> spinning a thread on slave to monitor new report files and push updates
> to master when there is something new (no polling on master, no polling
> over network). I did not find a way to eliminate polling altogether
> preserving all the flexibility JUnitResultArchiver provides, though.
>
> Testing on remote slave is actually faster than I expected. Refreshing
> test results takes ~5 seconds when building jenkins.
>
> @Roman: This filesystem based approach will cover your use case as well.
It will be great.
Could I help in achieving this?
Thanks,
Roman
>
> Here is what I have: https://github.com/jenkinsci/jenkins/pull/904
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
