[
https://issues.apache.org/jira/browse/CASSANDRA-17939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17615625#comment-17615625
]
Andres de la Peña commented on CASSANDRA-17939:
-----------------------------------------------
[~jmckenzie] thanks for looking into this.
{quote}+1 to junit only; we should be avoiding adding new python tests anyway
at this point. I see you've added repeat python tests as well which I wouldn't
say _no_ to. :)
{quote}
The automatic repetitions are only for JUnit tests. The changes in Python
dtests are just the renaming of the job and the ability to accept multiple
tests. This is done for consistency with the changes in the rest of the test
jobs.
{quote}Locally, you can run the same simple git command
Could we wrap this up in a flag to generate.sh in .circleci, {{generate.sh -d}}
or something to show auto-detected diff tests? Or at least doc how circle
derives it in readme.md so folks can run that themselves locally if they're
curious what tests get picked up and want to perhaps add some more.
First thing that pops for me - this command will (reasonably so) pop up all
tests that differ from upstream {_}including ones that are due to your branch
being stale and needing a rebase{_}, which further adds to the value of "double
check which tests will auto-populate from my branch" as a generate.sh command +
some output to say "hey, if you're seeing more than you expect you may need to
rebase".
{quote}
Yep, I'll do that in a bit. Note that the diff uses the three dot syntax, so it
should compare the current head of the patch branch to its fork point, not to
the head of the base branch. That is, it compares the head of the base branch
to the most recent commit that both the patch branch and the base branch have
in common. The diff should remain unchanged even if there are newer changes on
the base branch.
{quote}I wonder if we should remove the classic utest multiplexer from the
pre-commit workflows and leave it only on the separate workflows
+1 to moving to separate workflows only in favor of the new flow
{quote}
I have renamed the job to {{repeated_ant_test}} so it doesn't get confused with
the regular jobs. I have also removed it from the pre-commit workflows but left
it on the separate workflows. I think that moving it to a new pair of workflows
would add more noise/confussion that just leaving it on the separate workflows.
Those workflows are meant for debugging an/or fixing flakies, so I guess it
makes sense to have the special {{repeated_ant_test}} jobs there. Once we have
specific test jobs for all the available Ant targets we can just remove
{{{}repeated_ant_test{}}}.
> CircleCI: Automatically detect and repeat new or modified JUnit tests
> ---------------------------------------------------------------------
>
> Key: CASSANDRA-17939
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17939
> Project: Cassandra
> Issue Type: Task
> Components: CI
> Reporter: Andres de la Peña
> Priority: Normal
> Fix For: 3.0.x, 3.11.x, 4.0.x, 4.x
>
>
> The purpose of this ticket is adding a new CircleCI job that automatically
> detects new or modified test classes and runs them repeatedly. That way we
> wouldn't need to manually specify those tests with {{.circleci/generate.sh}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
