UniDesk E2E Reference

UniDesk delivery is not complete until the public frontend, public provider ingress, internal core API, PostgreSQL database, local provider-gateway self-connection, and frontend Playwright flow pass one end-to-end check. The canonical automated command is bun scripts/cli.ts e2e run.

Required Preconditions

config.json network.publicHost must be the externally reachable host name or IP of the main server, not 127.0.0.1, when validating browser access from outside the server.
bunx playwright install chromium and bunx playwright install-deps chromium must have been run on hosts that execute browser E2E tests.
The Docker stack must be running through bun scripts/cli.ts server start, and bun scripts/cli.ts server status must report healthy frontend, provider ingress, internal core, database, and provider-gateway containers.

Automated E2E Scope

bun scripts/cli.ts e2e run validates the following URLs and internal checks derived from config.json. The CLI response is intentionally bounded: it prints check names/statuses, screenshot path, counts, and resultPath; the full per-check diagnostics are written to resultPath under .state/e2e/ so failures remain inspectable without flooding stdout.

Public exposure: Docker port summary must show only frontend and provider ingress host mappings; public core、public database and known private microservice ports such as FindJob 3254 probes must fail.
Core API: docker exec unidesk-backend-core calls internal GET /api/overview, which must report dbReady: true and at least one online node.
Provider self-connection: internal GET /api/nodes must contain main-server with status: online, labels.providerGatewayVersion equal to src/components/provider-gateway/package.json and labels.providerGatewayUpgradePolicy: "always-enabled"; internal GET /api/nodes/system-status must contain CPU/memory/disk samples; internal GET /api/nodes/docker-status must contain a Docker snapshot for main-server; public provider ingress /health must return ok.
Provider remote control: internal /api/dispatch must successfully complete a real provider.upgrade task in mode: "plan" so the upgrade path is validated without recreating the running gateway during E2E.
Microservices: internal /api/microservices must include findjob and pipeline on D601 with public=false; /api/microservices/findjob/health and /api/microservices/findjob/proxy/api/summary must succeed through the real provider-gateway proxy; /api/microservices/findjob/proxy/api/jobs?__unideskArrayLimit=jobs:5 must return a bounded preview with _unidesk.arrayLimits metadata; /api/microservices/pipeline/health and /api/microservices/pipeline/proxy/api/snapshot?__unideskArrayLimit=registry.components:8,runs:3 must return Pipeline health, registry and run previews.
Database: the command writes an unidesk_e2e_markers row through docker exec unidesk-database psql and confirms provider state is stored in PostgreSQL.
Frontend: Playwright must open the public frontend URL derived from network.publicHost, not localhost or a Docker-internal URL; it logs in with the configured account, waits for 核心在线, asserts that main-server and Main Server Provider are visible, clicks 查看原始JSON to verify Provider data from the frontend, confirms no raw JSON is visible before that click, opens task history to verify duration and failure diagnostics, opens resource nodes 资源监控 to verify CPU/Memory/Disk curves and provider upgrade precheck dispatch, opens Docker 状态 and verifies the Docker Desktop-style container view including the database named volume unidesk_pgdata_10gb, opens 网关版本 and verifies the provider-gateway version, SSH 透传可用性、远程更新可用性 plus structured automatic update records for provider.upgrade, then opens 微服务 / 服务目录、微服务 / FindJob and 微服务 / Pipeline to verify D601、仓库引用、私有后端映射、FindJob 指标和岗位预览、Pipeline 组件矩阵和最近运行都通过 React 控件展示。
Microservice frontend assertions must wait for real backend data, not only the page skeleton. For FindJob this means the page must show a numeric 岗位总量, HEALTH OK, and a non-empty PREVIEW count such as 40/1463 PREVIEW; for Pipeline this means the page must show Pipeline v2 工作台, Health OK, a numeric component count, 控制图, and 最近运行; loading placeholders like -- or empty states are not sufficient for E2E success.

Frontend JSON Rule

The frontend must render JSON data into React controls by default. Raw JSON is allowed only after an explicit 查看原始JSON user action, and E2E must fail if the initial page exposes raw JSON text or a raw JSON block.

Automatic update records in the frontend are covered by the same rule: provider.upgrade task history must be rendered as rows/cards with status, mode, task id, source, duration, policy, outcome summary, and updated time. The page must not expose upgrade plan/result JSON as a log block unless the operator clicks 查看原始JSON.

Provider operation availability is also covered by the structured rendering rule. host.ssh availability must be displayed as badges or equivalent controls derived from capabilities and hostSsh* labels, and remote update availability must be displayed from provider.upgrade capability plus the always-enabled policy; these fields must not require opening raw Provider JSON.

Microservice pages are covered by the same rule. FindJob must show metrics, jobs and drafts as cards/tables; Pipeline must show component classes, graph nodes, run cards and log summaries as controls; the full microservice config, summary, snapshot, jobs preview, drafts and run JSON can only appear after an explicit 查看原始JSON click.

Public Boundary Rule

The public frontend URL and provider ingress URL are the only public network interfaces. backend-core REST API and PostgreSQL database are Docker-internal only; E2E must prove the historical public core/database ports are not reachable.

Database Persistence Rule

The PostgreSQL data volume is the named Docker volume unidesk_pgdata_10gb. CLI server control commands must never use docker compose down -v, docker volume rm, or any equivalent data-volume removal. To validate persistence, insert a marker row into unidesk_e2e_markers, run bun scripts/cli.ts server start or a full stop/start cycle, and verify the marker row still exists.

Delivery Gate

Before claiming delivery, run these checks and keep their JSON output or screenshot path available for review:

bun scripts/cli.ts check
bun scripts/cli.ts server start, then bun scripts/cli.ts job status latest until succeeded
bun scripts/cli.ts server status
bun scripts/cli.ts e2e run and inspect failedChecks or the emitted resultPath if any check fails
a database persistence marker check across at least one CLI-controlled restart

Provider Upgrade Gate

When delivery explicitly includes upgrading or rebuilding a compute-node provider-gateway such as D601 or D518, the automated E2E plan check is not sufficient. The operator must first bootstrap any legacy provider only from a node-local terminal, node-owned web terminal, systemd, scheduled task, or detached shell if it cannot yet schedule upgrades; SSH passthrough carried by the same provider-gateway must not be used for synchronous self-rebuilds. Then run provider.upgrade with mode: "schedule" against that Provider ID, confirm the task succeeds, confirm the node reconnects in the public frontend, and finally verify any required host.ssh capability with bun scripts/cli.ts ssh <PROVIDER_ID> hostname. This schedule check is a node-upgrade gate, not a replacement for the standard public frontend Playwright E2E gate.

External compute nodes should run that schedule check through the remote main-server passthrough form: bun scripts/cli.ts --main-server-ip 74.48.78.17 debug dispatch <PROVIDER_ID> provider.upgrade --mode schedule --wait-ms 15000. The default remote transport logs in to the public frontend and does not require a main server SSH key; this proves the node can validate itself without direct access to backend-core REST or PostgreSQL.

8.2 KiB Raw Blame History