mirror of
https://github.com/azaion/ui.git
synced 2026-06-21 14:31:10 +00:00
Oleksandr Bezdieniezhnykh
510df68bcf
Captures the full output of autodev existing-code Phase A through Step 4 (Code Testability Revision) for the Azaion UI workspace: - Step 1 Document: _docs/02_document/ (FINAL_report, architecture, glossary, components/, modules/, diagrams/, system-flows, module-layout) plus _docs/00_problem/ + _docs/01_solution/ + _docs/legacy/ + _docs/how_to_test + README. - Step 2 Architecture Baseline: architecture_compliance_baseline.md. - Step 3 Test Spec: _docs/02_document/tests/ (environment, test-data, blackbox/performance/resilience/security/ resource-limit tests, traceability-matrix), enum_spec_snapshot, expected_results/results_report.md (98 rows), plus the run-tests.sh + run-performance-tests.sh runners. - Step 4 Code Testability Revision: 01-testability-refactoring/ run dir (list-of-changes C01-C07, deferred_to_refactor, analysis/research_findings + refactoring_roadmap) and the 7 child task specs AZ-448..AZ-454 under _docs/02_tasks/todo/ plus _dependencies_table.md. - _docs/_autodev_state.md pins the cursor at Step 4 / refactor Phase 4 entry so /autodev resumes cleanly. Epic AZ-447 (UI testability gates) tracks the 7 child tasks that will land in subsequent commits. Co-authored-by: Cursor <cursoragent@cursor.com>
52 lines
4.1 KiB
Markdown
52 lines
4.1 KiB
Markdown
# Azaion UI — Environment Strategy
|
||
|
||
> Synthesis output of `/document` Step 3d (environment_strategy). Derived from
|
||
> `vite.config.ts`, `nginx.conf`, `.gitignore`, the workspace `README.md`, and
|
||
> the absence of a workspace `.env.example`.
|
||
|
||
## 1. Environments
|
||
|
||
| Env | How it runs | API base | Auth | Tile providers |
|
||
|-----|-------------|----------|------|----------------|
|
||
| Development | `bun run dev` (Vite dev server, port 5173) | Vite dev proxy: `/api → http://localhost:8080` (configured in `vite.config.ts`) | Suite admin/ service running locally (typically via parent suite `docker-compose up`) | OSM + satellite (env-configurable in mission-planner only) |
|
||
| Stage | nginx in container, ARM image `:stage-arm` | nginx `/api/<service>/ → http://<service>:8080/` (intra-cluster) | Stage suite admin/ service | Same |
|
||
| Production | nginx in container, ARM image `:main-arm` | nginx `/api/<service>/ → http://<service>:8080/` | Prod suite admin/ service | Same |
|
||
|
||
## 2. Configuration model
|
||
|
||
The SPA bundle is **fully static**. No env vars are read at runtime by the bundle. Every cross-environment difference is resolved at the **deployment edge** (nginx) or at the **suite-service level**.
|
||
|
||
| Concern | Where it's set | Notes |
|
||
|---------|----------------|-------|
|
||
| Backend API URL | nginx `proxy_pass` (`nginx.conf`) — same nginx config across stage / prod | Base URLs are intra-cluster service names (`http://annotations:8080`, etc.); the URL difference between environments is hidden by the orchestrator's DNS |
|
||
| Auth cookie domain | Set by suite admin/ service on `Set-Cookie` | UI does not control |
|
||
| Refresh-token lifetime | Set by suite admin/ service | UI tolerates any TTL |
|
||
| Tile provider URL (mission-planner) | `.env.example` declares `VITE_SATELLITE_TILE_URL` | mission-planner only; not deployed |
|
||
| OpenWeatherMap API key | **Hardcoded in source** (`flightPlanUtils.ts:60`) | Security finding — Step 4 fix to remove + proxy via suite |
|
||
| `AZAION_REVISION` | Stamped into image at build time | For diagnostics |
|
||
|
||
## 3. Why no `.env`
|
||
|
||
The workspace `.env.example` is **absent** today. The `README.md` "Local development" section explicitly notes this as a Step 4 testability fix.
|
||
|
||
**Trade-off**: avoiding a build-time env injection means `dist/` is identical across environments, which is great for promotability (the same image flows dev → stage → prod). The cost: the OpenWeatherMap key (and any future runtime config) cannot be changed without a rebuild.
|
||
|
||
**Future direction** (Step 4 / Step 5):
|
||
- Move the OpenWeatherMap call server-side (`flights/` service) — eliminates the bundled key entirely.
|
||
- Introduce a runtime `/config.json` that nginx serves — lets ops change feature flags / tile URLs without rebuilding.
|
||
- OR keep the static bundle and use Vite's `define` for build-time injection of safe-to-publish values (no secrets).
|
||
|
||
## 4. Promotability
|
||
|
||
The same image (`:dev-arm`, `:stage-arm`, `:main-arm`) is built per branch from the same Dockerfile. Theoretically the `:dev-arm` image is functionally identical to the `:main-arm` image except for the `AZAION_REVISION` label.
|
||
|
||
In practice: branch separation is the gating mechanism. Once dev → stage → main propagation is normalized, the safer pattern is to build ONE image per commit and re-tag it across environments (immutable image promotion). The Woodpecker pipeline does not implement this today; it rebuilds per-branch.
|
||
|
||
## 5. Local-dev quirks
|
||
|
||
- **Vite dev proxy** (`vite.config.ts`) requires the suite to be reachable on `http://localhost:8080`. If the parent suite's docker-compose binds to a different port, the developer must edit `vite.config.ts` (no env-driven override today).
|
||
- **`bun.lock`**: committed (per `package.json`'s `packageManager` field). `package-lock.json` is gitignored.
|
||
- **`.idea/`, `.claude/`, `.superpowers/`**: gitignored — IDE / agent metadata.
|
||
- **Playwright entries in `.gitignore`**: present but aspirational — Playwright is not installed (Step 5–7 territory).
|
||
- **mission-planner**: has its own `.env.example` declaring `VITE_SATELLITE_TILE_URL` and runs as a sibling Vite app. Not bundled into the deployed image.
|