Files
ai-spel-static/README.md
T
Ein Anderssono 4ebe1bb9ec
Build and publish static assets / publish (push) Failing after 9s
Add static Piper asset service
2026-10-16 07:24:54 +02:00

31 lines
1.9 KiB
Markdown

# AI-spel static assets
This repository publishes Piper/ONNX runtime assets and Swedish voice models through a dedicated Nginx service. The game keeps the same origin: ingress routes `/static/` here, `/` to the frontend, and `/api` to Rust.
The service contains only public, version-pinned files. Gitea Actions on the existing `large` runner downloads and verifies model files, runs checks, builds a `linux/amd64` image, bumps the patch version, and publishes the image, Helm chart, and rendered manifest to Harbor. Argo CD tracks the latest chart in the existing `ai-spel` project and namespace.
## Asset URLs and caching
Assets under `/static/piper-wasm-v1/` are served with `Cache-Control: public, max-age=31536000, immutable`. Keep this path and its contents stable. To change assets, publish under a new asset path and update the frontend to reference it after the new static release is healthy.
- `/static/piper-wasm-v1/voices/` — Alma, Lisa, and NST Swedish voices, plus attribution.
- `/static/piper-wasm-v1/onnx/` — ONNX Runtime WASM and ES module loader.
- `/static/piper-wasm-v1/piper/` — Piper phonemizer WASM and data.
- `/static/version.txt` — active deployment version, without long-lived caching.
The frontend worker remains bundled with the frontend; it fetches these large assets from same-origin static URLs. The browser does not request models from an external host.
## Argo CD bootstrap
After the first chart has been published, bootstrap the app once from `deploy/argocd/application.yaml`:
```sh
kubectl -n argocd apply -f deploy/argocd/application.yaml
```
It tracks the newest chart (`*`), uses automated sync/self-heal without pruning, and deploys to `ai-spel`. Later releases do not need manual Argo actions.
## Local policy
Do not build or run locally. CI runs static checks, tests, image build, and Helm lint/render on the existing runner; runtime verification happens on Kubernetes.