acdream/tests/AcDream.Launcher.Tests/xunit.runner.json
Erik b746d3d61b
Some checks failed
CI / linux-portable (push) Failing after 1s
CI / windows-gate (push) Failing after 6s
CI / release (push) Has been skipped
ci: Gitea pipeline — gate on both self-hosted runners, publish alpha releases
Every push to main now runs the gate on the self-hosted runners and, when
green, publishes a Gitea Release carrying the client, launcher+bake, and
manifest.

Pipeline (.gitea/workflows/ci.yml):
- windows-gate runs tools/run-release-gate.ps1, the project's own bounded
  gate. A bare `dotnet test AcDream.slnx` is NOT usable as a gate: it fails
  ~36 tests by design, because the InstalledDat/Live/Manual/OS lanes assert
  their own preconditions. The gate script's trait filter is what excludes
  them.
- linux-portable runs the portable closure, where the Linux-lane tests
  actually execute instead of failing on Windows.
- release depends on both, so a red gate cannot publish. It is a job in the
  same workflow rather than a workflow_run trigger, whose Forgejo support is
  unreliable; `needs` is guaranteed.

No actions/setup-dotnet: data.forgejo.org does not mirror it at all (404),
and both runners carry the pinned SDK band already. actions/checkout IS
mirrored and is used normally.

Release payloads become release ATTACHMENTS, outside git history, so ~120 MB
per build never enters a branch. Only the ~500-byte manifest.json is
committed, to the payload-free dist branch, because Forgejo has no
/releases/latest/download/ route (verified 404) for the launcher to poll.
publish-bin.ps1 takes -BaseUrl so the manifest points at the release tag.

Two real gate failures fixed:
- LauncherProjectBoundaryTests asserted four `**` path filters belonging to
  the push triggers that 8be14d39 removed when workflows went manual-only.
  The assertions about what the workflow DOES are untouched.
- MainWindowViewTests failed in Test Case Cleanup with "calling thread cannot
  access this object" while passing in isolation: Avalonia's headless session
  is thread-affine and xUnit ran collections in parallel. Serialized via
  xunit.runner.json, the same settings AcDream.Core.Tests already uses.

Local gate: 12 projects, 14,346 tests, 0 failures.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-19 10:35:36 +02:00

6 lines
175 B
JSON

{
"$schema": "https://xunit.net/schema/current/xunit.runner.schema.json",
"parallelizeAssembly": false,
"parallelizeTestCollections": false,
"maxParallelThreads": 1
}