revapi:check runs on every build via make check, but it has never actually compared anything: the version pattern it uses to resolve a baseline cannot match any version this project has ever published, so the gate passes vacuously.
pom.xml configures the baseline as the newest published release, filtered by a three-part version pattern:
<versionFormat>\d+\.\d+\.\d+</versionFormat>
<oldArtifacts>
<artifact>${project.groupId}:${project.artifactId}:RELEASE</artifact>
</oldArtifacts>Every published com.scylladb:java-driver-core is four-part or -scylla-suffixed: 4.19.0.1, 4.19.0.0, 4.18.1.0, 4.18.0.2, 4.18.0.1, 4.18.0.0, 4.17.0.1, 4.17.0.0, 4.15.0.1, 4.15.0.0, 4.14.1.0, 4.13.0.0, 4.12.0.0, 4.11.1.0, 4.10.0.0, 4.7.2.0, 4.9.0-scylla-1, 4.8.0-scylla-0. None matches \d+\.\d+\.\d+, since versionFormat is anchored against the whole version string. Running with -Drevapi.failOnUnresolvedArtifacts=true makes it explicit:
Failed to find a version of artifact 'com.scylladb:java-driver-core:RELEASE' that would
correspond to an expression '\d+\.\d+\.\d+'. The versions found were: [4.19.2.1, 4.19.2.0,
4.19.0.9, 4.19.0.8, ...]
failOnUnresolvedArtifacts defaults to false, so the plugin warns and completes without an analysis. <revapi.skip>true</revapi.skip> is set only in the fast profile, so CI is not skipping the goal — it is running it against no baseline.
Net effect: binary-compatibility breakages have been merging unchecked for as long as the four-part scheme has been in use, and the ~7,400-line ignore baseline in revapi.json has not been exercised either.
The fix is to widen versionFormat to cover the four-part scheme. Worth doing with eyes open: this activates a gate that has never run, so the first build after the change is likely to surface a substantial backlog of unbaselined breakages that will need triaging into revapi.json (or an explicit, documented decision to reset the baseline at the next release).
Found by @wprzytula while working on a downstream fork; filing here since the configuration is the same on scylla-4.x.
revapi:checkruns on every build viamake check, but it has never actually compared anything: the version pattern it uses to resolve a baseline cannot match any version this project has ever published, so the gate passes vacuously.pom.xmlconfigures the baseline as the newest published release, filtered by a three-part version pattern:Every published
com.scylladb:java-driver-coreis four-part or-scylla-suffixed:4.19.0.1,4.19.0.0,4.18.1.0,4.18.0.2,4.18.0.1,4.18.0.0,4.17.0.1,4.17.0.0,4.15.0.1,4.15.0.0,4.14.1.0,4.13.0.0,4.12.0.0,4.11.1.0,4.10.0.0,4.7.2.0,4.9.0-scylla-1,4.8.0-scylla-0. None matches\d+\.\d+\.\d+, sinceversionFormatis anchored against the whole version string. Running with-Drevapi.failOnUnresolvedArtifacts=truemakes it explicit:failOnUnresolvedArtifactsdefaults tofalse, so the plugin warns and completes without an analysis.<revapi.skip>true</revapi.skip>is set only in thefastprofile, so CI is not skipping the goal — it is running it against no baseline.Net effect: binary-compatibility breakages have been merging unchecked for as long as the four-part scheme has been in use, and the ~7,400-line
ignorebaseline inrevapi.jsonhas not been exercised either.The fix is to widen
versionFormatto cover the four-part scheme. Worth doing with eyes open: this activates a gate that has never run, so the first build after the change is likely to surface a substantial backlog of unbaselined breakages that will need triaging intorevapi.json(or an explicit, documented decision to reset the baseline at the next release).Found by @wprzytula while working on a downstream fork; filing here since the configuration is the same on
scylla-4.x.