Files
galaxy-game/ui/docs/testing.md
T
Ilia Denisov 63cccdc958 docs: testing.md — local gitea ci cheat sheet
Replaces the act-as-fallback section with the operations needed to
work with the local Gitea + arm64 act_runner shipped in tools/local-ci/:
how to bring it up, push, query run status from curl, and pull
zstd-compressed step logs from inside the gitea container. Keeps a
short act note as a syntax-only dry-run.

Also drops `client/**` from the path-filter list documented at the
top (the workflow excludes deprecated client/ from triggers and from
the go test command), and notes that the checkout step now uses
submodules: recursive so MaxMind-DB fixtures land for pkg/geoip.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-07 08:49:43 +02:00

6.6 KiB

UI Testing Tiers

UI client test toolchain. Project-wide testing layers (service / inter-service / system) live in ../../docs/TESTING.md; this doc only covers the UI-specific tiers added in Phase 2 of ../PLAN.md.

Tier 1 — per-PR

Triggered by .gitea/workflows/ui-test.yaml on every push and pull request that touches ui/**, backend/**, gateway/**, game/**, pkg/**, go.work, or go.work.sum. Linux runner only.

The actions/checkout@v4 step uses submodules: recursive, so the runner pulls every git submodule the suite depends on (today only pkg/geoip/test-data, the MaxMind-DB fixtures used by pkg/geoip).

Runs:

  • go test over the monorepo Go modules, excluding two areas:

    • integration/ — needs Docker + testcontainers and is the project's make -C integration integration gate.
    • client/ — the deprecated Fyne client (see ../PLAN.md §74) is frozen; its tests are not run in CI.

    The pkg/<name>/ modules are listed one by one in the workflow because they are independent go.work modules and ./pkg/... does not recurse into separate modules. The exact command lives in .gitea/workflows/ui-test.yaml.

  • pnpm test (Vitest + @testing-library/svelte + @testing-library/jest-dom) — component / unit tests under ui/frontend/tests/**/*.test.ts.

  • pnpm exec playwright test — end-to-end smoke against pnpm run dev on port 5173. Four projects:

    • chromium-desktop (Desktop Chrome)
    • webkit-desktop (Desktop Safari)
    • chromium-mobile-iphone-13 (iPhone 13 viewport, Chromium engine)
    • chromium-mobile-pixel-5 (Pixel 5 viewport, Chromium engine)

Playwright traces and screenshots are retained on failure and uploaded as Gitea Actions artefacts (playwright-report and playwright-traces, 14-day retention).

Tier 2 — release

Triggered by .gitea/workflows/ui-release.yaml on tag push (v*). Currently mirrors the Tier 1 step set; the dedicated release-only checks land in later phases:

  • Visual regression baseline check — Phase 33. Snapshots live in ui/frontend/tests/__snapshots__/ until the project shifts to Argos or another visual-diff service.
  • iOS smoke (Capacitor + Appium) — Phase 32. Runs on a macos-13 runner once the Capacitor mobile wrapper exists.

Both blocks are present as commented sections in .gitea/workflows/ui-release.yaml with the phase number that re-enables them.

Local execution

From ui/frontend/:

pnpm test                                           # Vitest
pnpm exec playwright install                        # one-time
pnpm exec playwright test                           # all projects
pnpm exec playwright test --project=chromium-desktop
pnpm exec playwright show-report                    # open last HTML report

From the repository root, the same scope CI uses (backend serially because most packages spawn their own Postgres testcontainer and parallel bootstraps starve each other on constrained runners):

go test -count=1 -p 1 ./backend/...
go test -count=1 \
  ./gateway/... ./game/... \
  ./pkg/calc/... ./pkg/connector/... ./pkg/cronutil/... \
  ./pkg/error/... ./pkg/geoip/... ./pkg/model/... \
  ./pkg/postgres/... ./pkg/redisconn/... ./pkg/schema/... \
  ./pkg/storage/... ./pkg/transcoder/... ./pkg/util/...

Local CI verification

tools/local-ci/ ships a self-contained Gitea + Actions runner via docker-compose so workflow changes are exercised end-to-end on a real runner before pushing to a remote Gitea instance. On Apple Silicon the runner and every spawned workflow container are arm64-native (no QEMU). Full runbook lives in ../../tools/local-ci/README.md; the cheat sheet below covers the operations needed when working a phase that touches CI.

Bring up / push / tear down

make -C tools/local-ci up      # idempotent: gitea + runner + admin user + repo
make -C tools/local-ci push    # add `local-gitea` remote (first call) and push HEAD
make -C tools/local-ci status  # docker compose ps
make -C tools/local-ci logs    # tail container logs
make -C tools/local-ci down    # stop, keep state
make -C tools/local-ci clean   # stop and wipe volumes for a fresh start

Default credentials baked in: galaxy:galaxy-dev (admin user, also the owner of the galaxy/galaxy repo). Web UI on http://localhost:3000; runs at http://localhost:3000/galaxy/galaxy/actions.

Inspect a run from the shell

The Gitea Actions API is on http://localhost:3000/api/v1 with basic auth. Useful for verifying a workflow change without opening the browser:

# Latest workflow runs — `status` is a human-readable string here:
# "running" / "success" / "failure" / "cancelled".
curl -s -u galaxy:galaxy-dev \
  'http://localhost:3000/api/v1/repos/galaxy/galaxy/actions/tasks?limit=5' \
  | python3 -m json.tool

# Tight one-liner for the latest run only:
curl -s -u galaxy:galaxy-dev \
  'http://localhost:3000/api/v1/repos/galaxy/galaxy/actions/tasks?limit=1' \
  | python3 -c 'import json, sys; r=json.load(sys.stdin)["workflow_runs"][0]; print(r["run_number"], r["status"], r["display_title"])'

Step-by-step workflow output is stored zstd-compressed under /data/gitea/actions_log/galaxy/galaxy/<run_padded>/<job_index>.log.zst inside the gitea container:

docker compose -f tools/local-ci/docker-compose.yml exec -T gitea sh -c '
  apk add --quiet zstd
  zstdcat /data/gitea/actions_log/galaxy/galaxy/01/1.log.zst
' | less

<run_padded> is the run number, zero-padded to two digits (01, 02, …); <job_index> is the 1-based index of the job inside that run (only 1 for the current single-job workflows).

Typical phase workflow

When a phase changes anything under .gitea/workflows/ or surfaces new tests in CI:

  1. Local sanity first — run the affected commands directly (pnpm test, pnpm exec playwright test, the targeted go test ./... slice).
  2. Commit and make -C tools/local-ci push.
  3. Poll the API for the latest run; once it leaves running, inspect status. On failure pull the log via the snippet above.
  4. Fix and repeat. The runner is always-on; each push triggers a fresh run (test cache is cleared by -count=1 so a green run is honest).

Quick syntax-only dry-run with act

For a sub-second check that the workflow YAML is well-formed and action references resolve, without pulling images and without running anything:

act -W .gitea/workflows/ui-test.yaml -n push

act doesn't honour Gitea-specific behaviours (artifact storage, secrets, run triggers). Use it for syntax checks; fall back to the local Gitea above for honest end-to-end verification.