bugfix/spider-ssr-gate
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
bb45e8d6ae |
fix(ssr): inject derived gradients and migrate component SCSS to CSS vars
CI Pipeline / backend-test (push) Successful in 9m52s
CI Pipeline / frontend-test (push) Successful in 24s
CI Pipeline / frontend-build (push) Successful in 30s
CI Pipeline / backend-lint (push) Successful in 9s
CI Pipeline / backend-test (pull_request) Successful in 9m59s
CI Pipeline / frontend-test (pull_request) Successful in 23s
CI Pipeline / frontend-build (pull_request) Successful in 31s
CI Pipeline / backend-lint (pull_request) Successful in 8s
CI Pipeline / quality-gate (push) Successful in 2s
CI Pipeline / quality-gate (pull_request) Successful in 2s
The server-injected inline <style> was missing the three derived gradient variables (--sky-gradient, --sunset-gradient, --mixed-gradient) that components reference via var(). Without them, components fell back to SCSS build-time defaults on the first paint, causing a visible flash before ThemeService.apply() corrected the values. Additionally, migrate three component SCSS files from hardcoded SCSS color variables to CSS custom properties so the first paint uses the server-injected runtime colors: - login.component.scss: backgrounds, text colors, borders, focus rings - events.component.scss: event date card background gradient - about.component.scss: donation CTA background gradient |
||
|
|
e78a725839 |
fix(ssr): remove color defaults from :root in _themes.scss
CI Pipeline / backend-test (push) Successful in 9m55s
CI Pipeline / frontend-test (push) Successful in 23s
CI Pipeline / frontend-build (push) Successful in 29s
CI Pipeline / backend-lint (push) Successful in 9s
CI Pipeline / backend-test (pull_request) Successful in 9m56s
CI Pipeline / frontend-test (pull_request) Successful in 23s
CI Pipeline / frontend-build (pull_request) Successful in 30s
CI Pipeline / backend-lint (pull_request) Successful in 8s
CI Pipeline / quality-gate (push) Successful in 2s
CI Pipeline / quality-gate (pull_request) Successful in 1s
The SSR server injects fresh color CSS custom properties as an inline <style> block before </head>, but _themes.scss also set hardcoded color defaults on :root at build time. The two :root blocks compete in the cascade — the compiled stylesheet (loaded after the inline <style>) overwrites the server-injected colors, causing a visible flash where wrong colors render briefly before ThemeService.apply() corrects them. Removing the color properties from :root in _themes.scss makes the server-injected <style> the sole source of truth for colors. Non-color properties (fonts, radii, shadows) remain as build-time defaults since they don't change between deploys. |
||
|
|
3dead2921a |
fix: switch sitemap/robots to dynamic generation + Nginx proxy
CI Pipeline / backend-test (push) Successful in 8m58s
CI Pipeline / frontend-test (push) Successful in 29s
CI Pipeline / frontend-build (push) Successful in 31s
CI Pipeline / backend-lint (push) Successful in 10s
CI Pipeline / backend-test (pull_request) Successful in 8m56s
CI Pipeline / frontend-test (pull_request) Successful in 28s
CI Pipeline / frontend-build (pull_request) Successful in 32s
CI Pipeline / backend-lint (pull_request) Successful in 11s
CI Pipeline / quality-gate (push) Successful in 3s
CI Pipeline / quality-gate (pull_request) Successful in 3s
The reviewer noted the static sitemap.xml had a hardcoded domain in a white-label app. Instead of writing files to disk, we now serve sitemap.xml and robots.txt as dynamic API endpoints that read KMTN_WEBSITE_URL at runtime. - Nginx proxies /sitemap.xml and /robots.txt to the backend API so search crawlers reach them at root paths. - Removed the startup filesystem-write that would fail in Docker (backend can't write to Nginx container's static dir). - Simplified sitemap_export.py to pure generation functions (no I/O). - Added /api/sitemap/regenerate admin endpoint for consistency. |
||
|
|
5484c761b4 |
fix: address reviewer feedback — dynamic sitemap/robots + wildcard CI branches
CI Pipeline / backend-test (push) Successful in 8m12s
CI Pipeline / frontend-test (push) Successful in 28s
CI Pipeline / frontend-build (push) Successful in 32s
CI Pipeline / backend-lint (push) Successful in 9s
CI Pipeline / backend-test (pull_request) Successful in 8m43s
CI Pipeline / frontend-test (pull_request) Successful in 29s
CI Pipeline / frontend-build (pull_request) Successful in 32s
CI Pipeline / backend-lint (pull_request) Successful in 9s
CI Pipeline / quality-gate (push) Successful in 3s
CI Pipeline / quality-gate (pull_request) Successful in 2s
- CI workflow: replace hardcoded branch list with ['**'] wildcard so pipeline runs on every branch push, not just 4 named branches. - Sitemap/robots.txt: moved from static files to dynamic generation. New sitemap_export.py module (follows theme_export.py pattern) uses KMTN_WEBSITE_URL to generate tenant-aware sitemap.xml and robots.txt on app startup. Atomic writes to STATIC_FILES_DIR so Nginx serves them. - Added /api/sitemap endpoint with /status (public) and /regenerate (admin-only) for runtime control. Addresses reviewer comments on PR #4: 1. 'more general way to ensure this runs on any branch on push' 2. 'whitelabel app - this file may need to be dynamically generated' |