Windows test support — fast CI loop, analyzer green, web hang/login/store fixed

[gamesh411]

Progress

Set up a tight Windows CI feedback loop and worked the failures down layer by layer. Each push now gives a Windows-only result in ~4–10 min (instead of the old 1h+ matrix that cancelled after the web job hung for 30 min).

Feedback loop

• New .github/workflows/windows-iter.yml: runs only the two Windows jobs on pushes to this branch (+ workflow_dispatch), concurrency cancels superseded runs, actions/checkout@v4 / setup-python@v5.
• Added pytest-timeout to the analyzer & web dev requirements and run with --timeout --timeout-method=thread, so a hanging test fails fast with a thread stack dump instead of burning the job timeout.
• Removed the duplicate Windows jobs from test.yml (to be folded back once green).

Analyzer (Windows): ✅ GREEN (stable across 3 runs)

• Root cause: the official LLVM Windows package ships no diagtool, so get_warnings() returns nothing and the clang-diagnostic-* based checks fail. Fixed by skipping the 3 diagtool-dependent tests when diagtool is unavailable (same pattern as the existing python-ldap skips). All other CheckerHandlingClangTidy tests pass.

Web (Windows): hang + login + store-crash fixed; structural blockers remain

Confirmed by CI, in order of how the failures peeled off:

• 30-min hang eliminated / login works. The functional tests enable server auth and relied on HOME redirection so the client finds the throw-away credentials. On Windows os.path.expanduser("~") ignores HOME, so the client fell back to an interactive getpass() and hung forever. Fixed by redirecting CC_PASS_FILE/CC_SESSION_FILE into the test workspace and writing credentials there, plus stdin=subprocess.DEVNULL guards on the test subprocesses. CI now logs Server reported successful authentication on Windows.
• Store crash fixed. CC_FORCE_SYNC_STORE (used by the tests) wrapped massStoreRun in a signal.SIGUSR1 watchdog; SIGUSR1 doesn't exist on Windows so even referencing it crashed the store. Now falls back to a plain synchronous store when the signal is unavailable (POSIX unchanged).

Remaining blockers (both structural, surfaced fast by the new loop)

1. Build logging unsupported on Windows. test_garbage_file_collection builds a project via CodeChecker check -b, which uses CodeChecker log; this is explicitly unsupported on Windows (analyzer/.../buildlog/build_manager.py). The test can't produce reports on Windows as written.
2. Forced-sync store hangs server-side. Once past the SIGUSR1 crash, the synchronous massStoreRun does not return on Windows (the test now hits the 300s pytest-timeout inside store's p.wait() rather than hanging the whole job). Needs investigation into the server-side store/background-task path on Windows.

Proposed next steps

1. Rework the web functional path to avoid CodeChecker log on Windows: feed a pre-generated compile_commands.json and drive CodeChecker analyze + store directly. This unblocks producing reports.
2. Investigate the synchronous massStoreRun server-side hang on Windows (or prefer the async store path the tests can also use).
3. Expand the web job from the single test to the db_cleanup module, then the full tests/functional suite, using the fast-timeout loop.
4. Fold the Windows jobs back into test.yml and flip continue-on-error: false once green.

Verified this iteration

• Analyzer (Windows) CI: ✅ green (3 diagtool tests skipped, rest pass), stable across runs.
• Web (Windows) CI: 30-min hang gone; login + store-crash fixed; now fails fast at the unsupported build-logging step / sync-store hang.
• All changed Python validated on Linux (pycodestyle; the affected analyzer unit tests and the test_garbage_file_collection functional test still pass with diagtool/POSIX paths exercised).