94 points jadenlemmon 3 days ago 32 comments
jadenlemmon 3 days ago | parent
This post covers how we added Windows to a test infrastructure built around Linux runners. The central problem was giving each test a clean, logged-in Windows desktop without waiting 2–3 minutes for a VM to boot.
We extended the device scheduler we already use for mobile testing. It maintains warm pools of Windows VMs on GCE. Each test claims a ready VM, uses it once, and releases it. The VM is then destroyed and replaced, rather than cleaned up for the next test.
The test code stays in a Linux pod. Playwright connects to browsers on the Windows machine over CDP, while WebdriverIO and Appium handle native apps through WinAppDriver. A small Go agent captures the desktop with FFmpeg and streams it over WebRTC for live viewing and recordings.
That separation lets a single test move between a browser and a native Windows app without requiring a separate Windows runner pipeline.
The trade-off is that we keep idle Windows VMs ready and install the app under test on every run. In exchange, tests don’t inherit another run’s files, registry changes, or saved sessions.
I’d love to answer any questions!
trollbridge 3 days ago | parent
Eventually it got to a point it could iterate very quickly and was really only constrained by total system RAM which meant a dozen at most copies could be running simultaneously.
mcoliver 3 days ago | parent
trollbridge 3 days ago | parent
rsolva 3 days ago | parent
alasano 3 days ago | parent
mcoliver 3 days ago | parent
There are so many unknowns and the ability for the agents to dynamically adjust and make decisions allows for some really powerful autonomous workflows.
c-hendricks 2 days ago | parent
mcoliver 2 days ago | parent
h4kunamata 2 days ago | parent
All those actions within my homelab are automated via Ansible and bash scripts (I only run Linux), I am only notified if something goes wrong like a backup failed.
I get it if you never worked in IT, that is fine, but you need zero AI to get the above fully automated.
Does Claude keep versioning of the changes?? I host my own repos via Forgejo, Ansible and the automation process consume the config files from there, one source of truth. If my whole setup burns with fire, I can bring everything back online from the offsite Ansible playbook located at Codeberg.
whalesalad 2 days ago | parent
I use Claude or codex to manage the entire thing, interchangeably. They keep detailed daily journals. They keep a central TODO.md up to date. They refresh stale docs or stale plans when new plans invalidate old decisions.
I have so many layers of backups and fail safes that I work entirely in yolo mode. It’s really insane what I’ve been able to deploy myself on nights and weekends. Stuff I’ve wanted to tackle for years but never got around to it.
blahgeek 3 days ago | parent
joinjune 3 days ago | parent
ranger_danger 3 days ago | parent
ProblemExplorer 3 days ago | parent
I don't use windows but have to run windows 11 VM to access special devices. I don't want to bother with licenses, although I have them, and creating a new incus QEMU VM from scratch everytime from an ISO takes ~5m, freeing me up from worrying about all the activation and license drama.
If the activation and license setup was easy/automated in QEMU, I would imagine snapshots would be way easier. I would prefer not needing to connect to the internet.
c-hendricks 3 days ago | parent
Your info might be like decades out of date, since windows 10 it's just been an overlay and locking out some appearance customizations (you can still set them via other means though).
ProblemExplorer 2 days ago | parent
c-hendricks 2 days ago | parent
1718627440 2 days ago | parent
defied 3 days ago | parent
madduci 3 days ago | parent
Luker88 3 days ago | parent
OneDeuxTriSeiGo 3 days ago | parent
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
jadenlemmon 3 days ago | parent
xlazom00 3 days ago | parent
msla 2 days ago | parent
fhn 2 days ago | parent
peter_d_sherman 1 day ago | parent
This article makes some excellent points!
If you've ever worked in, or alongside QA in commercial software environments, you know that being able to run a large amount of automated parallel Windows specific QA tasks is indeed a headache! And that's if an organization can accomplish that at all -- many organizations still use single human QA's and/or SDET's and still run many QA tasks manually... Of course, AI should/will help with some of this, but there still is the physical testing infrastructure to take into consideration... there are many barriers, not the least of which include such things as necessity for multiple Windows licences, setting up those Windows environments properly, instrumenting test harnesses properly, aggregating the results from multiple sources, etc., etc.
Phrased another way, there's a large market there -- if you can solve all or some of those problems, in whole or in part...
Anyway, an excellent article on this topic!