If you checked SHAs I suspect we would skip 90% of the dtests-jar builds
in CI?
On 29/11/23 9:26, Mick Semb Wever wrote:
On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky <a...@aber.io> wrote:
Hey folks - wanted to raise a separate thread to discuss
publishing of dtest-shaded JARs on release.
Currently, adjacent projects that want to use the jvm-dtest
framework need to build the shaded JARs themselves. This is a
decent amount of work, and is duplicated across each project. This
is mainly relevant for projects like Sidecar and Driver.
Currently, those projects need to clone and build apache/cassandra
themselves, run ant dtest-jar, and move the JAR into the
appropriate place. Different build systems treat local JARs
differently, and the whole process can be a bit complicated. Would
be great to be able to treat these as normal dependencies.
https://issues.apache.org/jira/browse/CASSANDRA-19113
Any objections?
+1
But I am not sure this will save us from having to build the shared
dtest jar for other branches in CI.
Compatibility breakages can come from a combination of changes that
happen in different branches. I'd rather not be only catching these
failures after a release has been made. This is why the python dtests
can do upgrade tests on both latest releases and branch heads.
I am in favour of seeing the jvm-dtest take both approaches, and for
that it requires from published dtest-shaded jars. (Also in favour of
switching python dtests in our CI pipelines to
use VersionSelectionStrategies.BOTH by default).