Sluijsens
084b941204
Continuous Integration / config (pull_request) Successful in 10s
Continuous Integration / backend-build (pull_request) Successful in 4m57s
Continuous Integration / vulnerability-scan (pull_request) Successful in 4m47s
Continuous Integration / frontend-prepare (pull_request) Successful in 1m51s
Continuous Integration / backend-test (pull_request) Successful in 5m17s
Continuous Integration / frontend-build (pull_request) Successful in 2m15s
Continuous Integration / frontend-test (pull_request) Successful in 4m24s
Continuous Integration / frontend-lint (pull_request) Successful in 2m10s
Continuous Integration / publish-production (pull_request) Skipped
Continuous Integration / deploy-production (pull_request) Skipped
Continuous Integration / publish-test (pull_request) Successful in 6m19s
Continuous Integration / deploy-test (pull_request) Skipped
actions/setup-node@v4's Post step attempts a cache-save that fails hard on this self-hosted Gitea Actions runner (no GHES cache API support), marking frontend-prepare as failed and blocking its dependents even though the actual install/build work succeeds. v3's older cache implementation doesn't hit this. Also cleans up two stale comments left over from the /admin MSBuild-target removal. Also updates the documented backup script to skip cleanly (exit 0) when the target database doesn't exist yet (MariaDB error 1049) rather than failing the whole deploy - expected on a brand-new environment's first production run, before migrations have ever had a chance to create it. Still fails hard on any other error, so a real backup failure against an existing database still blocks the deploy as intended.