JAVA-2622: Add Cassandra 4.0 to build matrix for ITs#1390
Conversation
adutra
left a comment
There was a problem hiding this comment.
LGTM but for some reason this branch is not showing up on our internal CI, could you investigate please?
7fc68b6 to
0b94023
Compare
| if (version.getMajor() == 4 | ||
| && version.getMinor() == 0 | ||
| && version.getPatch() == 0 | ||
| && version.getPreReleaseLabels() != null) { |
There was a problem hiding this comment.
This check is specifically to catch a Version object for something like 4.0-alpha2. When you use Version.parse(String), it sets the patch value to 0 if not specified.
Passing a string of "4.0-alpha2" yields a major of 4, minor of 0, patch of 0 and preRelease of "alpha2". Version.toString() always appends the patch version to the String. So if you parse "4.0-alpha2", the toString() method returns "4.0.0-alpha2". The way CCM is installed on the Jenkins images, it looks for a released version of CCM, or a tagged pre-release version. So the ccm create command for C* 4.0 pre-release builds needs to specify -v 4.0-alpha2, not -v 4.0.0-alpha2.
This seemed to be the easiest way to accommodate this quirk as once C* 4.0 is released, it should be available as 4.0.0 and Version.parse(String) and Version.toString() on that will work like it has been. I didn't want to mess with the Version class as making the patch version optional would cause all kinds of parsing headaches considering we already have a dsePatch version that is optional (i.e. 2.0.1.1 vs 2.0.1).
TL;DR; If the Version object is 4.0.0 and has at least 1 preRelease tag, CcmBridge will cut out the patch version for the String it uses to build the CCM command.
There was a problem hiding this comment.
Why didn't we have the problem so far with versions such as 3.0, 3.11, etc? Maybe the Jenkins images were called 3.0.0 and 3.11.0? I don't mind special-casing 4.0 but I would like to understand why we need to do this now.
There was a problem hiding this comment.
Yes, that is correct. For Cassandra versions, Jenkins images have access to the ones here: http://repomirror.datastax.lan/apache/cassandra/. If the version string doesn't match one of those, CCM will try to clone down a branch or tag that matches the version string. For whatever reason, Cassandra tags the 4.0 pre-releases without a patch version.
I suppose it is possible to store off 4.0-alpha2 as 4.0.0-alpha2 in that repository above, but I think the other drivers are doing something similar to this approach currently.
Going forward, I expect Cassandra 4.0 to resolve to 4.0.0, or 4.0.x where x is the latest available patch release, which is exactly what happens with our builds when the matrix specifies 3.0 or 3.11. And once Cassandra 4.0 releases have a patch version in the number scheme, this special casing won't be hit.
No description provided.