Fix the red mods CI compile gate (part 2 of #68: decoupled but never repaired) #69

New issue

Closed

opened 2026-07-05 07:13:36 +00:00 by coilysiren · 1 comment

coilysiren commented

2026-07-05 07:13:36 +00:00

Owner

Context

Follow-up to #68. That fix decoupled the app-image publish from the mods compile job (the P0 that had frozen prod since #60) and landed - prod is unfrozen and current. But #68's part 2, repairing the red mods job itself, is not done: the mods CI job has failed on every run since #60 added it, including run 58 on the post-fix HEAD (88325f5). It no longer blocks deploys, but the mod-compile safety signal is still red.

Why it matters

The mods gate is the only automated check that the four C# mods actually compile before they ship to the game server out of band. Those out-of-band mod ships are exactly the queued restart-window work - #55 (stores activation), #31 (jobs-mod rollout), #65 (CitizensApiController) - so a green mods gate is the net that stops a broken mod crash-looping the server (eco-ops#7). Right now that net is down.

Ask

Make the mods job green. It has never passed - investigate make build-mods in the CI environment and fix the cause. Likely suspects:

the self-installed .NET 10 SDK step,
Eco.ReferenceAssemblies restore - the pin was bumped 998 -> 1024 by #66; confirm 0.13.0-beta-release-1024 actually restores from the feed and that all four mods (jobs, replay, telemetry, stores #55) compile against it,
ICU / DOTNET_SYSTEM_GLOBALIZATION_INVARIANT.

Keep mods a required status check / signal, but do not re-add it to publish's needs (that coupling is what #68 removed).

Acceptance

The mods job passes on a fresh push (make build-mods compiles all four mods green in CI).
publish still needs: [test, frontend] only.

Refs

Decouple: #68. Gate origin: #60. Pin bump: #66. Restart-window consumers of the signal: #55, #31, #65. Crash-loop risk: eco-ops#7.

## Context Follow-up to #68. That fix **decoupled** the app-image `publish` from the `mods` compile job (the P0 that had frozen prod since #60) and landed - prod is unfrozen and current. But #68's part 2, **repairing the red `mods` job itself**, is not done: the `mods` CI job has failed on every run since #60 added it, including run 58 on the post-fix HEAD (`88325f5`). It no longer blocks deploys, but the mod-compile **safety signal is still red**. ## Why it matters The `mods` gate is the only automated check that the four C# mods actually compile before they ship to the game server out of band. Those out-of-band mod ships are exactly the queued restart-window work - #55 (stores activation), #31 (jobs-mod rollout), #65 (CitizensApiController) - so a green mods gate is the net that stops a broken mod crash-looping the server (eco-ops#7). Right now that net is down. ## Ask Make the `mods` job green. It has never passed - investigate `make build-mods` in the CI environment and fix the cause. Likely suspects: * the self-installed .NET 10 SDK step, * `Eco.ReferenceAssemblies` restore - the pin was bumped 998 -> 1024 by #66; confirm `0.13.0-beta-release-1024` actually restores from the feed and that all four mods (`jobs`, `replay`, `telemetry`, `stores` #55) compile against it, * ICU / `DOTNET_SYSTEM_GLOBALIZATION_INVARIANT`. Keep `mods` a required status check / signal, but do **not** re-add it to `publish`'s `needs` (that coupling is what #68 removed). ## Acceptance * The `mods` job passes on a fresh push (`make build-mods` compiles all four mods green in CI). * `publish` still `needs: [test, frontend]` only. ## Refs Decouple: #68. Gate origin: #60. Pin bump: #66. Restart-window consumers of the signal: #55, #31, #65. Crash-loop risk: eco-ops#7.

coilyco-ops commented

2026-07-05 07:13:47 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-eco-app-69 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-05T07:13:42Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s 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).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-eco-app-69` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-05T07:13:42Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s 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).  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-05 07:33:19 +00:00

fix(ci): harden the mods compile gate against the runner's flaky NuGet egress (#69)

coilysiren closed this issue

2026-07-05 07:33:19 +00:00

coilysiren referenced this issue from a commit

2026-07-05 07:33:19 +00:00

Merge branch 'issue-69': harden the mods compile gate against flaky NuGet egress (#69)

coilysiren referenced this issue

2026-07-06 03:24:23 +00:00

Two EcoReplay BodySerializer tests fail on clean checkout (ArgumentException: Can not convert Object to String) #67

coilyco-ops referenced this issue