Skip to main content
Version: 1.0

Pipelines

The Pipelines page (/pipelines) tracks CI activity for a tenant's own repositories — it's meant for a customer's external CI (their own GitHub Actions, GitLab CI, or anything else) to report into, not a KubeOpera-hosted build system. Every pipeline you register belongs to your tenant alone; kubeopera-api resolves your tenant from your session and never trusts a client-supplied tenant ID, so there's no way to see or write another tenant's pipelines.

A pipeline gets created two ways: manually, via the Create Pipeline form described below, or automatically the first time you deploy a GitHub-sourced app through the Deploy Application Wizard — a matching Pipeline and Build Config are registered for you with no extra step, and the build's real progress reports into it. See App Creation Flow for that path.

Summary cards​

Four cards, togglable between the tenant-wide 7-day rollup and one specific pipeline's own numbers via the dropdown above them: Total Runs, Success Rate, Failed Runs, and Avg Duration.

Reporting into a pipeline​

After creating a pipeline, the confirmation panel shows two things, once, that are never shown again: the webhook URL to configure at your Git host (https://cicd.kubeopera.io/webhook/{github|gitlab}, triggered on Push), and a one-time reporting token for direct API reporting from your own CI. Copy the token immediately — it isn't retrievable again after this screen.

Two ways to use the token, both shown as ready-to-use curl snippets with your real pipeline ID and token already filled in:

Option A — your CI creates and owns the run:

RUN_ID=$(curl -s -X POST https://cicd.kubeopera.io/api/v1/pipelines/<id>/runs \
  -H "X-Pipeline-Token: <token>" -H "Content-Type: application/json" \
  -d '{"commit":"'"$GIT_SHA"'","branch":"'"$GIT_BRANCH"'","trigger_type":"manual"}' | jq -r .id)

curl -s -X PATCH https://cicd.kubeopera.io/api/v1/runs/$RUN_ID \
  -H "X-Pipeline-Token: <token>" -H "Content-Type: application/json" \
  -d '{"status":"success","stages":[{"name":"build","status":"success"}]}'

Option B — correlate with the run a push webhook already created:

RUN_ID=$(curl -s "https://cicd.kubeopera.io/api/v1/pipelines/<id>/runs/find?commit=$GIT_SHA" \
  -H "X-Pipeline-Token: <token>" | jq -r .id)

Either way, a stage report can include real failure diagnostics — error_message, a short log_excerpt (keep it to the last ~20 lines or the failing assertion, not a full log), exit_code, and a log_url pointing at the real source of truth (for GitHub Actions, ${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID} needs no extra setup to construct). PATCHing the same stage name twice updates that one stage in place rather than creating a duplicate — so an incremental "running → success/failed" report for the same stage works as expected.

The repository string you register (owner/repo for GitHub, group/project for GitLab) must exactly match what the webhook payload reports, since that's how an inbound webhook event gets correlated to your pipeline.

note

Webhook signature verification (GITHUB_WEBHOOK_SECRET/GITLAB_WEBHOOK_TOKEN) isn't provisioned on every deployment today — if it isn't configured, anyone who discovers your webhook URL could post a fake run. The reporting-token path (Option A/B above) doesn't have this exposure, since the token is generated per-pipeline and never guessable.

Run list and detail​

The run list and its detail view are a master/detail split, the same pattern used on the Incidents and Traces pages: select a run on the left, see its full detail on the right — there's no inline accordion-expand here.

The detail panel includes a Gantt-style timeline: one horizontal bar per reported stage, positioned and sized by its real started_at/finished_at timestamps against the run's own total duration, colored by status (running/success/failed). For each stage, the panel also shows any error_message, log_excerpt, and a link to the real log (log_url) — when a stage carries none of these, it just shows its status and timing, no fabricated detail.

The "closed browser" guarantee​

For an app deployed via the wizard's GitHub-source path, the Kaniko build's own progress is reported into its pipeline by build-service itself, server-side — not by the browser tab that started the deploy. If you close the wizard, or the whole browser, before the build finishes, the run in the Pipelines dashboard still reaches a correct final state with full stage data, because nothing about reporting depends on that tab staying open.