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 [email protected].
> 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 [email protected].
For more options, visit https://groups.google.com/groups/opt_out.