I'd like us to invest in unit tests and make them the contract guards.
>
Thank you Jacek.
In the end, I feel we strayed off the topic a bit - my question was quite
> concrete - I'd like to remove the CASSANDRA_USE_JDK11 knob for CCM - it
> should set it appropriately for Cassandra 4 so that the
Hi,
+1 on CCM not using CASSANDRA_USE_JDK11 to pick a JDK version. I don’t think
it’s a good interface for expressing what JDK CCM should use. I checked and I
don’t see it being used in the dtests, so it shouldn’t break anything? I am not
sure what it was added for.
Cleaning up CCM so it only
BTW. I've created a simple workflow for GitHub Actions -
https://github.com/riptano/ccm/pull/771 - feel free to review
- - -- --- - -
Jacek Lewandowski
sob., 25 maj 2024 o 06:09 Jacek Lewandowski
napisał(a):
> Thank you for all the opinions. That is useful for future w
Thank you for all the opinions. That is useful for future work on CCM.
When I implemented the changes that caused recent headaches, I wasn't aware
that the CCM code was so patchworked, which resulted in many surprises. I
apologize for that. Anyway, there is no reason to sit and complain instead
of
> The scripts that are in cassandra-builds seem like a starting point for
> converging different CI systems so that they run the same set of tests in as
> similar environments as possible
Yeah, I took a superset of circle and ASF tests to try and run :allthethings:.
Part of how the checkstyle de
Hi,
There is definitely a mismatch between how the full range of dtests work and
the direction CCM is going in and we have some difficulty getting those to
match. I fully empathize with several of those CI systems not being publicly
visible/accessible, and the behavior of upgrade paths being ab
Agree with Mick on the revert, and agree w/you Jacek on this area needing to be
cleaned up.
I'm just as irritated as anyone about how archaic and hard to trace our CI
system is (trust me. The last 9 months has been... challenging), but with
things like this that are effectively API's, the blast
>
> When starting Cassandra nodes, CCM uses the current env Java distribution
> (defined by the JAVA_HOME env variable). This behavior is overridden in
> three cases:
>
> - Java version is not supported by the selected Cassandra distribution -
> in which case, CCM looks for supported Java distribut
Hi,
When starting Cassandra nodes, CCM uses the current env Java distribution
(defined by the JAVA_HOME env variable). This behavior is overridden in
three cases:
- Java version is not supported by the selected Cassandra distribution - in
which case, CCM looks for supported Java distribution acro
