Joseph Doherty
d769244ac0
The `windows`/`live-mxaccess` CI jobs were removed in abb0930 because Gitea
act_runner host-mode on Windows is broken and a runs-on gate with no runner
wedges the queue. This left the entire x86/net48 Worker + Worker.Tests tier
(and the live-MXAccess smoke) unguarded by CI.
Restore it without a native Windows runner: Linux jobs on ubuntu-latest (which
always schedule) SSH to windev (10.100.0.48), fetch+checkout the SHA under test
in an isolated clone C:\build\mxaccessgw-ci, run the x86 build/tests there, and
propagate the remote exit code back — so a Worker regression turns the job red
and an unreachable host fails loud (never stuck).
- scripts/ci/run-windev-ci.sh: Linux driver (key/known-hosts, UTF-16LE base64
EncodedCommand bootstrap, ssh, exit-code passthrough).
- scripts/ci/windev-worker-ci.ps1: windev stage — worktree lock, re-fetch/
checkout under lock, build|test|live modes; PS 5.1-safe, checks $LASTEXITCODE.
- scripts/ci/windev.known_hosts: pinned host keys for StrictHostKeyChecking.
- scripts/ci/README.md: operator bring-up + acceptance checklist.
- ci.yml: windows-x86 (per-push `test`) + nightly-windev (scheduled `live` +
on-failure Gitea issue); drop the removal note; fix header/cron comments.
TST-26 (same commit, by rule): correct docs/scripts that still describe the
removed jobs — GatewayTesting.md, Contracts.md, check-codegen.ps1 — and
reattribute the Generated/-commit guard (primary = check-codegen diff in the
portable job; secondary = windows-x86 net48 compile).
Mechanism hand-verified on windev: build->0, bogus-SHA->nonzero (lock released),
test->356 passed/0 failed in ~50s, ssh exit-code propagation confirmed. Merge
requires operator bring-up first (dedicated ci@ key + Gitea secrets) or the
per-push job is red every push — see scripts/ci/README.md.
Windows/x86 CI tier (TST-25)
The x86 / net48 Worker and its tests cannot build on a Linux runner, and a native Windows
act_runner is broken (host-mode writes each step's script to a path it can't resolve; a
runs-on gate with no runner wedges the queue forever). Instead, a Linux CI job SSHes to
windev (10.100.0.48) and runs the Worker build/tests there, propagating the remote exit
code back so a regression turns the job red.
Pieces
| File | Runs on | Role |
|---|---|---|
run-windev-ci.sh <build|test|live> |
Linux CI job | Writes the SSH key/known-hosts, base64-encodes a bootstrap, SSHes to windev, returns the remote exit code. |
windev-worker-ci.ps1 -Sha -Mode |
windev | Locks the CI clone, checks out the SHA, runs the x86 build / Worker.Tests / live smoke. |
windev.known_hosts |
committed | Pinned windev host keys so StrictHostKeyChecking=yes has no TOFU prompt. Host keys are public; committing is intentional. |
Modes are cumulative: build = x86 Worker build; test = build + Worker.Tests;
live = test + full-slnx build + live-MXAccess smoke (MXGATEWAY_RUN_LIVE_MXACCESS_TESTS=1).
CI jobs (.gitea/workflows/ci.yml): windows-x86 runs test per push/PR; nightly-windev
runs live on the 0 6 * * * schedule and opens a Gitea issue on failure.
One-time bring-up (operator — required before this lands on main)
Until these are done, windows-x86 is red on every push (no key → SSH fails). Do them
first, then merge.
- CI clone —
C:\build\mxaccessgw-ci, a fresh clone of the Gitea origin (done during TST-25 verification; recreate withgit clone https://gitea.dohertylan.com/dohertj2/mxaccessgw C:\build\mxaccessgw-ciif missing). Never the dirty Desktop checkout. - Dedicated CI key — generate a NEW ed25519 keypair for CI (do not reuse the operator's
personal windev key):
ssh-keygen -t ed25519 -f ci_windev -N ''. Appendci_windev.pubto the windev CI account'sauthorized_keys(optionally with a forcedcommand=limiting it to this bootstrap). - Gitea repo secrets — store the private key as
WINDEV_SSH_KEYand, optionally, the pinned host keys asWINDEV_SSH_KNOWN_HOSTS(the committedwindev.known_hostsis the fallback).run-windev-ci.shconnects as userciby default (WINDEV_SSH_USERto override); ensure that account exists on windev, or setWINDEV_SSH_USERto the intended one. - Network precheck — confirm the Gitea runner container (on the
traefikdocker network, host10.100.0.35) can reach10.100.0.48:22: a one-offnc -z -w5 10.100.0.48 22step. The network was created for gitea name resolution, not LAN egress, so verify. - Actions token — the
nightly-windevon-failure step creates a Gitea issue with the built-in token; confirm Actions tokens have issue-write on this repo.
Verifying it end-to-end (design's acceptance checks)
- Push a branch →
portable,java,windows-x86all green; windev's clone sits at the pushed SHA. - Deliberate red: add a failing
[Fact]toWorker.Tests, push, confirmwindows-x86goes red; revert. (Proves exit-code propagation — the whole point.) - Unreachable-host red: point at a bogus port / stop sshd, confirm the job fails fast, not hangs.
- Concurrency: push two branches back-to-back, confirm the second remote run waits on the lock.
- Nightly: trigger the schedule path, confirm
liveruns and a forced failure opens an issue. - Confirm no key material appears in job logs.
Degraded mode
If the tier is down for infra reasons, fall back to the manual windev worktree procedure
(isolated C:\build worktree, dotnet build/test -p:Platform=x86 by hand) per merge for
worker-touching changes until windows-x86 is green again. See docs/GatewayTesting.md.