Make factory-game CI test gate fail fast instead of hanging in dotnet restore #7

New issue

Closed

opened 2026-07-09 17:05:30 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-09 17:05:30 +00:00

Member

The current factory-game-v3 CI run for commit d30f9f0630 (chore: verify git lfs asset availability) has been spinning in the gate job for several minutes. The visible log is stuck inside ward exec test:

ward: exec test in /workspace/coilyco-gaming/factory-game-v3
cli-guard: namespace sandbox unavailable here; running tools unsandboxed (set CLIGUARD_NO_SANDBOX=1 to silence). See docs/sandbox.md.
  Determining projects to restore...

Current repo wiring from main:

.forgejo/workflows/ci.yml has one job, gate, in dev-base v0.226.0, checkout with lfs: true, then ward exec test.
.ward/ward.yaml maps test to dotnet test tests.csproj.
tests.csproj targets net8.0, restores xUnit/OpenTelemetry/ReportGenerator packages, and references Assets/Plugins/*.dll, Assets/Plugins/**/*.dll, plus old Unity editor glob paths.
This repo is in Unity-to-Rust/Bevy transition; the test gate is intended as a lightweight migration baseline, not a long-running restore sink.

Requested implementation:

Make CI fail fast or produce a clear diagnostic instead of hanging indefinitely at Determining projects to restore....
Add a practical timeout around the test gate in CI and/or the ward test verb.
Split restore/build/test phases if that gives better logs, so a NuGet restore hang is visibly distinct from compile/test failures.
Review tests.csproj for stale Unity-era references that force broad plugin/tree scans or remote restore work that is inappropriate for the current migration baseline. Remove or narrow stale references if safe.
Keep the gate useful for the current C# baseline, but do not let a verification-only commit like #6 sit in CI for 8+ minutes with no new output.
Update README/docs if the validation command changes.

Acceptance:

A fresh push shows the gate job either passes or fails with actionable output in a bounded time.
The log no longer sits silently at Determining projects to restore... for many minutes.
The fix does not undo the LFS setup from #4/#6 or the aos baseline from #5.

The current `factory-game-v3` CI run for commit `d30f9f0630` (`chore: verify git lfs asset availability`) has been spinning in the `gate` job for several minutes. The visible log is stuck inside `ward exec test`: ```text ward: exec test in /workspace/coilyco-gaming/factory-game-v3 cli-guard: namespace sandbox unavailable here; running tools unsandboxed (set CLIGUARD_NO_SANDBOX=1 to silence). See docs/sandbox.md. Determining projects to restore... ``` Current repo wiring from main: * `.forgejo/workflows/ci.yml` has one job, `gate`, in dev-base `v0.226.0`, checkout with `lfs: true`, then `ward exec test`. * `.ward/ward.yaml` maps `test` to `dotnet test tests.csproj`. * `tests.csproj` targets `net8.0`, restores xUnit/OpenTelemetry/ReportGenerator packages, and references `Assets/Plugins/*.dll`, `Assets/Plugins/**/*.dll`, plus old Unity editor glob paths. * This repo is in Unity-to-Rust/Bevy transition; the test gate is intended as a lightweight migration baseline, not a long-running restore sink. Requested implementation: * Make CI fail fast or produce a clear diagnostic instead of hanging indefinitely at `Determining projects to restore...`. * Add a practical timeout around the test gate in CI and/or the ward `test` verb. * Split restore/build/test phases if that gives better logs, so a NuGet restore hang is visibly distinct from compile/test failures. * Review `tests.csproj` for stale Unity-era references that force broad plugin/tree scans or remote restore work that is inappropriate for the current migration baseline. Remove or narrow stale references if safe. * Keep the gate useful for the current C# baseline, but do not let a verification-only commit like #6 sit in CI for 8+ minutes with no new output. * Update README/docs if the validation command changes. Acceptance: * A fresh push shows the `gate` job either passes or fails with actionable output in a bounded time. * The log no longer sits silently at `Determining projects to restore...` for many minutes. * The fix does not undo the LFS setup from #4/#6 or the aos baseline from #5.

coilyco-ops commented

2026-07-09 17:05:38 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-factory-game-v3-7 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T17:05:35Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL). --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-gaming/factory-game-v3#7 · branch issue-7 · harness codex · workflow direct-to-main
Run: engineer-codex-factory-game-v3-7 · ward v0.493.0 · dispatched 2026-07-09T17:05:35Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-factory-game-v3-7` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T17:05:35Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h TTL). `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh**. That is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-gaming/factory-game-v3#7` · branch `issue-7` · harness `codex` · workflow `direct-to-main` - **Run:** `engineer-codex-factory-game-v3-7` · ward `v0.493.0` · dispatched `2026-07-09T17:05:35Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-09 17:12:06 +00:00

fix: bound factory-game test gate

coilyco-ops closed this issue

2026-07-09 17:12:06 +00:00

coilyco-ops commented

2026-07-09 17:12:50 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default
felt: the restore/test split was straightforward once moved into a script and the stale Unity references were narrowed
confidence: high
surprises: the container had no dotnet on PATH, so the local failure path was a fast diagnostic instead of a restore stall
follow-ups: none

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: direct-to-main; review summary: review gate skipped by ~/.ward/config.yaml default felt: the restore/test split was straightforward once moved into a script and the stale Unity references were narrowed confidence: high surprises: the container had no dotnet on PATH, so the local failure path was a fast diagnostic instead of a restore stall follow-ups: none </details>

coilyco-ops referenced this issue

2026-07-09 17:34:38 +00:00

Make factory-game main CI green after bounded test-gate change #8

coilyco-ops referenced this issue

2026-07-09 17:52:39 +00:00

Fix remaining factory-game CI failure after dev-base dotnet bump #9