I love the idea of David to make this dual config stuff directly the part
of the tests, I just leave this here where I quickly put some super
primitive runner together
https://github.com/smiklosovic/cassandra/commit/693803772218b52c424491b826c704811d606a31
We could just run by default with one co
>
> Perhaps this was needed during j17 stabilization but is no longer required?
No, I only switched from tests running J8+J11 to tests running J11+J17.
What we tested was something decided in the 4.0 era when JDK11 was added,
and I was not even part of the community yet :-)
> Any known java-relat
This thread got large quick, yay!
>> is there a reason all guardrails and reliability (aka repair retries)
>> configs are off by default? They are off by default in the normal config
>> for backwards compatibility reasons, but if we are defining a config saying
>> what we recommend, we should
This goes back to what I was talking about previously, we might even run
tests for both j11 and j17 e.g. in Circle _but only on a selected set of
tests_ where there is some kind of a "tension" between the code and Java
version, whatever it means. Like Chronicle queues or BTrees etc, I merely
remebe
For the sake of argument, if we picked one, would you (anyone, not just
Stefan) be OK with the JVM that's selected being the one you don't use?
I'm willing to bet most folks will have a preference for the JVM they run
in production. I think both should be run on some frequent basis but I can
defin
I don't think there is as simple a way to identify those since there
are many ways you can specify a single token.
Kind Regards,
Brandon
On Thu, Feb 15, 2024 at 11:45 AM Jacek Lewandowski
wrote:
>
> Brandon, that should be doable with the current filters I think - that is,
> select only those
Only requiring building on supported JDKs and running all tests only on a
pre-defined version is definitely an improvement in terms of build time.
Building it is cheap, one worker and 5 minutes.
As I already said, just want to reiterate that, instead of _running with
all Java's_ we might run with
Brandon, that should be doable with the current filters I think - that is,
select only those tests which do not support vnodes. Do you know about such
in-jvm dtests as well?
- - -- --- - -
Jacek Lewandowski
czw., 15 lut 2024 o 18:21 Brandon Williams napisał(a):
> On Th
On Thu, Feb 15, 2024 at 1:10 AM Jacek Lewandowski
wrote:
> For dtests we have vnodes/no-vnodes, offheap/onheap, and nothing about other
> stuff. To me running no-vnodes makes no sense because no-vnodes is just a
> special case of vnodes=1. On the other hand offheap/onheap buffers could be
> tes
Great summary Josh,
>
>- JDK-based test suites on highest supported jdk using other config
>
> Do you mean a smoke test suite by that ^ ?
- - -- --- - -
Jacek Lewandowski
czw., 15 lut 2024 o 18:12 Josh McKenzie napisał(a):
> Would it make sense to only block commi
> Would it make sense to only block commits on the test strategy you've listed,
> and shift the entire massive test suite to post-commit?
> Lots and lots of other emails
;)
There's an interesting broad question of: What config do we consider
"recommended" going forward, the "conservative" (i.
Would it make sense to only block commits on the test strategy you've
listed, and shift the entire massive test suite to post-commit? If there
really is only a small % of times the entire suite is useful this seems
like it could unblock the dev cycle but still have the benefit of the full
test sui
Paulo:
> 1) Will cassandra.yaml remain the default test config? Is the plan moving
> forward to require green CI for both configurations on pre-commit, or
> pre-release?
The plan is to ensure both configurations are green pre-commit. This should
not increase the CI cost as this replaces extra con
> It's also been questioned about why we don't just enable settings we
recommend. These are settings we recommend for new clusters. *Our
existing cassandra.yaml needs to be tailored for existing clusters being
upgraded, where we are very conservative about changing defaults.*
I think this unnece
On reducing circle ci usage during dev while iterating, not with the
intention to replace the pre-commit CI (yet), we could do away with
testing only dtests, jvm-dtests, units and cqlsh for a _single_
configuration imo. That would greatly reduce usage. I hacked it quickly
here for illustration
On the merging failing tests discussion I _do_ spend the time looking if
my patch did cause them or not and I certainly enforce that in the
reviews I do. The current failures are a manageable number to check
against Butler/Jenkins/Circle/Jira so I was under the impression
everybody else was als
> Mick and Ekaterina (and everyone really) - any thoughts on what test
> coverage, if any, we should commit to for this new configuration?
> Acknowledging that we already have *a lot* of CI that we run.
>
Branimir in this patch has already done some basic cleanup of test
variations, so this is n
17 matches
Mail list logo
