The backend test step fails on the self-hosted runner after 8s while passing
on Windows, in a clean Linux container, and in CI's exact build-then-test
order. The job log is not readable via the Gitea API (401), so step boundaries
are the only available telemetry: splitting restore / build / test makes the
failing phase identifiable from step timings alone.
Restore retries once, mirroring the npm ci and dotnet SDK retries already in
this workflow for the same runner's known flakiness. The suite itself is
unchanged — still the whole suite, nothing filtered or skipped.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The build step only builds JobTrackerApi, so the test project was never
compiled — and `dotnet test --no-build` then made the step a ~1s no-op
(locally it errors "test source file not found"; on the persistent
self-hosted runner it can silently run a stale binary). The 306 backend
tests have not been gating CI.
Drop --no-build so the test project is compiled and the suite runs.
Verified locally: 306 passed in 14s instead of "succeeding" in 1s.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
npm run build (Terser minify + fork-ts-checker workers) has now died three
distinct ways on this runner in this session: a printed Terser minify error,
an explicit SIGSEGV, and a fully silent kill with zero output between
'Creating an optimized production build...' and the failure line (OOM/SIGSEGV
signature — process killed before it could flush an error). All three are the
same resource-starved-runner class as the npm ci and dotnet-install flakes
already retried elsewhere in this workflow. Retry once, matching that pattern.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The single self-hosted act_runner intermittently fails actions/setup-dotnet:
a partial extraction sticks in the shared tool-cache (tar: Cannot open: File
exists) or the SDK tarball download corrupts. Install into a clean private
$HOME/.dotnet via dotnet-install.sh with a rm -rf + retry-once, matching the
npm ci and NuGet publish retries already in this pipeline.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The frontend deps step occasionally crashes with "Segmentation fault (core
dumped)" (exit 139) during `npm ci` — a memory/native flake on the act_runner,
unrelated to the change under test (it failed the deploy-fix PR whose only change
is the Dockerfile). Retry once with a clean node_modules before failing.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The whitelist silently skipped new suites; two regressions in
non-whitelisted suites reached main unnoticed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
cesnimda
cesnimda