Joseph Doherty
5c8075996f
Acceptance-check finding (concurrency): the worktree lock in windev-worker-ci.ps1 guarded the build stage, but run-windev-ci.sh's bootstrap did git fetch + git checkout on the shared C:\build\mxaccessgw-ci clone BEFORE that lock was taken. Two concurrent runs therefore collided on .git/index.lock at the bootstrap stage (the second failed 'Another git process seems to be running', exit 1) instead of the second waiting — defeating the lock's purpose for manual/degraded-mode overlap or a future second runner. (The single Gitea runner serializes jobs, so CI pushes never actually overlapped; this is defense-in-depth being restored.) Fix: the bootstrap now acquires the same mkdir worktree lock around its fetch/ checkout and exports MXGW_CI_LOCK_HELD; windev-worker-ci.ps1 re-uses that lock (skips re-acquire/release) when the env is set, and still self-locks for a standalone/manual run. Now the second concurrent run waits at the bootstrap.
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 secret
WINDEV_SSH_KEY— store the private key base64-encoded on a single line:base64 -w0 < ci_windev(macOS:base64 < ci_windev | tr -d '\n'). This is required, not cosmetic — Gitea's secret masker is line-oriented, so a raw multiline PEM is not redacted in the stepenv:echo and leaks in cleartext; the single-line base64 masks to***.run-windev-ci.shauto-decodes it. Host keys are public and come from the committedwindev.known_hostspin, so noWINDEV_SSH_KNOWN_HOSTSsecret is wired intoci.yml.run-windev-ci.shconnects as userciby default; set theWINDEV_SSH_USERvariable (not a secret — it is public) to the actual account, and ensure that account exists on windev. - 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.