Files
support_backend/specs/001-ci-pipeline/checklists/requirements.md
T
saqib mirandClaude Sonnet 5 2dffe58496 feat: implement CI pipeline (Jenkinsfile) for 001-ci-pipeline
Implements tasks T001-T016, T018-T022, T024-T026 from
specs/001-ci-pipeline/tasks.md (T017/T023 need a real Jenkins
instance to verify and are left for manual follow-up).

- Add Jenkinsfile: checkout -> install -> environment validation
  -> typecheck -> lint (+ architecture check) -> format check ->
  unit -> integration -> E2E -> build -> Docker build -> publish
  -> deploy, matching the constitution's required stage order.
  Secrets are always injected from Jenkins credentials at runtime,
  never read from a repo-committed file. Publish/Deploy are skipped
  (not failed) on branches with no resolved deploy target.
- Fix docker-compose.test.yml: remove fixed container_name on
  app/postgres/redis, which would have made concurrent CI runs
  collide (FR-009). Verified locally that two runs under different
  -p project names no longer share container/volume/network names.
- Document the pipeline and local .env setup in README.md.
- Mark completed tasks in specs/001-ci-pipeline/tasks.md and record
  the container_name/compose-down-env-file findings in the spec's
  requirements checklist notes.

Locally verified passing: Dockerfile build, typecheck, lint,
architecture check, format check, unit test suite, and the edited
docker-compose.test.yml bringing up postgres/redis with isolated
per-project container names.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-21 17:25:46 +05:30

2.9 KiB

Specification Quality Checklist: Continuous Integration Pipeline

Purpose: Validate specification completeness and quality before proceeding to planning Created: 2026-08-21 Feature: spec.md

Content Quality

  • No implementation details (languages, frameworks, APIs)
  • Focused on user value and business needs
  • Written for non-technical stakeholders
  • All mandatory sections completed

Requirement Completeness

  • No [NEEDS CLARIFICATION] markers remain
  • Requirements are testable and unambiguous
  • Success criteria are measurable
  • Success criteria are technology-agnostic (no implementation details)
  • All acceptance scenarios are defined
  • Edge cases are identified
  • Scope is clearly bounded
  • Dependencies and assumptions identified

Feature Readiness

  • All functional requirements have clear acceptance criteria
  • User scenarios cover primary flows
  • Feature meets measurable outcomes defined in Success Criteria
  • No implementation details leak into specification

Notes

  • Deferred, out of scope for this feature: flaky-test retry/quarantine policy (see Edge Cases).
  • Tool choice (e.g. which CI system) is deliberately left out of this spec — the constitution's Technology & Platform Constraints section already commits to Jenkins per docs/09; that mapping belongs in /speckit-plan, not here.
  • All items pass; no revision iterations were needed.

Implementation notes (added during /speckit-implement)

  • docker-compose.test.yml had fixed container_name values (support-test, postgres-test, redis-test) on all three services — this would have made FR-009/SC-005 (concurrent-run isolation) impossible, since Docker container names must be unique per host regardless of Compose project. Removed them so Compose auto-names containers per project (verified locally: two up runs under different -p project names now produce <project>-postgres-1 / <project>-redis-1 etc. with no collision).
  • docker compose ... down needs the same --env-file flag as up, or it can fail to resolve service config and leave containers running — confirmed by hitting this locally; the Jenkinsfile's post { always { ... } } teardown includes it.
  • The existing test:unit npm script (vitest run with no path filter) currently runs the entire tests/**/*.test.ts glob — including integration/E2E — because vitest.config.ts's include isn't scoped per script; only test:integration/test:e2e narrow by passing an explicit directory. Today's "integration" tests are instantiation-only checks (no real DB/Redis calls yet), so this isn't currently harmful, but it means the Unit test stage doesn't actually isolate unit-only coverage. Out of scope to fix here (not part of this feature's requirements) — worth a follow-up once real integration tests exist.