apt install celilo is the front door Celilo is building toward — the install
path Linux operators reach for first, with signature verification and
apt upgrade semantics built in. That front door needs a repo behind it, kept
current automatically. The plan: tagging a release in git publishes a fresh
celilo package to apt.celilo.computer with no operator at the keyboard.
The last mile of a release
Publishing the .deb is the final phase of the CI pipeline, and it runs only
after the earlier release stages are in place. When CI builds the package it
emits a “build published” webhook rather than reaching for the apt server
directly. There is deliberately no SSH from the build machine to the repo — the
whole flow stays inside Celilo’s own machinery, authenticated through its secret
store and audited on the event bus.
Webhook to signed index
The webhook lands on celilo-mgr, which downloads the built .deb from the
forge’s artifacts API and invokes the apt_publish capability on the
celilo-apt-repo module. That module drops the file into incoming/, runs
reprepro processincoming, and updates the signed dists/ index. Both arm64
and amd64 ship together from day one. Duplicate or replayed publishes are
harmless — reprepro refuses a version it already has.
Signed, never leaked
The GPG key that signs the repo’s Release file lives in Celilo’s secret store
and never leaves it — CI signs by invoking the apt_publish capability, not by
holding the raw key. The result is a repo an operator can trust the same way
they trust any signed apt source, updated automatically on every tagged release.