Orchestration Pipelines

A pipeline is an ordered sequence of test suite executions — API tests, then UI tests, then security scans, then compliance evaluation. Each step runs after the previous one completes.

Why Pipelines

Without a pipeline, you manually:

1. Run API tests
2. Wait for results
3. Run UI tests
4. Wait for results
5. Trigger security scans
6. Wait, then check compliance

With a pipeline, you define this once and execute with one call.

Creating a Pipeline

POST /api/pipelines
{
  "name": "Release v2.1 Validation",
  "projectId": 2,
  "description": "Full validation before release",
  "steps": [
    {
      "stepOrder": 1,
      "name": "API Smoke Tests",
      "suiteType": "API_GROUP",
      "suiteRefId": 1,
      "executionMode": "SEQUENTIAL",
      "stopOnFailure": true
    },
    {
      "stepOrder": 2,
      "name": "UI Regression",
      "suiteType": "UI_SUITE",
      "suiteRefId": 1,
      "executionMode": "SEQUENTIAL",
      "stopOnFailure": false
    },
    {
      "stepOrder": 3,
      "name": "Security Scan",
      "suiteType": "SCAN_GROUP",
      "suiteRefId": 1,
      "executionMode": "PARALLEL"
    },
    {
      "stepOrder": 4,
      "name": "Performance Baseline",
      "suiteType": "PERFORMANCE",
      "suiteRefId": 1
    }
  ]
}

Suite Types

Type	References	What it executes
API_GROUP	api_scenario_group.id	All scenarios in the group
API_SCENARIO	api_scenarios.id	A single API scenario
UI_SUITE	ui_test_suite.id	All UI tests in the suite
SCAN_GROUP	scan_group.id	All security scans in the group
PERFORMANCE	performance_scenarios.id	A performance/load test

Executing a Pipeline

POST /api/pipelines/{id}/execute
{
  "tag": "release-v2.1",
  "environmentId": 7,
  "credentialTag": "regression-test"   # optional — defaults to env's default credential
}

Field	Required	Notes
environmentId	Yes	Which environment the pipeline runs against. Request is rejected with HTTP 400 if missing.
tag	No	Free-text version tag for filtering history; defaults to pipeline-run.
credentialTag	No	Pinned credential for the run. Falls back to the environment's default credential when omitted.

The pipeline runs asynchronously. Each step:

1. Calls the existing suite execute endpoint
2. Waits for completion
3. Records the execution ID (no result duplication)
4. Moves to the next step (or aborts if stopOnFailure triggered)

The environmentId is persisted on the execution record and surfaces in the executions table as the Environment column, so testers can see at a glance which environment a given pipeline run targeted. Older runs created before this field existed (cloud-security-scanner-release#38) render as "— (legacy run)" in that column rather than blocking the row.

When the Environment column is missing or always blank for new runs, the backend may be running a stale image. CI normally restarts the proofarc-backend deployment on every main merge via the KUBECONFIG_CONTENT GitHub secret; if that secret is missing, the "Rollout Deployments" job in docker-publish.yml skips silently with a warning and you'll need kubectl -n proofarc rollout restart deployment proofarc-backend manually. See cloud-security-scanner-release#43.

Viewing Results

# List all executions for a pipeline
GET /api/pipelines/{id}/executions

# Get specific execution with step details
GET /api/pipelines/executions/{executionId}

Each step execution has an executionId that points to the existing execution record (API scenario execution, scan job, etc.). No data is duplicated — follow the pointer to see full results.

Stop on Failure

When stopOnFailure: true on a step:

• If that step fails, all subsequent steps are SKIPPED
• The pipeline status is FAILED
• Previous step results are preserved

Use this for critical steps: "Don't run security scans if API tests fail."

Pipeline Flow

Define Pipeline (once)
  ├── Step 1: API Smoke Tests (stopOnFailure: true)
  ├── Step 2: UI Regression
  ├── Step 3: Security Scans (parallel)
  └── Step 4: Performance Test

Execute Pipeline (each release)
  ├── Step 1: COMPLETED → execution_id=45
  ├── Step 2: COMPLETED → execution_id=102
  ├── Step 3: COMPLETED → job_id=abc-123
  └── Step 4: COMPLETED → job_id=def-456

View Results
  └── Each step → follow execution_id to existing results