gocdnext

Webhook-first CI with the deployment + observability seam built-in.

What is gocdnext?

gocdnext is a CI/CD orchestrator that takes the parts of GoCD, Drone, Woodpecker and GitHub Actions that worked, drops the parts that didn’t, and puts them in one binary. Pipelines live in .gocdnext/ next to your code. Webhooks turn pushes into runs. Plugins are containers with a tiny manifest. Logs are partitioned and archivable. The control plane and the runner agent each ship as a single Go binary.

Dashboard

Single Helm install

Server, agent, web UI, postgres-dev, runner profiles — all wired via one chart. Auth, retention, log archive, plugin catalog all surface as values.yaml knobs.

Pipelines as code

.gocdnext/<name>.yaml per pipeline. Webhook-on-push creates a run, fanout from materials.upstream chains pipelines, manual triggers are one click.

Plugins are containers

uses: ghcr.io/klinux/gocdnext-plugin-go@v1 is a thin shim image. The official catalog ships 39+ plugins; your own land in extraPlugins: of values.yaml — no PR required.

Anti-Woodpecker logs

log_lines is RANGE-partitioned by month, batched bulk-inserted, and (opt-in) cold-archived to S3/GCS so the database stays lean even at hundreds of jobs/hour.

A look around

Run detail with live logs Run detail — Jobs / Tests / Artifacts tabs with the log stream live via SSE.

Project pipelines Project page — pipelines as cards, status-tinted left border, bottleneck pill, mini stage strip.

Value Stream Map VSM — the graph of pipelines + materials, exactly the GoCD primitive.

Plugin catalog — auto-generated from each plugin’s plugin.yaml manifest.

Where to next

Operate: jump to Helm install for the cluster runbook, or Local dev for make dev.
Author pipelines: the Quickstart walks the smallest pipeline that does something useful end-to-end.
Reference: the plugin catalog is built from the same plugin.yaml manifests the server validates with: against, so what you read here matches what runs.