saqib mirandClaude Sonnet 5
414f336704
/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>
2.4 KiB
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).