cesnimda/jobtrackingapp
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

ci: bisect backend suite across steps to localise runner crash
CI and Deploy / test (push) Failing after 1m0s
Details
CI and Deploy / deploy (push) Has been skipped
Details

Browse Source 
The host smoke passes, so the test host starts; the full suite still dies ~3s
in with parallelism disabled, so one specific test takes the process down on
this runner only. Job logs are unreadable via the API, so the suite is sliced
across four steps — the first failing step identifies the class. Temporary
diagnostic scaffolding; every test still runs, nothing is skipped.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
cesnimda
2026-07-18 21:55:35 +02:00
parent 2bdc4a9748
commit 7fa3080a28
1 changed files with 16 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitea/workflows/ci-deploy.yml
+16 -5
View File
@@ -62,11 +62,22 @@ jobs:
- name: Test backend (host smoke)
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build --filter "FullyQualifiedName~CvBuilderTests.Every_catalog_theme_renders_valid_html"
# Collection parallelism is disabled here for the same reason the frontend runs --runInBand:
# this runner is resource-flaky (documented npm ci SIGSEGV and SDK cache corruption above).
# Every one of the 306 tests still runs -- only the concurrency changes.
- name: Test backend
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build -- xUnit.parallelizeTestCollections=false xUnit.maxParallelThreads=1
# The host smoke above passes, so the test host starts fine; the full suite still dies ~3s in
# even with parallelism disabled, i.e. one specific test takes the process down on this runner
# only. Job logs are not readable via the API, so the suite is bisected across steps: the first
# failing step localises the offending class. Slices are alphabetical because execution order is
# alphabetical once collection parallelism is off. Temporary diagnostic — every test still runs.
- name: Test backend (slice 1 A-C)
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build -- xUnit.parallelizeTestCollections=false xUnit.maxParallelThreads=1 --filter "FullyQualifiedName~AiWorkspace|FullyQualifiedName~Attachment|FullyQualifiedName~AuthAndSystem|FullyQualifiedName~BackupController|FullyQualifiedName~CareerProfile|FullyQualifiedName~ClientErrors|FullyQualifiedName~Correspondence|FullyQualifiedName~CvBuilder|FullyQualifiedName~CvCorpus"
- name: Test backend (slice 2 D-J)
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build -- xUnit.parallelizeTestCollections=false xUnit.maxParallelThreads=1 --filter "FullyQualifiedName~DatabaseBackup|FullyQualifiedName~EmailStatus|FullyQualifiedName~GmailController|FullyQualifiedName~GoogleToken|FullyQualifiedName~Imap|FullyQualifiedName~InterviewPrep|FullyQualifiedName~JobApplications"
- name: Test backend (slice 3 J-P)
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build -- xUnit.parallelizeTestCollections=false xUnit.maxParallelThreads=1 --filter "FullyQualifiedName~JobCvMatch|FullyQualifiedName~JobImport|FullyQualifiedName~JobPipeline|FullyQualifiedName~LocalAuth|FullyQualifiedName~MicrosoftGraph|FullyQualifiedName~MicrosoftToken|FullyQualifiedName~Ownership|FullyQualifiedName~ProductionConfig|FullyQualifiedName~ProfileCv"
- name: Test backend (slice 4 R-T)
run: dotnet test JobTrackerApi.Tests/JobTrackerApi.Tests.csproj --configuration Release --no-build -- xUnit.parallelizeTestCollections=false xUnit.maxParallelThreads=1 --filter "FullyQualifiedName~RulesEngine|FullyQualifiedName~Sessions|FullyQualifiedName~SqliteMigration|FullyQualifiedName~StageAnalytics|FullyQualifiedName~Summarizer|FullyQualifiedName~TwoFactor"
- name: Install frontend deps
working-directory: job-tracker-ui