GitOps & Build Infrastructure

The pieces that have to exist in your cluster before a pull request can build and deploy itself — a node pool for builds, object storage for build artifacts, Argo CI for pipelines, and Argo CD for GitOps delivery. This page explains what each one is for and the order they go in.

Want the click-by-click version instead? Follow Set Up Argo CI/CD End to End — the same material as a walkthrough, from an empty cluster to a pull request that builds and deploys itself.

What you are building

Routes B and C run your builds as real pipelines inside your own cluster. Nothing leaves your account: your source is cloned, your image is built and pushed to your registry, and SeaGit deploys the result. To make that possible, the cluster needs four things installed once.

YOUR CLUSTER

  ┌─ builds node pool ─────────────────────────────┐
  │  dedicated nodes where build pods run          │
  │                                                │
  │   MinIO ──────── stores build artifacts/logs   │
  │   Argo CI ────── runs the build pipelines      │
  │   Argo CD ────── GitOps delivery (optional)    │
  └────────────────────────────────────────────────┘
            ▲                            │
            │ trigger                    │ build result
            │                            ▼
   SeaGit GitHub App            SeaGit deploys · preview URL
                                promote · rollback · PR status

Install order matters: the node pool first (so build pods have somewhere to land), then MinIO (Argo CI will not install without artifact storage), then Argo CI, then Argo CD if you want it.

The four pieces

1. A node pool for builds

Builds are bursty and hungry: they spike CPU for a minute or two, then disappear. Running them on the same nodes as your applications means a busy build can starve a running app, and a full application pool leaves builds stuck Pending with nowhere to schedule.

Add a custom node pool on your cluster — commonly named builds — and let it scale from zero. Both Argo CI and Argo CD ask for a Workflow Node Pool at install time; pointing them at this pool keeps build load off your application nodes and lets the pool shrink back to nothing between builds.

2. MinIO — artifact storage

MinIO is an S3-compatible object store that runs inside your own Kubernetes cluster. Argo CI needs somewhere to put what a pipeline produces — build logs, caches, and artifacts passed between steps — and MinIO keeps all of it in your account rather than in a third-party service.

This is a hard prerequisite. Installing Argo CI without artifact storage is rejected with MinIO needs to get installed first! — the install does not start. The one exception: if you supply your own S3 bucket in Argo CI's Artifact Storage settings, that satisfies the requirement and MinIO is not needed.

MinIO is not available on the Free plan, and distributed mode requires a Startup plan or above. On Free, bring your own S3 bucket instead.

3. Argo CI — the build pipelines

Argo CI (Argo Workflows) is what actually builds your code. It installs a workflow engine plus a webhook endpoint into your cluster, and ships a default pipeline that clones your repository, builds your Dockerfile, pushes the image to your registry, and reports the result back to SeaGit — so a repository with no pipeline file of its own still builds correctly.

Repositories that need more — tests, linting, scanning, multiple steps — can define their own pipeline in the repository and Argo CI will run that instead.

4. Argo CD — GitOps delivery (optional)

Argo CD continuously reconciles what is running in your cluster against what is declared in Git — the GitOps workflow in its strictest form. It is optional: SeaGit deploys your applications for you either way. Add it when you want a Git repository to be the source of truth for cluster state — your own manifests, third-party components, or anything you manage outside SeaGit's application model.

It installs independently of Argo CI and has no MinIO requirement.

What Argo CI asks for

Most of the install form is references to things you connect once under Providers. Set those up first and the install itself is a two-minute job.

Field	What it is
Github Provider	The credentials the pipeline uses to clone your repository.
Docker Registry	Where built images are pushed. Choose `ECR` to push into the AWS account behind the cluster, or connect another registry provider.
Webhook Password (Provider)	A token/API-key provider holding the shared secret that authenticates incoming build events, so nobody else can trigger your pipelines.
Seagit API Key (Provider)	A provider holding a SeaGit API key. It is injected into the Argo namespaces as a Kubernetes Secret so finished builds can report their result back to SeaGit. Without it, builds run but SeaGit never hears the outcome — the deployment stays queued.
Workflow Node Pool	The node pool build pods are scheduled onto. Leave it as Any Node in the cluster only if you have no dedicated pool.
Host Name and Webhook Host Name	Public hostnames on one of your domains — typically `argoci.your-domain` for the pipeline dashboard and `argohook.your-domain` for the endpoint that receives build events.
Artifact Storage	Leave unset to use the MinIO you installed, or point it at your own S3 bucket.

💡 When you create a SeaGit API key you can tick “Store API Key as Provider credentials?” and the provider is created for you — ready to pick in this form.

Connecting it to an environment

Installing Argo CI makes a cluster capable of building. An environment then has to be told to use it — that is what turns a pull request into a build.

Open the environment, go to its Build Servers settings, and add one:

Type: Argo Workflows — then pick the Cluster that has Argo CI installed. Only clusters with the add-on appear in the list.
Type: Custom — for Route D, where your own CI builds and reports back. Name your system and select the webhook provider holding its credentials.

An environment can have more than one build server, and applications deployed into that environment inherit these settings. A repository can override the choice with a .seagit file if different services need different build paths.

How do I know it worked?

After all three add-ons report applied, three things should be true:

The Argo CI dashboard answers on the host name you chose, over HTTPS with a valid certificate.
Your builds node pool scales up when a build runs and back down when it finishes.
A pull request on a connected repository shows three SeaGit status checks — Dispatch, Build (CI), and Deployment (CD).

If a build never starts, the usual cause is the environment having no build server attached, or the pull request's branch not matching the branch pattern on your application instance. The setup guide's troubleshooting section lists the failure signatures and their fixes.

Frequently Asked Questions

What is a GitOps workflow?

A GitOps workflow makes a Git repository the source of truth for what runs in your cluster: you change Git, and a controller reconciles the cluster to match rather than anyone applying changes by hand. Argo CD is the component that performs that reconciliation. On SeaGit it is optional — SeaGit deploys your applications either way — and you add it when you want your own manifests, third-party components, or anything outside SeaGit application model driven from Git.

What is the difference between Argo CI and Argo CD?

Argo CI (Argo Workflows) runs build pipelines: it clones your repository, builds the image, pushes it to your registry, and reports the result. Argo CD does continuous delivery: it reconciles running cluster state against what is declared in Git. They install independently — Argo CI requires artifact storage such as MinIO, Argo CD does not — and you can run either without the other.

Why does Argo CI need MinIO?

Argo CI needs somewhere to store what a pipeline produces — build logs, caches, and artifacts passed between steps. MinIO provides that as an S3-compatible object store running inside your own cluster, so build data stays in your account. The requirement is enforced at install time: without MinIO applied, or an S3 bucket set in Argo CI Artifact Storage settings, the install is refused with "MinIO needs to get installed first!".

Do I need a separate node pool for builds?

It is strongly recommended. Builds are bursty — they spike CPU for a minute or two, then disappear — so running them on your application nodes lets a busy build starve a running app, and a full application pool leaves build pods stuck Pending with nowhere to schedule. A custom pool, commonly named builds, isolates that load and can scale back to nothing between builds. Both Argo CI and Argo CD ask which node pool to schedule onto.