A push becomes a release.
Delivery is the path from a commit to an image the estate can run: git hosting, a build pipeline, a private registry and a package cache. New code starts a build without waiting for a schedule, and a slow line to public package registries no longer stalls it.
What it holds
| Forgejo | git hosting, CI and the private registry in one service |
|---|---|
| Forgejo Actions runner | runs each build in its own containers |
| Pull mirror | a read-only copy of your repository, kept in step |
| Push webhook | starts a build when the mirror gets new code |
| Nexus Repository | a pull-through cache for apt, pip and npm packages |
| Watchtower | moves labelled services to the new image |
What it promises
A push starts a build
When the mirror picks up a new commit, a webhook starts the build straight away. The six-hourly schedule stays as a backstop.
Proved by firing
Every build webhook was checked by firing it and watching a real build start. A webhook that answers with success but starts nothing does not count as working.
Packages fetched once
Builds fetch apt, pip and npm packages through Nexus. The first fetch of a package comes from the public registry; every later one comes from local disk.
Builds still work without it
If the cache is not configured, a build falls back to the public registries. The same project builds on a laptop or in another CI with no change.
What people ask
How long from a push to a build?
The mirror checks your repository every ten minutes, so that is the longest wait. Once it has the commit, the webhook starts the build straight away.
Do we have to move our code to you?
No. Your repository stays where it is. A read-only mirror follows it, and builds work from the mirror.
What if a public package registry is slow or down?
Packages already in the cache come from local disk. Only a package the cache has never seen has to come from upstream, and that happens once.