Stop ssh consuming the test driver's stdin - #107
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
WalkthroughThe SSH commands in three Nix VM tests now use ChangesSSH stdin handling
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
Adds
-nto the fivesshinvocations in the VM tests. Fixescheck (adminaccess-bringup)hanging in CI until the 30-minute job timeout.Root cause
machine.succeed()runs its command through a shell on the VM's backdoor serial channel.sshwithout-nreads that channel's stdin, so it swallows the driver's own protocol stream. The command completes in the guest while the driver waits forever for a completion marker that ssh already consumed.The CI log shows exactly that.
box.succeed(f"{ssh} keepadmin@{lan} sudo -n true")starts at 00:58:11, and the guest reports:Session opened and closed at t+18.9s. The driver then printed nothing for 29 minutes, until the runner cancelled the job. The guest did the work; the driver never heard about it.
It is a race, which is why it passes locally and hangs in CI.
Scope
Five invocations across three files had the same shape, not just the one that was failing:
tests/adminaccess-bringup.nixtests/mesh-admin-ssh.nixtests/yubikey-ssh.nixThe other four pass today on the same coin-flip. Fixed all five rather than the symptom. None of them feed stdin: every command is
trueorsudo -n true, so-nchanges nothing about intent.Why this went unnoticed
Across the last 25 CI runs, no execution of
check (adminaccess-bringup)exceeded 3 minutes except the two that exposed this. Every other run was the fast lane, where the VM tests do not execute, and the job reports success in about 65s because it is a no-op there. The admin-access path, SSH and YubiKey, has had the appearance of CI coverage without the substance.Test plan
Run locally with KVM, on this branch:
adminaccess-bringup: PASS (the test that hangs in CI)yubikey-ssh: PASSmesh-admin-ssh: PASS, and 3/3 on forced--rebuildrepeatsmesh-admin-sshonb766ecdwithout-n: PASS, confirming the comparison is meaningfulnix fmtreports 0 changedfull-ciOne honest note on the measurement: the very first
mesh-admin-sshrun on this branch failed, which I initially reported as-nbreaking it. It did not reproduce in four subsequent runs, and that first run executed immediately after another VM test in the same invocation. The failure is not attributable to this change, butmesh-admin-sshmay have a pre-existing flake under load, which is worth watching separately.Unblocks #106, whose only remaining failure is this hang.
Summary by CodeRabbit