marcel/familienarchiv
1
0
Fork 0
Code Issues 118 Pull Requests 2 Actions 4 Packages Projects Releases Wiki Activity

test(ci): production image smoke-test job — boot frontend + backend images, curl /login #501

New Issue
Open
opened 2026-05-11 13:19:38 +02:00 by marcel · 0 comments
marcel commented 2026-05-11 13:19:38 +02:00
Owner
Copy Link

Background

PR #499 wires the production deploy pipeline (Caddy + nightly staging + release tag → production). The first cross-image regression is caught only at deploy time: if a frontend Dockerfile change breaks the production stage, or the backend image fails to bind 8080, the workflow's up -d --wait step is the first to notice — at 02:00 during the nightly run.

A pre-merge CI job that boots the actual production images and curls /login would catch this at PR time.

This was Sara's "deferred follow-up" in the pre-merge review summary (comment #8333) and tracked as OQ-2 in Elicit's PR #499 review (comment #8356).

Scope

Add a CI job production-images-smoke to .gitea/workflows/ci.yml:

  1. Build the frontend production stage and the backend image using docker compose -f docker-compose.prod.yml build against a stub .env.
  2. Bring up minio + db + backend + frontend (--profile staging to skip the OCR container, which is 5GB+ of model weights and not useful for a smoke).
  3. Wait for healthchecks (--wait).
  4. Curl /login on the frontend, assert 200 + content-type text/html.
  5. Curl /actuator/health on the backend through the internal docker network (not via Caddy), assert UP.
  6. Tear down with down -v.

Total CI time target: < 5 minutes on the existing self-hosted runner. If the OCR container would be needed for a more complete smoke, that goes in a separate job (it would dominate runtime).

Acceptance criteria

  • CI job exists and passes on the PR that introduces it
  • Job fails when a real regression is introduced (verified by intentionally breaking the frontend production stage on a throwaway branch)
  • Job runtime < 5 minutes p90 on existing runner

Out of scope

  • OCR container smoke (separate follow-up — heavy)
  • Anything requiring secrets (stub env file only)
  • E2E flows (covered by existing Playwright job)

References

  • PR #499 — QA review (Sara, #8354)
  • PR #499 — Requirements review (Elicit, #8356, OQ-2)
  • Issue #461 — security scan gates in CI (parallel scope; image smoke is the functional counterpart)
## Background PR #499 wires the production deploy pipeline (Caddy + nightly staging + release tag → production). The first cross-image regression is caught only at deploy time: if a frontend Dockerfile change breaks the `production` stage, or the backend image fails to bind 8080, the workflow's `up -d --wait` step is the first to notice — at 02:00 during the nightly run. A pre-merge CI job that boots the actual production images and curls `/login` would catch this at PR time. This was Sara's "deferred follow-up" in the pre-merge review summary ([comment #8333](https://git.raddatz.cloud/marcel/familienarchiv/issues/497#issuecomment-8333)) and tracked as OQ-2 in Elicit's PR #499 review (comment [#8356](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8356)). ## Scope Add a CI job `production-images-smoke` to `.gitea/workflows/ci.yml`: 1. Build the frontend `production` stage and the backend image using `docker compose -f docker-compose.prod.yml build` against a stub `.env`. 2. Bring up minio + db + backend + frontend (`--profile staging` to skip the OCR container, which is 5GB+ of model weights and not useful for a smoke). 3. Wait for healthchecks (`--wait`). 4. Curl `/login` on the frontend, assert 200 + content-type text/html. 5. Curl `/actuator/health` on the backend through the internal docker network (not via Caddy), assert UP. 6. Tear down with `down -v`. Total CI time target: < 5 minutes on the existing self-hosted runner. If the OCR container would be needed for a more complete smoke, that goes in a separate job (it would dominate runtime). ## Acceptance criteria - [ ] CI job exists and passes on the PR that introduces it - [ ] Job fails when a real regression is introduced (verified by intentionally breaking the frontend `production` stage on a throwaway branch) - [ ] Job runtime < 5 minutes p90 on existing runner ## Out of scope - OCR container smoke (separate follow-up — heavy) - Anything requiring secrets (stub env file only) - E2E flows (covered by existing Playwright job) ## References - PR #499 — QA review (Sara, [#8354](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8354)) - PR #499 — Requirements review (Elicit, [#8356](https://git.raddatz.cloud/marcel/familienarchiv/pulls/499#issuecomment-8356), OQ-2) - Issue #461 — security scan gates in CI (parallel scope; image smoke is the functional counterpart)
marcel added the P2-mediumdevopstest labels 2026-05-11 13:19:43 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
P0-critical
Blocks a core user journey, causes data loss, or is a security/accessibility barrier. Work on this before P1+.
 P1-high
Significant friction on a main user journey; workaround exists but is non-obvious. Next up after P0.
 P2-medium
Noticeable improvement; doesn't block anything; schedule opportunistically.
 P3-later
Cosmetic or parking-lot work; fine to stay open indefinitely.
 audit
Read-only audit / assessment work; produces a report rather than changing code
 bug
Something isn't working
 cleanup
Removal of dead code, vague comments, naming violations, and scratch artifacts
 collaboration
We want to extend the family archive to have more collaboration tools
 conversation
descoped
We will do that later
 devops
documentation
README, ARCHITECTURE, GLOSSARY, CONTRIBUTING, per-domain docs
 epic
Marker for epic-level issues that group multiple child issues
 feature
file-upload
legibility
Codebase Legibility Refactor — preparing the codebase for human evaluation and bus-factor reduction
 notification
person
phase-1: security
Security hygiene — must be done first
 phase-2: container-images
Production-ready multi-stage Docker images
 phase-3: prod-compose
Production compose overlay + Caddy reverse proxy
 phase-4: spring-prod-profile
Spring Boot production configuration profile
 phase-5: backups
Database and object storage backup strategy
 phase-6: deployment-docs
.env.example, DEPLOYMENT.md, runbook
 phase-7: monitoring
Prometheus, Loki, Grafana, Alertmanager
 refactor
Code restructuring without behaviour change
 security
test
ui
UI/UX and accessibility issues
 user
No Label P2-medium devops test
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Jens marcel
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: marcel/familienarchiv#501
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?