Today every test, build, and publish runs on the operator’s laptop — and only
when someone remembers to run it. Celilo will move that work onto its own
self-hosted forge: a Forgejo module running CI natively, so a merge to main
triggers the publish instead of a human at a terminal. The forge that hosts
Celilo’s code becomes the thing that ships it.
Publish on merge
The publish workflow lives beside the code it releases, at
.forgejo/workflows/publish.yml. It triggers on a release tag, a manual
dispatch, or a main-branch merge, and runs the same celilo publish flow the
operator runs by hand today — no bespoke release pipeline. In practice the job
is bun install && bun run publish -y, or bun run publish --alpha for
PR-branch builds. npm and registry credentials arrive as Forgejo secrets, never
baked into the repo.
Verified before it ships
Pre-merge CI runs the verdaccio-backed integration tests that already exist but
today only run on demand. That includes the consumer-side check — install the
just-published @celilo/cli into a fresh directory and confirm it detects
correctly — so a broken publish is caught in CI rather than by whoever installs
it next.
Events, not just artifacts
When celilo publish finishes inside a workflow, it emits a
publish.npm.<dist-tag>.@celilo/<pkg>@<version> event onto the build bus. CI is
the emitter; downstream consumers — other repos, the beta-promotion flow —
react asynchronously wherever they run. Publishing stops being a dead end and
becomes the start of a chain.