[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13443081#comment-13443081
]
Uwe Schindler commented on LUCENE-4332:
---------------------------------------
bq. I also agree tests should somehow be rerun with the same seed thru this
thing. maybe the ant task for this can just generate a random seed itself, and
pass that with a -D.
Thats the only way to go. A good old Javascript-<script/> inside ant can do
this. I was thinking about the same for my Jenkins infrastructure. Because
currenty you cannot tell my SDDS Jenkins instance to repeat the same test-run.
I was thinking about a similar thing (parametrizable build that passes a random
master seed to "ant test"). The Groovy code in Jenkins doing the JDK
randomization will do this. I just had no time, but it is on my todo list.
bq. it doesnt hurt anything to set it up in build.xml: though I agree we should
instead use an ivy:cachepath instead of introducing so many third party
dependencies for a task/tool that our actual codebase doesn't rely on.
That is what I am optimg for. The extra test-framework/ivy.xml additions should
not be there and the cachepath used directly "inline mode". -> revert
test-framework/ivy.xml -> add dependency inline to ivy:cachepatch or use a
separate pitest-ivy.xml referenced from cachepath only (not resolve).
bq. Uwe I agree there is some risk, but I think we should set it up in the
build to get started (maybe someone volunteers to run it in a sandbox'ed
jenkins once a week, or whatever).
I would take care of a sandbox. The windows tests on SDDS Jenkins are running
in a VirtualBOX. The Jenkins virtualBOX plugin has some options about
starting/shutting down engines. I would create a minimal Linux VBOX instance
(32 bit, few ram to run tests or like that) and make a virtual harddisk
snapshot. Whenever the pitest runs weekly, Jenkins starts a new instance using
the saved snapshot (which is plain empty clean), runs pitests and then shuts it
down again, loosing all changed data on the virtual disk.
> Integrate PiTest mutation coverage tool into build
> --------------------------------------------------
>
> Key: LUCENE-4332
> URL: https://issues.apache.org/jira/browse/LUCENE-4332
> Project: Lucene - Core
> Issue Type: Improvement
> Affects Versions: 4.1, 5.0
> Reporter: Greg Bowyer
> Assignee: Greg Bowyer
> Labels: build
> Attachments:
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
> LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
>
>
> As discussed briefly on the mailing list, this patch is an attempt to
> integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
