Your NameandClaude Sonnet 5
db0f8e4543
The deploy pipeline (.gitea/workflows/deploy.yml -> Dockerfile) never got updated when the frontend was rewritten under web/ -- it was still doing `npm ci`/`npm run build` at the repo root and copying the old app's umd/, css/, index.html, etc. into the nginx image. Every deploy therefore kept shipping the old app regardless of what was actually on dev, no matter how much of the rewrite had landed. Dockerfile now builds from web/ (Vite) and copies its self-contained dist/ output (index.html + content-hashed assets/, no separate umd/css/ img/audio/manifest/service-worker/firebase files -- none of that exists in the new app). VITE_TINODE_API_KEY is what src/lib/config.ts actually reads (Vite only exposes VITE_-prefixed env vars to client code), so the existing TINODE_API_KEY build-arg is now renamed into that on its way into the build environment instead of passed through under its old name. nginx.conf updated to match: index.html stays no-cache (its URL never changes, so a stale cached copy would keep pointing at deleted asset filenames after a deploy), assets/ gets a long immutable cache (Vite content-hashes every filename there, so a new build never reuses an old URL). Dropped the old umd/ and img/ location blocks, neither exists in the new build. Verified locally: `docker build` succeeds, the container serves the new app's real index.html/assets with the intended cache headers, and an unknown client-side route (/messages/slf) correctly falls back to index.html. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
25 lines
1.1 KiB
Nginx Configuration File
25 lines
1.1 KiB
Nginx Configuration File
server {
|
|
listen 80;
|
|
listen [::]:80;
|
|
server_name _;
|
|
root /usr/share/nginx/html;
|
|
index index.html;
|
|
|
|
# The webapp uses real (History API) client-side routing, so any unknown path can safely fall
|
|
# back to index.html -- the app resolves the actual view/topic client-side from the path itself
|
|
# once index.html loads. index.html itself is never content-hashed, so it must always be
|
|
# revalidated -- otherwise a browser holding a cached copy would keep requesting the *previous*
|
|
# deploy's now-deleted /assets/*.js filenames after a new deploy replaces them.
|
|
location / {
|
|
add_header Cache-Control "no-cache";
|
|
try_files $uri $uri/ /index.html;
|
|
}
|
|
|
|
# Vite content-hashes every filename under assets/ (e.g. index-DYjopaLI.js) -- a new build never
|
|
# reuses an old asset's URL, so these can be cached aggressively and indefinitely; a stale cached
|
|
# copy simply never gets requested again once index.html points at the new hashed filenames.
|
|
location /assets/ {
|
|
add_header Cache-Control "public, max-age=31536000, immutable";
|
|
}
|
|
}
|