Shipr
Shipr is where you deploy. You register the repositories you develop and the repositories that deploy them, connect the platforms they ship to, and move each one up a ladder of environments: testing, then staging. Production is the last rung, and it is yours to promote by hand.
You open Shipr from a workspace, at /<workspace>/shipr. It is for signed-in people only, and it has no public page.
Topics
- What Shipr holds: the registry of repositories and the log of runs, and the ladder.
- Permissions: who may read, deploy, register and unregister.
- Production: the one step nobody takes but you.
What you do in Shipr, a program can do over the API: register and manage repositories, keep connections and organization defaults, start a run, read its log and cancel it.
Repositories are under the shipr tag: list, create, read, change and remove, plus a repository's persona and its platforms. One call registers a repository from its remote. Groups are plain resources.
Connections and organization defaults are listed, read, changed and removed under the same tag.
Runs are started, listed and read. A run can be cancelled, and its event log can be read. Live feeds of all runs, and of one run, are for a signed-in session only.
How a run behaves. A run claims its row so that two runner processes never take the same one. A failed run is retried, up to a fixed number of attempts. A group's repositories are processed one at a time, in order. Every call to GitHub mints a token for that call alone, and the token is redacted from every event. The verify command in a repository's configuration is the owner's to run and is never run on the server. The runner is switched on by a setting on the backend.
The full list of routes, with each one's parameters, body and responses, is the REST reference on the help site. The tools an agent gets, across the hub, are listed in the MCP reference.
Git is the state. The database holds only what cannot be read from git: who registered what, which connection reaches which repository and what each run did. What a repository is at is read live from git and only cached.
Never force-push. Commits move between rungs through bare mirrors with plain pushes, so a run can never erase history on a rung.
One at a time within a group. The repositories in a group depend on each other, so a group's run takes them in order.
A run has a person. A token with nobody behind it, or with no scope, is refused, so the record of every deployment names who started it.
The owner deploys production. Every pipeline stops at staging, and the step to production is taken by hand.