Build & Deploy Routes
SeaGit gives you four ways to get a code change from your repository to a running deployment. They differ in who triggers and who runs the build — but they all end the same way: SeaGit deploys and manages the result. This page explains what each route means so you can pick the right one.
At a Glance
code change (push / pull request)
ROUTE A — SeaGit Primary (Direct/Embedded)
change ─▶ SeaGit ─▶ build job runs directly in your cluster ─▶ SeaGit deploys
ROUTE B — Argo Workflows / CI (argoci), via SeaGit
change ─▶ SeaGit GitHub App ─▶ SeaGit routing ─▶ argoci pipeline (your cluster) ─▶ SeaGit deploys
ROUTE C — Direct via your own argoci webhook (you own the trigger)
change ─▶ your argoci webhook ─▶ argoci default workflow
└─(build signals + deploy acknowledgement)─▶ SeaGit deploys
ROUTE D — Your CI, via SeaGit
change ─▶ SeaGit GitHub App ─▶ SeaGit routing ─▶ your CI system
└─(acknowledgement)─▶ SeaGit deploys
build signals + deployment acks are sent to SeaGit Signals → signals.seagit.com
── every route ends here ──▶ SeaGit deploys & manages:
preview URL · promote to production · rollback · status on the PRWhichever route you choose, deployment management is identical — previews, promotion, rollback, and pull-request status all work the same way.
The Four Routes
Route A — SeaGit Primary (Direct/Embedded)
The simplest option. A direct build job runs right in your cluster and is automatically hooked up to SeaGit's services — no extra moving parts. You connect your repository and SeaGit does the rest: it detects the change, builds in your cluster, and deploys.
Choose this when: you want the shortest, most hands-off path from a code change to a running app.
Route B — Argo Workflows / CI (argoci), via SeaGit
Builds run as full pipelines (Argo Workflows, provided by the argoci add-on) inside your cluster. The trigger comes through the SeaGit GitHub App, and SeaGit's dispatcher and routing services decide what to build and send it to the pipeline. You get richer builds — tests, checks, multiple steps — fully orchestrated by SeaGit.
Choose this when: you want managed, multi-step pipelines in your own cluster without wiring the triggering yourself.
Route C — Direct via your own argoci webhook
You connect your repository directly to your own argoci webhook — SeaGit is not in the trigger path. You stay fully in control of when and how builds run. The default workflow shipped with the argoci add-on still keeps you integrated with SeaGit: it sends build signals as the build starts and finishes, and a deployment acknowledgement when it's done. That hands the result to SeaGit so you keep preview URLs, promotion, rollback, and pull-request status — even though SeaGit didn't trigger the build.
Choose this when: you want to own the trigger and build pipeline, but still use SeaGit to deploy and manage releases.
Route D — Your CI, via SeaGit
Everything flows through the SeaGit GitHub App and SeaGit's routing services, which hand the build off to your own CI system. Your CI builds the release and reports back with an acknowledgement, and SeaGit deploys it. Your existing CI keeps doing the building; SeaGit handles routing and deployment.
Choose this when: you have an established CI you want to keep, fully integrated through SeaGit.
How the Routes Stay Connected
Every route talks to SeaGit Signals — the public integration endpoint at https://signals.seagit.com — using two lightweight calls that keep your builds and deployments in sync with SeaGit, no matter who runs the build:
- Build signals
POST /builds/start— your build tells SeaGit when it starts and whether it succeeded or failed, so SeaGit can show progress and decide whether to deploy. - Deployment acknowledgement
POST /deployments/{id}/ack— once a deployment finishes, SeaGit confirms the outcome back on your pull request (status check + summary with a link to the live environment).
In Routes A, B, and D these calls are wired automatically. In Route C they are already built into the default workflow that ships with the argoci add-on — so a direct setup stays fully integrated with signals.seagit.com out of the box, with nothing extra to configure.
Which Route Is Right for You?
| If you want… | Route |
|---|---|
| The simplest, fully automatic setup | A — Embedded |
| Managed multi-step pipelines in your cluster, triggered for you | B — Argo Workflows/CI via SeaGit |
| To own the trigger & pipeline, but still deploy with SeaGit | C — Direct Argo Workflows/CI webhook |
| To keep your existing CI, integrated through SeaGit | D — Your CI via SeaGit |