2f0bda1e28
Some checks failed
shell-lint / shellcheck (pull_request) Failing after 10m43s
secrets-guard / encrypted (pull_request) Failing after 10m45s
PR build (required check) / changes (pull_request) Failing after 10m47s
PR build (required check) / build-backend (pull_request) Has been cancelled
PR build (required check) / build-frontend (pull_request) Has been cancelled
PR build (required check) / validate-observability (pull_request) Has been cancelled
PR build (required check) / gate (pull_request) Has been cancelled
MonthPage and RecordsPage each made two backend calls sequentially (CityMonth/CityRecords, then City) where the second never depended on the first's result -- both are independent single-slug lookups. Waiting for one full round trip before even starting the other was pure latency with nothing to show for it. fetchWithCity launches both concurrently via goroutines and a WaitGroup. Verified live against a stub with an injected 400ms delay on both endpoints: city page (1 call) and month/records pages (2 calls each) all cost ~0.404s now, not ~0.404s vs ~0.8s -- the two-call pages no longer pay double. Error priority is preserved exactly: if the primary call fails, its error wins even when City also fails or hasn't finished, matching the old sequential code (which never called City() once primary had already failed). The one real trade-off, called out in the comment: City() is now always launched even on a request that's about to 404 from primary, so an invalid slug costs one extra (wasted, cheap) backend lookup it previously skipped -- worth it since a bad slug is the rare path and a good one is the common path this speeds up. Tests: happy path; primary-error-wins and city-error-surfaces (both single and combined failure); and a deterministic concurrency proof via rendezvous channels rather than timing (the old sequential code would deadlock this test, not just run it slower). Full suite green under `-race -count=2`. Docker build (which runs `go test` inside the image) passes. |
||
|---|---|---|
| .forgejo/workflows | ||
| backend | ||
| frontend | ||
| infra | ||
| observability | ||
| CLAUDE.md | ||
| CUTOVER-NOTES.md | ||
| README.md | ||
thermograph
The Thermograph monorepo — the split repos reunified (2026-07-22) with full history via subtree merges, while keeping everything the split was actually for: per-domain images, per-domain deploys, and an async FE/BE contract.
Domains
| Dir | What | CI |
|---|---|---|
backend/ |
FastAPI graded-climate API, accounts, notifications (Discord bot, push, mail), data pipeline | backend-build-push → image emi/thermograph/backend; backend-deploy[-prod|-dev] |
frontend/ |
Public client: static JS/CSS + SSR pages | frontend-* mirrors of the above; image emi/thermograph/frontend |
infra/ |
Compose, deploy scripts, terraform, SOPS secrets vault, ops cron | infra-sync (host checkout + secrets render), secrets-guard, ops-cron |
observability/ |
Loki + Grafana + Alloy stack | observability-validate |
thermograph-docs deliberately stays its own repo (ADRs + runbooks, no
build artifacts, different change cadence).
How CI stays decoupled
Every workflow in .forgejo/workflows/ is path-filtered to its domain: a
push touching only frontend/** builds/deploys nothing else. Images stay
separate (emi/thermograph/backend, emi/thermograph/frontend, each tagged
sha-<12hex>), deploys stay per-service (infra/deploy/deploy.sh SERVICE=backend|frontend|all), and the API version contract
(GET /api/version, PAYLOAD_VER) still lets FE and BE ship out of lockstep.
The one intentionally coupled piece is pr-build.yml: a single always-running
gate required check that builds only the domains a PR touches (a
path-filtered required check would deadlock auto-merge).
Branch model (unchanged from the split era): PRs → dev, main → beta,
release → prod; infra tracked via main on all hosts.
Before pointing anything live at this repo, read CUTOVER-NOTES.md.