The windows-x86 acceptance check 'no key material in logs' failed: run #37's job log printed the full WINDEV_SSH_KEY PEM in the step env echo. Gitea's secret masker is line-oriented, so a multiline PEM rendered as one line with literal \n escapes never matches the real-newline secret value and is not redacted. Fix: store WINDEV_SSH_KEY base64-encoded (single line) so the masker redacts it to ***; run-windev-ci.sh auto-decodes a base64 PEM (still accepts a raw PEM for local hand-testing). Drop the redundant WINDEV_SSH_KNOWN_HOSTS from the job env (host keys are public and come from the committed windev.known_hosts pin), removing another cleartext env line. Document the base64 requirement in the bring-up README. Operationally: the previously-exposed CI key has been rotated on windev (old pubkey revoked from administrators_authorized_keys, new key installed) and the Gitea WINDEV_SSH_KEY secret replaced with the new key's base64.
4.1 KiB
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.