A kernel driver that tests and ships itself
Code that sits in the write path of a production disk is only as trustworthy as the machinery that proves it before it reaches you. Every commit to the ShadowCradle Linux snapshot driver is linted, compiled against four distribution families and two architectures, booted on eleven kernel versions inside throwaway VMs, run through 151 correctness assertions, and packaged for five distribution formats — without a human deciding which kernels to cover or whether it was good enough to ship.
All of it is public. The pipeline definition, the test harness, the kernel matrix and the results are in the same GPL-licensed repository as the driver itself, so none of what follows has to be taken on trust.
Six stages, from commit to signed release
Each stage exists because a specific class of bug escaped an earlier one. They run in order, and a red stage stops everything downstream — a package is never built from a commit whose tests did not pass.
What happens when a new kernel ships
This is the question that decides whether a block driver is a liability. The Linux block layer changes between releases, and a driver hooked into it breaks quietly when it does. Our answer is that nobody has to notice: a scheduled pipeline asks upstream what exists, fetches it, builds it and boots it, and turns red on its own if the new kernel broke us.
Five suites, in increasing realism
A backup product that loses data quietly is worse than no backup product, so the suites are built around the quiet failures specifically: not "did it work", but "what did it do when the power went out halfway through".
Deployment is a build artifact, not a procedure
Every format below is produced by the same pipeline run, from the same commit that passed the tests, inside the distribution container it targets. Tagging a release attaches the published URLs to the tag; there is no step in which somebody uploads a build from a laptop.
On a managed ShadowCradle appliance none of this is your problem — the agent carries the driver and DKMS rebuilds it when the host kernel is upgraded. The artifacts exist so that you can install, inspect and reproduce it independently of us if you ever want to.