yusufipek
156d8bf8e8
Enabling immutable releases, configuring the dependency-release environment, which order the two dispatch runs go in, and which five constants have to move together were all in the pull request description, which is not a place anybody looks a year later. The same file says what this costs: the pinned digest means a backend update is a Dikte release, and the build is deterministic between two runs of one builder rather than across time, because the apt metadata behind the pinned packages is not pinned and LunarG drops superseded ones. Both are worth knowing before the next version bump, not during it. The README keeps a clause instead of the paragraph it had grown.
The Vulkan whisper-server bundle
whisper.cpp publishes a CPU-only archive for Linux, so the graphics card on a
Linux machine is out of reach through the Download button. This directory
builds the archive upstream does not: whisper-server with a dynamic Vulkan
backend next to the CPU ones, for x86_64, against the Ubuntu 22.04 runtime
contract.
It is published as a release of Dikte's own, whisper.cpp-v<version>, marked
as a prerelease and kept off Latest so that neither the update check nor the
download page picks it up. dikte/ggml.py fetches it by tag and installs it
only when the archive's digest is the reviewed one; anything else falls back
to upstream's CPU archive, and the settings window says when it did.
Publishing a new bundle
- Enable GitHub's immutable releases setting for the repository, and give the
dependency-releaseenvironment a required reviewer. Both are repository settings, not something this workflow can do for itself. - Run whisper.cpp Vulkan bundle on
masterwith the new version and its peeled commit,expected_sha256empty andpublish: false. The run builds the archive and reports its digest; without a reviewed digest it refuses to publish, which is what the first run is for. - Review that digest against a build of your own, then run the workflow again
with the same version and commit,
expected_sha256set to it, andpublish: true. Approve the environment when it asks. - Write the same version, tag and digest into
MANAGED_WHISPER_RELEASE,MANAGED_WHISPER_VERSIONandMANAGED_WHISPER_SHA256indikte/ggml.py, and intoREVIEWED_WHISPER_VERSIONandREVIEWED_WHISPER_SHA256in the workflow.tests/test_packaging.pyholds the two sides together. - Ship a Dikte release. Until one goes out, nobody's Dikte knows the new bundle exists.
What this costs, and what it does not promise
The digest lives in Dikte's source, so a backend update is a Dikte release. Linux x86_64 machines with a Vulkan loader stay on the pinned whisper.cpp version until step 5 happens, while every other platform follows upstream's newest release on its own. That is the deliberate trade: an executable Dikte downloads is not allowed to change without a reviewed digest behind it.
The build is deterministic between two runs of the same builder, not across time. The base image, the CMake tarball, the LunarG packages and the direct apt packages are pinned by digest or version, but the Ubuntu and LunarG repository metadata behind them is not, and LunarG drops superseded packages. A rebuild months later can fail to resolve, or resolve to something that produces a different digest. Treat the published archive as the artifact, not as something reproducible on demand: a version bump means building, validating, reviewing the new digest and updating the pinned tuple together.