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).

Reply via email to