Design a real required CI path for C# / NuGet checks

coilyco-ops commented

2026-07-09 18:14:04 +00:00

Owner

Deferred follow-up. Kai does want the C# / NuGet checks brought into the normal required-CI fold eventually, but not as part of today's CI-green cleanup.

Context:

Today's decision is to stop treating the current never-green C# / NuGet checks as required CI. See eco-app#110 and factory-game-v3#10.
The current eco-app mods job has historically failed or hung, then was made fail-fast, but it still is not a trustworthy required signal.
The factory-game Unity/NuGet test surface is also stale during the Rust/Bevy migration, so fixing it today is the wrong work.
This issue is the follow-up for doing that properly later, not abandoning the checks permanently.

Requested design/implementation when picked up:

Define what C# / NuGet validation should prove for each repo or package family.
Make the checks reproducible in dev-base or a dedicated pinned CI image.
Avoid indefinite restore hangs; use clear restore/build/test phases, bounded timeouts, and actionable logs.
Decide whether shared NuGet caching/proxying is needed before making the checks required.
For eco-app, determine whether the C# mods gate should be a required job, a manual diagnostic first, or split per mod.
For factory-game-v3, revisit only after the Rust/Bevy migration plan clarifies whether the old Unity C# tests remain useful.
Once the path is reliable, wire it into required CI and update docs to say it is required.

Acceptance:

A documented required-CI design exists for the C# / NuGet checks.
The implementation is green repeatedly before being marked required.
The checks are bounded and diagnosable, not a long-running silent restore sink.

Deferred follow-up. Kai does want the C# / NuGet checks brought into the normal required-CI fold eventually, but not as part of today's CI-green cleanup. Context: * Today's decision is to stop treating the current never-green C# / NuGet checks as required CI. See eco-app#110 and factory-game-v3#10. * The current eco-app `mods` job has historically failed or hung, then was made fail-fast, but it still is not a trustworthy required signal. * The factory-game Unity/NuGet test surface is also stale during the Rust/Bevy migration, so fixing it today is the wrong work. * This issue is the follow-up for doing that properly later, not abandoning the checks permanently. Requested design/implementation when picked up: * Define what C# / NuGet validation should prove for each repo or package family. * Make the checks reproducible in dev-base or a dedicated pinned CI image. * Avoid indefinite restore hangs; use clear restore/build/test phases, bounded timeouts, and actionable logs. * Decide whether shared NuGet caching/proxying is needed before making the checks required. * For eco-app, determine whether the C# mods gate should be a required job, a manual diagnostic first, or split per mod. * For factory-game-v3, revisit only after the Rust/Bevy migration plan clarifies whether the old Unity C# tests remain useful. * Once the path is reliable, wire it into required CI and update docs to say it is required. Acceptance: * A documented required-CI design exists for the C# / NuGet checks. * The implementation is green repeatedly before being marked required. * The checks are bounded and diagnosable, not a long-running silent restore sink.

coilyco-ops added the

labels

2026-07-10 09:00:46 +00:00

coilysiren referenced this issue from coilyco-flight-deck/ward

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

coilyco-ops commented

2026-07-22 06:43:05 +00:00

Author

Owner

Run 105 settles the open proxy question. Required container-native mod packaging reproduced the same NU1301 failure as #69: dotnet restore spent about 10 minutes waiting for the public NuGet v3 service index, then failed before any per-mod publish job started. The old retry mitigation was already retired because it created 20 to 40 minute sinks.

The durable prerequisite is now tracked in coilyco-flight-deck/infrastructure#571: deploy and live-verify an internal NuGet v3 caching proxy reachable from the Forgejo Docker and Docker-build runner paths. Once that endpoint exists, eco-app should add the smallest NuGet.Config consumer change and restore the compile/package path to required CI without retry loops.

Run 105 settles the open proxy question. Required container-native mod packaging reproduced the same NU1301 failure as #69: `dotnet restore` spent about 10 minutes waiting for the public NuGet v3 service index, then failed before any per-mod publish job started. The old retry mitigation was already retired because it created 20 to 40 minute sinks. The durable prerequisite is now tracked in coilyco-flight-deck/infrastructure#571: deploy and live-verify an internal NuGet v3 caching proxy reachable from the Forgejo Docker and Docker-build runner paths. Once that endpoint exists, eco-app should add the smallest `NuGet.Config` consumer change and restore the compile/package path to required CI without retry loops.

