Pipeline projects

A pipeline project is the ownership and release boundary for one repository-backed body of workflow code. It contains source configuration, discovered pipelines, environments and operational history.

Create and manage projects

POST {api-base}/orgs/{org_id}/workspaces/{workspace_id}/pipeline-projects
GET  {api-base}/orgs/{org_id}/workspaces/{workspace_id}/pipeline-projects
GET  {api-base}/orgs/{org_id}/workspaces/{workspace_id}/pipeline-projects/{project_id}
PUT  {api-base}/orgs/{org_id}/workspaces/{workspace_id}/pipeline-projects/{project_id}
DELETE {api-base}/orgs/{org_id}/workspaces/{workspace_id}/pipeline-projects/{project_id}

DELETE archives a project. It preserves versions, deployments and execution history. Permanent purge is a separately authorized asynchronous operation and should be used only after retention and dependency checks.

Repository configuration

Each project can have one active repository configuration referencing a workspace Git integration. The configuration selects the repository, tracked branch and source policy without copying provider credentials.

POST /pipeline-projects/{project_id}/repository
GET  /pipeline-projects/{project_id}/repository
PUT  /pipeline-projects/{project_id}/repository

Definition roots

Definition roots restrict discovery to one or more repository paths. Use them to avoid treating unrelated code as runnable pipeline declarations.

POST /pipeline-projects/{project_id}/definitions-roots
GET  /pipeline-projects/{project_id}/definitions-roots
PUT  /pipeline-projects/{project_id}/definitions-roots/{root_id}
DELETE /pipeline-projects/{project_id}/definitions-roots/{root_id}

Roots must remain inside the checked-out project source. Absolute paths and traversal outside the source revision are rejected.

Source reconciliation

Reconciliation resolves repository head and project configuration into a source revision. It is asynchronous because fetching, validation and discovery can require compute.

POST /pipeline-projects/{project_id}/reconciliations
GET  /pipeline-projects/{project_id}/reconciliations
GET  /pipeline-projects/{project_id}/reconciliations/{reconciliation_id}

The reconciliation record includes request kind, branch/configuration generations, state and diagnostics. Repeated webhook deliveries can converge on the same repository state without publishing duplicate releases.

Source revisions

GET  /pipeline-projects/{project_id}/source-revisions
GET  /pipeline-projects/{project_id}/source-revisions/{revision_id}
POST /pipeline-projects/{project_id}/source-revisions/dirty-drafts

A revision freezes resolved source and discovery results. Repository revisions record their commit identity. Dirty drafts are explicit development artifacts and must not be mistaken for a reviewed repository commit.

Development sessions

Development sessions provide time-bounded compute against a base revision and project environment.

POST /pipeline-projects/{project_id}/development-sessions
GET  /pipeline-projects/{project_id}/development-sessions
GET  /pipeline-projects/{project_id}/development-sessions/{session_id}
POST /pipeline-projects/{project_id}/development-sessions/{session_id}/activity
POST /pipeline-projects/{project_id}/development-sessions/{session_id}/stop

Sessions have idle and maximum lifetime limits. Touch activity only for genuine user work; it is not a substitute for a production deployment.

Pipelines and versions

Discovered pipeline identities remain stable across revisions. Publishing a version freezes the selected source revision and the server-validated execution declaration.

GET  /pipelines
GET  /pipelines/{pipeline_id}
GET  /pipelines/{pipeline_id}/versions
GET  /pipelines/{pipeline_id}/versions/{version_id}
POST /pipelines/{pipeline_id}/versions/{version_id}/publish

Only published versions are eligible for normal environment deployment and scheduled production execution.