Files
support_backend/specs/001-ci-pipeline/data-model.md
T
saqib mirandClaude Sonnet 5 414f336704 docs: spec, plan, and design artifacts for CI pipeline feature
/speckit-specify + /speckit-plan output for 001-ci-pipeline: feature
spec with 2 user stories and 10 functional requirements, requirements
quality checklist, implementation plan with constitution gate check,
Phase 0 research (6 decisions incl. secrets-from-credentials-store),
Phase 1 data model, pipeline stage contract, and a 5-scenario
quickstart validation guide. No Jenkinsfile yet — that's the
implementation step after /speckit-tasks.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-21 16:22:29 +05:30

49 lines
2.4 KiB
Markdown

# Phase 1 Data Model: Continuous Integration Pipeline
This feature has no application/Prisma data model — it introduces no new database entities. The
"entities" below (from spec.md's Key Entities) are Jenkins-native concepts, recorded here only
so the contract between them is explicit; none require new persistence code.
## Pipeline Run
Represents one execution of the full validate → build → publish → deploy sequence for a single
proposed change.
| Field | Meaning | Source of truth |
|---|---|---|
| id / build number | Unique identifier for the run | Jenkins build number |
| trigger ref | Commit SHA / PR reference that triggered the run | Jenkins SCM checkout metadata |
| stage results | Ordered list of Stage Result (see below) | Jenkins declarative pipeline `stages` block |
| overall status | pass / fail | Jenkins build result |
| deploy target | Which environment (if any) this run published/deployed to | Jenkins pipeline parameter, derived from branch (main → prod pipeline job; other branches → validate-only, no deploy) |
**Lifecycle**: created on trigger → stages execute in order → stops at first failing stage (FR-003)
→ terminal state (pass/fail) is immutable once set.
## Stage Result
The outcome of one stage (checkout, install, env validation, typecheck, lint, format check, unit
test, integration test, E2E test, build, Docker build, publish, deploy) within a Pipeline Run.
| Field | Meaning |
|---|---|
| stage name | One of the fixed stage names in Constitution → Testing, Observability & CI/CD Gates |
| status | pass / fail / skipped (later stages are "skipped" once an earlier stage fails, per FR-003/FR-005) |
| output | Captured log output for that stage, surfaced to the engineer (FR-004) |
| duration | Stage execution time |
**Relationship**: many Stage Results belong to one Pipeline Run, ordered.
## Deploy Target
An environment a validated build can be published/deployed to.
| Field | Meaning |
|---|---|
| name | `test` \| `staging` \| `production` (matches existing `.env.test`/`.env.development`/`.env.prod` + `docker-compose.*.yml` split) |
| credentials | Reference into Jenkins credentials store (never repo-committed — see research.md) |
| compose file | The corresponding `docker-compose.<target>.yml` |
**Relationship**: a Pipeline Run targets at most one Deploy Target for its publish/deploy stages;
validate-only runs (e.g. feature-branch builds) have no Deploy Target (Edge Cases in spec.md).