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>
2.9 KiB
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.ymlhad fixedcontainer_namevalues (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: twoupruns under different-pproject names now produce<project>-postgres-1/<project>-redis-1etc. with no collision).docker compose ... downneeds the same--env-fileflag asup, or it can fail to resolve service config and leave containers running — confirmed by hitting this locally; theJenkinsfile'spost { always { ... } }teardown includes it.- The existing
test:unitnpm script (vitest runwith no path filter) currently runs the entiretests/**/*.test.tsglob — including integration/E2E — becausevitest.config.ts'sincludeisn't scoped per script; onlytest:integration/test:e2enarrow 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 theUnit teststage 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.