coilyco-ops referenced this issue from coilyco-flight-deck/infrastructure

2026-07-22 06:51:20 +00:00

Add an allowlisted egress proxy for Forgejo Actions runner jobs #563

coilyco-ops commented

2026-07-22 06:51:35 +00:00

Author

Owner

Correction to the prior infrastructure link: the canonical blocker is coilyco-flight-deck/infrastructure#563. An earlier Telegram investigation already reproduced destination-sensitive TLS failure from the Forgejo runner DinD network while ordinary Kubernetes pods remained healthy. api.nuget.org is now the second affected destination. The narrower infrastructure#571 NuGet-cache issue is closed as a duplicate.

A NuGet cache may still be useful later for speed and resilience, but required CI first needs the shared DinD egress path repaired or consistently proxied, including cold-cache restores.

Correction to the prior infrastructure link: the canonical blocker is coilyco-flight-deck/infrastructure#563. An earlier Telegram investigation already reproduced destination-sensitive TLS failure from the Forgejo runner DinD network while ordinary Kubernetes pods remained healthy. `api.nuget.org` is now the second affected destination. The narrower infrastructure#571 NuGet-cache issue is closed as a duplicate. A NuGet cache may still be useful later for speed and resilience, but required CI first needs the shared DinD egress path repaired or consistently proxied, including cold-cache restores.

coilyco-ops referenced this issue

2026-07-22 07:14:02 +00:00

ci: route the Eco image build through the runner egress proxy #142

coilyco-ops commented

2026-07-22 07:46:20 +00:00

Author

Owner

The first full required-path verification is green. Workflow-dispatch run 107 completed in 11m03s on commit 58ab8bd. The container image built successfully with its C# NuGet restores routed through the infrastructure-owned allowlisted proxy, and all four independent mod package jobs succeeded. This issue remains open because its acceptance criteria call for repeated green evidence and the broader required-CI design decision.

The first full required-path verification is green. Workflow-dispatch run 107 completed in 11m03s on commit 58ab8bd. The container image built successfully with its C# NuGet restores routed through the infrastructure-owned allowlisted proxy, and all four independent mod package jobs succeeded. This issue remains open because its acceptance criteria call for repeated green evidence and the broader required-CI design decision.

coilyco-ops referenced this issue

2026-07-25 13:36:45 +00:00

[interactive] Resolve remaining Eco App decisions and live checkpoints #155

coilyco-ops referenced this issue from a commit

2026-07-26 00:35:27 +00:00

fix: retire stale Eco compatibility gates

coilyco-ops closed this issue

2026-07-26 00:35:27 +00:00

coilyco-ops commented

2026-07-26 00:35:49 +00:00

Author

Owner

Policy selected and landed in e042ea5.

Compilation stays one required build-image gate because one application image carries one coherent set of mod packages.
Publication remains split per mod with fail-fast disabled, so registry status is isolated without recompiling.
The shared image build is bounded at 30 minutes and each publisher at 20 minutes.
docs/mod-packages.md now records the contract.

The first required-path success was followed by repeated successful full workflow runs, including 114, 115, 118, 119, 121, 122, 124, 126, 127, and the current-main run 133. The combined compile plus split publish shape is both repeated and diagnosable.

Policy selected and landed in `e042ea5`. * Compilation stays one required `build-image` gate because one application image carries one coherent set of mod packages. * Publication remains split per mod with fail-fast disabled, so registry status is isolated without recompiling. * The shared image build is bounded at 30 minutes and each publisher at 20 minutes. * `docs/mod-packages.md` now records the contract. The first required-path success was followed by repeated successful full workflow runs, including 114, 115, 118, 119, 121, 122, 124, 126, 127, and the current-main run 133. The combined compile plus split publish shape is both repeated and diagnosable.

Rows
Columns

Design a real required CI path for C# / NuGet checks #111