2.2.0 took three release attempts. Every one of them failed in the kdrant-cli job, on a defect that
any push could have caught, and none of them could be caught before the tag because nothing below the
release workflow ever ran the binary.
The three, in order. kdrant migrate could not create the collection it migrated into, which is true
of every target nobody has made yet and therefore of the whole command. Then the step that proves the
binary called docker on a macOS runner, which has none. Then it worked. A release should not be where
a tool is exercised for the first time.
The gap is exact and small. ArgumentsTest covers the flag parsing and the flags were right;
MigrateTargetTest now covers the target configuration. Neither runs a command. The binary itself is
built on every push through ./gradlew build and then never started.
So this is a CI job rather than a new kind of test: build the binary, start a Qdrant the way the runner
can, and run each command against it. The release workflow already contains that script, which is the
argument for moving it rather than writing it: the same steps belong on every push, and the release
should be the second time they run rather than the first.
Two things to settle while doing it. Whether the job runs on both runners or only on Linux, given a
macOS runner has no Docker and needs the released Qdrant binary instead, and that the release still
proves both. And whether kdrant snapshot restore and the commands M65 adds join it, because a command
covered by nothing is the next one to break in a release.
Exit criterion: a CI job on every push builds the kdrant binary and runs collections, scroll,
migrate and the snapshot round trip against a real Qdrant, and a defect of the kind that stopped
2.2.0 three times fails a pull request rather than a tag.
2.2.0took three release attempts. Every one of them failed in thekdrant-clijob, on a defect thatany push could have caught, and none of them could be caught before the tag because nothing below the
release workflow ever ran the binary.
The three, in order.
kdrant migratecould not create the collection it migrated into, which is trueof every target nobody has made yet and therefore of the whole command. Then the step that proves the
binary called
dockeron a macOS runner, which has none. Then it worked. A release should not be wherea tool is exercised for the first time.
The gap is exact and small.
ArgumentsTestcovers the flag parsing and the flags were right;MigrateTargetTestnow covers the target configuration. Neither runs a command. The binary itself isbuilt on every push through
./gradlew buildand then never started.So this is a CI job rather than a new kind of test: build the binary, start a Qdrant the way the runner
can, and run each command against it. The release workflow already contains that script, which is the
argument for moving it rather than writing it: the same steps belong on every push, and the release
should be the second time they run rather than the first.
Two things to settle while doing it. Whether the job runs on both runners or only on Linux, given a
macOS runner has no Docker and needs the released Qdrant binary instead, and that the release still
proves both. And whether
kdrant snapshot restoreand the commands M65 adds join it, because a commandcovered by nothing is the next one to break in a release.
Exit criterion: a CI job on every push builds the
kdrantbinary and runscollections,scroll,migrateand the snapshot round trip against a real Qdrant, and a defect of the kind that stopped2.2.0three times fails a pull request rather than a tag.