azaion/ui

mirror of https://github.com/azaion/ui.git synced 2026-06-21 19:21:10 +00:00

Files

T

Oleksandr Bezdieniezhnykh 510df68bcf [AZ-447] autodev Steps 1-4 baseline: docs, tests, refactor specs

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>

2026-05-11 00:38:49 +03:00

4.1 KiB

Raw Blame History

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.

4.1 KiB Raw Blame History Unescape Escape