[
https://issues.apache.org/jira/browse/CASSANDRA-16687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17349242#comment-17349242
]
Andres de la Peña commented on CASSANDRA-16687:
-----------------------------------------------
As it's mentioned in the description, supporting Python upgrade dtests is easy,
we only need to add the {{--execute-upgrade-tests}} as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/d5966428453e225510bfc0caa28eb1723dd56ee5].
If I'm right this flag is harmless when the repeated test to be run isn't an
upgrade test.
As for JVM upgrade dtests, it's a bit more complicated because we need the
dtest jars. I can think of multiple ways of doing this:
# Do nothing. If we start the job {{start_jvm_upgrade_tests}} it will call the
job {{j8_dtest_jars_build}}, which will create the jars and add them to the
workspace, making them available for the dtest multiplexer. The downside is
that it forces us to run the entire set of JVM upgrade tests and wait for the
finalization of the {{j8_dtest_jars_build}} job before approving the
{{start_repeated_utest}} job. Of course this isn't very practical.
# Build the dtest jars on each repeated test runner. This would be quite
inefficient because it will build the jars 25 times in the case of MIDRES, and
100 times with HIGHRES.
# Allow to run {{j8_dtest_jars_build}} separately, and make
{{jvm_upgrade_tests}} depend on it, as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/2d1f34a2afc6ceb060e192fd04fa2c5824dfbcad].
That way we don't need to run the the entire set of JVM upgrade tests to run
the multiplexer, but we still need to wait for the finalization of the
{{j8_dtest_jars_build}} job before approving the {{start_repeated_utest}} job
in case we are repeating a JVM upgrade test, which is a bit inconvenient.
# Make the {{repeated_utest}} job depend on {{j8_dtest_jars_build}}, so we can
approve both {{start_repeated_utest}} and {{start_j8_dtest_jars_build}} as soon
as the workflow is created. The downside is that it will build the dtest jars
even if the test to run repeatedly isn't an upgrade one, which is inefficient
and slightly confusing (why do we need to build the dtest jar to run a repeated
utest?).
# Make a separate, specific job for running JVM upgrade tests named
{{repeated-jvm-upgrade-dtest}}, and make it depend on {{j8_dtest_jars_build}},
as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/b9eebd7ec32f38f477dedbd7dea264550986951c].
Also we would add separate env vars for that job, as it's done
[here|https://github.com/apache/cassandra/pull/1016/commits/2fd8415a953f226abc4c8909547774dd3f1dde01].
That is efficient in the sense that the dtest jars are only built once in all
the workflow, and I think that makes the dependencies easy to understand. The
resulting workflow can be seen on [this
run|https://app.circleci.com/pipelines/github/adelapena/cassandra/484/workflows/1604b21f-42fd-487a-a6ef-3561bf82cc55].
I think the approach described in 5. is the right one, even though it requires
an extra click to run the JVM upgrade tests. Any alternative ideas are more
than welcome. It would be super nice to have a way to automatically run the
{{j8_dtest_jars_build}} job only if {{start_jvm_upgrade_tests}} *or*
{{start-repeated-jvm-upgrade-dtest}} are called, but I can't see a way to do so
with CircleCI.
> Support upgrade tests in CircleCI multiplexer
> ---------------------------------------------
>
> Key: CASSANDRA-16687
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16687
> 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
>
> The CircleCI jobs for running a test repeatedly added by CASSANDRA-16625
> don't support upgrade tests. In the case of Python upgrade dtests we only
> need the {{--execute-upgrade-tests}} when calling {{pytest}}. For Java
> upgrade tests we need to build the dtest jars before running the repeated
> tests.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
