docs: capture todo - Gitea CI regression + Docker build/publish

This commit is contained in:
Lucas Berger
2026-06-09 20:49:07 -04:00
parent 73fcdaf075
commit 2cae72e9dd
2 changed files with 53 additions and 8 deletions
+9 -8
View File
@@ -4,12 +4,12 @@ milestone: v1.0
milestone_name: milestone milestone_name: milestone
status: executing status: executing
stopped_at: Phase 5 UI-SPEC approved stopped_at: Phase 5 UI-SPEC approved
last_updated: "2026-06-09T22:44:55.108Z" last_updated: "2026-06-10T00:34:28.043Z"
last_activity: "2026-06-09 -- Phase 04 plan 07 complete (gap-closure: LIST-03 + T-04-08)" last_activity: 2026-06-10 -- Phase 05 execution started
progress: progress:
total_phases: 15 total_phases: 15
completed_phases: 4 completed_phases: 4
total_plans: 28 total_plans: 36
completed_plans: 28 completed_plans: 28
percent: 27 percent: 27
--- ---
@@ -21,14 +21,14 @@ progress:
See: .planning/PROJECT.md (updated 2026-06-07) See: .planning/PROJECT.md (updated 2026-06-07)
**Core value:** One color-coded family calendar (shared + personal) and shared lists from a single low-friction PWA — cross-ecosystem, no app store **Core value:** One color-coded family calendar (shared + personal) and shared lists from a single low-friction PWA — cross-ecosystem, no app store
**Current focus:** Phase 04shared-lists-live-sync **Current focus:** Phase 05web-push-notifications
## Current Position ## Current Position
Phase: 04 (shared-lists-live-sync) — COMPLETE Phase: 05 (web-push-notifications) — EXECUTING
Plan: 7 of 7 (all plans complete) Plan: 1 of 8
Status: Ready to execute Status: Executing Phase 05
Last activity: 2026-06-09 -- Phase 04 plan 07 complete (gap-closure: LIST-03 + T-04-08) Last activity: 2026-06-10 -- Phase 05 execution started
Progress: [██████████] 100% Progress: [██████████] 100%
@@ -110,6 +110,7 @@ Recent decisions affecting current work:
- **Fix `docs/deployment.md` local-dev command** — the documented dev run is wrong: the API dev script (`node --watch dist/index.js`) does NOT load `.env`, and `DB_HOST` defaults to `localhost` with an empty password. Correct local-dev command is: `pnpm --filter @familysync/api build && set -a; source .env; set +a && DEV_AUTH_BYPASS=true DB_HOST=localhost pnpm --filter @familysync/api dev` (+ `pnpm --filter @familysync/pwa dev`). Consider adding `--env-file=.env` to the dev script so this is automatic. (Surfaced during Phase 2 UAT.) - **Fix `docs/deployment.md` local-dev command** — the documented dev run is wrong: the API dev script (`node --watch dist/index.js`) does NOT load `.env`, and `DB_HOST` defaults to `localhost` with an empty password. Correct local-dev command is: `pnpm --filter @familysync/api build && set -a; source .env; set +a && DEV_AUTH_BYPASS=true DB_HOST=localhost pnpm --filter @familysync/api dev` (+ `pnpm --filter @familysync/pwa dev`). Consider adding `--env-file=.env` to the dev script so this is automatic. (Surfaced during Phase 2 UAT.)
- **REQUIREMENTS.md traceability gap** — phase.complete flagged 6 REQ-IDs in the body missing from the Traceability table: CAL-09, CAL-10, CAL-11, CAL-12, DISP-01, DISP-02. Add them to keep traceability in sync (likely Phase 4/5/display requirements). - **REQUIREMENTS.md traceability gap** — phase.complete flagged 6 REQ-IDs in the body missing from the Traceability table: CAL-09, CAL-10, CAL-11, CAL-12, DISP-01, DISP-02. Add them to keep traceability in sync (likely Phase 4/5/display requirements).
- **DST spring-forward spot-check (Phase 2)** — recurring/DST is implemented and code-verified (VTIMEZONE before expansion + local display TZ), and operator approved general times; navigating to March 2026 to eyeball the spring-forward transition is a recommended future spot-check. - **DST spring-forward spot-check (Phase 2)** — recurring/DST is implemented and code-verified (VTIMEZONE before expansion + local display TZ), and operator approved general times; navigating to March 2026 to eyeball the spring-forward transition is a recommended future spot-check.
- **Gitea CI — regression on PR to main + Docker build/publish** — self-hosted Gitea runner exists but no CI yet. Add `.gitea/workflows/`: full regression (lint/typecheck/unit + API integration tests against a MariaDB service container + PWA build) gating PRs to `main`, plus build/publish the Docker image to the Gitea registry. Decide image matrix (API-only vs API+PWA — only `apps/api/Dockerfile` exists today) and tag policy. See pending todo `2026-06-10-gitea-ci-regression-and-docker-publish.md`.
### Blockers/Concerns ### Blockers/Concerns
@@ -0,0 +1,44 @@
---
created: 2026-06-10T00:48:16.555Z
title: Gitea CI — full regression on PR to main + build/publish Docker image
area: tooling
files:
- docker-compose.yml
- docker-compose.dev.yml
- apps/api/Dockerfile
---
## Problem
The repo is committed against a self-hosted Gitea instance with a registered
Actions runner, but there is no CI yet (no `.gitea/workflows/` or `.github/workflows/`).
Two things should run automatically:
1. **Full regression testing** on every PR targeting `main` — gate the merge.
2. **Build the app's Docker image and publish it to the Gitea container registry.**
Open context / decisions to make when picking this up:
- **Test scope:** "full regression" = lint + typecheck + unit + the API integration
tests. Those integration tests need a real MariaDB (see
[[api-integration-test-db]]) — the workflow must spin up a MariaDB service
container, bind it, and set `DB_HOST=127.0.0.1` + `.env` creds. The PWA build/test
also needs to run.
- **Monorepo:** pnpm workspace (`apps/api`, `apps/pwa`, shared). Cache the pnpm store.
- **Docker images:** only `apps/api/Dockerfile` exists today — there is no PWA
Dockerfile yet. Decide whether to publish one image (API) or also build/serve the
PWA. Tag scheme + when to publish (only on merge to `main`? on tags? per-PR?).
- **Registry auth:** push to the Gitea registry using the runner's `GITHUB_TOKEN`/
Gitea-provided token or a dedicated package-write token.
- Gitea Actions are GitHub-Actions-compatible syntax but run on the self-hosted
runner — confirm runner labels and available images.
## Solution
TBD — likely a `.gitea/workflows/ci.yml`:
- `on: pull_request` (to `main`) → job: install (pnpm), lint, typecheck, unit tests,
API integration tests against a `mariadb` service container, PWA build.
- `on: push` to `main` (or tag) → job: `docker build` `apps/api/Dockerfile`, login to
Gitea registry, push tagged image.
Verify Gitea Actions enablement + runner is healthy before authoring. Decide image
matrix (API only vs. API+PWA) and tag policy first.