[ https://issues.apache.org/jira/browse/CASSANDRA-17869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17710981#comment-17710981 ]
Ekaterina Dimitrova edited comment on CASSANDRA-17869 at 4/11/23 2:26 PM: -------------------------------------------------------------------------- {quote}Those jobs are complete now. {quote} Thanks! - jvm-dtest-upgrade - the same amount of tests run as in current trunk. I took a look at a few tests and stumbled into simpleUpgradeWithNetworkAndGossipTest for example. It explicitly has a call to [.upgradesToCurrentFrom(v3X)|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTest.java#L37] so it seems the current matrix correctly ignores this call when it sees JDK which is not supported by the respective Cassandra version we are trying to build. But I am thinking we should probably change the method _upgradesToCurrentFrom(version)_ to maybe _upgradesToCurrent()_ or so? And document that the versions we upgrade from are detected based on the JDK version supported or so? Otherwise it looks confusing at the moment. - jvm-dtest - The number of tests run seems close to what we would expect. Test failures: _- org.apache.cassandra.distributed.test.repair.ForceRepairTest.force_ - new timeout I haven't seen recently, we can keep an eye on it whether it was just random _org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.testOutboundConnectionsAreRejectedWhenAuthFails_ - timeout in a class that is known to have failures already. The rest of the failures match what we already know about. was (Author: e.dimitrova): {quote}Those jobs are complete now. {quote} Thanks! - jvm-dtest-upgrade - the same amount of tests run as in current trunk. I took a look at a few tests and stumbled into simpleUpgradeWithNetworkAndGossipTest for example. It explicitly has a call to [.upgradesToCurrentFrom(v3X)|https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/upgrade/UpgradeTest.java#L37] so it seems the current matrix correctly ignores this call when it sees JDK which is not supported by the respective Cassandra version we are trying to build. But I am thinking we should probably change the method _upgradesToCurrentFrom(version)_ to maybe _upgradesToCurrentFrom()_ or so? And document that the versions we upgrade from are detected based on the JDK version supported or so? Otherwise it looks confusing at the moment. - jvm-dtest - The number of tests run seems close to what we would expect. Test failures: _- org.apache.cassandra.distributed.test.repair.ForceRepairTest.force_ - new timeout I haven't seen recently, we can keep an eye on it whether it was just random _org.apache.cassandra.distributed.test.InternodeEncryptionEnforcementTest.testOutboundConnectionsAreRejectedWhenAuthFails_ - timeout in a class that is known to have failures already. The rest of the failures match what we already know about. > Add JDK17 option to cassandra-builds (build-scripts and jenkins dsl) and on > jenkins agents > ------------------------------------------------------------------------------------------ > > Key: CASSANDRA-17869 > URL: https://issues.apache.org/jira/browse/CASSANDRA-17869 > Project: Cassandra > Issue Type: Task > Components: Build > Reporter: Michael Semb Wever > Assignee: Michael Semb Wever > Priority: Normal > Fix For: 5.x > > Time Spent: 2.5h > Remaining Estimate: 0h > > Add JDK17 option to cassandra-builds build-scripts, they only currently > support options {{8}} and {{11}}. > Add JDK17 to the matrix axes in the jenkins dsl. > Ensure JDK17 is installed on all the jenkins agents. -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org