[ 
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335378#comment-17335378
 ] 

Andres de la Peña commented on CASSANDRA-16625:
-----------------------------------------------

{quote}Mmmm shouldn't be the case unless I am missing sthg. If you're not 
dirty-hack looping but using Junit to loop proper everything should be 
correctly isolated and equivalent to looping in sh or ant imo.
{quote}
I have just added your 
[RepeatRunner|https://github.com/apache/cassandra/pull/987/files#diff-3b232ce364185d49c362ae79ed940d43bb9acc2c90d8e996ae1f4bae2d611b35R1]
 to {{ViewTest}} and run:
{code:java}
ant testsome -Dtest.name=org.apache.cassandra.cql3.ViewTest  
-Dtest.methods=testCompoundPartitionKey
{code}
It fails in the second iteration because the driver's session has been closed 
(all runs share the same JVM). Did you manage to make one of these tests work 
with that Junit runner?

As for the bash looping approach, I think we can have a nice performance boost 
if we add a flag to optionally disable [the dependency from the {{build-test}} 
ant target|https://github.com/apache/cassandra/blob/trunk/build.xml#L1504] in 
each loop iteration, provided that we call {{build-test}} before starting the 
loop. That's never going to be as fast as looping inside the same JVM with 
JUnit, of course.

> Add a CircleCI job to run some tests repeatedly
> -----------------------------------------------
>
>                 Key: CASSANDRA-16625
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-16625
>             Project: Cassandra
>          Issue Type: Task
>          Components: CI
>            Reporter: Andres de la Peña
>            Assignee: Andres de la Peña
>            Priority: Normal
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> I think it could be useful to have an optional CircleCI job to run some 
> specific tests n times. That way, tickets could attach CircleCI runs showing 
> that the changes don't make a certain ticket flaky or, conversely, that they 
> fix a flaky test. Doing this systematically should mitigate the risk of 
> introducing new flaky tests, and I guess it would be more convenient and easy 
> to share than running the tests locally or on a private CI system.
> It would also be nice to have something similar in Jenkins, but I'm focusing 
> this ticket on CircleCI because it's available also for non-committers, so 
> assignees can run their tests before setting the tickets as ready for review.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to