/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>
49 lines
2.4 KiB
Markdown
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).
|