[
https://issues.apache.org/jira/browse/CASSANDRA-16625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17334701#comment-17334701
]
Andres de la Peña commented on CASSANDRA-16625:
-----------------------------------------------
[~e.dimitrova] [~bereng] thanks for the feedback. Indeed this is still a work
in progress.
{quote}In general it looks good to me, but we need to update the patch files,
not directly the MIDRES, HIHRES ones. More info on that
[here|https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md].
{quote}
The MIDRES and HIGHRES have actually been generated with the patch files. Those
patch files only modify the executors and, since I haven't done any changes on
them, I think there is no need to modify the patch files. At least they seem to
produce the desired changes in {{config-2_1.yml}}.
{quote}Also, I think it would be nice to update the readme files and the docs
with info about this new option when it is done.
{quote}
I agree. Both
[{{.circleci/readme.md}}|https://github.com/apache/cassandra/blob/trunk/.circleci/readme.md]
and [the section in the documentation for
CircleCI|https://cassandra.apache.org/doc/latest/development/testing.html?highlight=circleci#performance-testing]
seem more focused on how to run with different resources than in describing
the different workflows and jobs, so perhaps they need further work in that
direction. Not sure whether that should be addressed here or in a separate
ticket.
{quote}you could make j11 unit tests not require user approval. I think that's
just a bug on the ci file
{quote}
Good idea, done
[here|https://github.com/adelapena/cassandra/commit/61ba75d405d64d9c1c60f11be554de1b88ecd622]
for the j11 workflow. By the way, I'm not sure why we have j11 jobs in the j8
workflow.
{quote}As per junit tests I would try to avoid the 'count' approach. That is
good for slow tests but for quick tests it's a waste of time. I've had to loop
sometimes 10K times a test programmatically and it would take a minute. If I
had to do that at sh level or start/stop junit 10K times it would take ages
imo. My 2cts.
{quote}
Passing a {{count}} argument to the different flavours of testsome/test-some is
independent on whether we use an ant loop, a Junit runner or, in the future,
Junit 5's {{@RepeatedTest}}. Junit-based solutions would just read that
argument to determine the amount of iterations. I see the performance advantage
of using Junit-based solutions to run the tests in the same JVM. However, it
seems that we have several tests that currently don't work with that approach,
for example {{ScrubTest}}, {{ViewTest}}, {{ReadRepairTest}} or
{{SASIIndexTest}}. I guess we could have both approaches and use the one that
is more adequate for the case at hand.
> 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
>
> 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]
