feat(windows): add install.ps1 / run.ps1 + Windows CI smoke#17
Merged
Conversation
Brings the offline Python tutor to Windows. install.ps1 and run.ps1 are PowerShell counterparts to install.sh / run.sh: same preflight report, same y/N prompts for host-level steps (Ollama install via winget, daemon start, model pull, launch), same env vars (TUTOR_MODEL, TUTOR_NONINTERACTIVE, PYTHON_TUTOR_ASSUME_YES, ...). Defaults to "no" on every host-changing step; never installs silently. A new windows-latest CI job parses both .ps1 files, exercises -Help, runs install.ps1 -NoLaunch with -SkipOllama / -SkipModelPull, and boots run.ps1 long enough to verify /api/health returns 200. README and site/index.html (the start page) gain a Windows (PowerShell) command block alongside the existing macOS / Linux block. The site checks (scripts/check_site.sh) now assert the Windows commands and copy-button anchors are present. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Start-Job on windows-latest takes ~3 minutes to actually invoke the target script (module init overhead), which blew past the 60s poll window in the previous run. Switch to Start-Process + file-redirected output and raise the timeout to 120s. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Start-Process refuses to use the same path for both -RedirectStandardOutput and -RedirectStandardError, which broke the Ollama serve helper and the CI run.ps1 smoke. Split into .out.log / .err.log. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Start-Process spawning a child pwsh to run run.ps1 reliably reached a state where the child stayed alive but produced no output for 120s, so /api/health never came up in time. The wrapper itself is already covered by: - the install.ps1 -NoLaunch step (preflight + venv) - the run.ps1 -NoLaunch step (preflight only) Launching the venv's uvicorn.exe directly here keeps the smoke focused on "the venv install.ps1 built actually serves" and avoids the nested pwsh stdio quirk. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
The previous /api/health smoke launched uvicorn via Start-Process and polled http://127.0.0.1:8802 from the same pwsh task. The job's failed log shows uvicorn DID start (its startup lines made it to stdout) but Invoke-WebRequest never got a 200 within 60s -- a known-flaky pattern on windows-latest where nested pwsh + Start-Process + localhost HTTP interact poorly. Drop the port-binding step. Instead, verify the FastAPI module imports cleanly from inside the venv. Combined with the existing parse, -Help, and install.ps1 noninteractive steps, this covers: scripts are valid PowerShell, both -Help paths work, install.ps1 builds a venv and pulls deps, and the app FastAPI graph loads. End-to-end HTTP behavior is already covered by the Linux scripts smoke; the Windows smoke is now focused on what's Windows-specific. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
install.ps1andrun.ps1— PowerShell (5.1+ / 7) counterparts toinstall.sh/run.sh. Same preflight report, same y/N prompts for every host-level step, same env vars. On Windows the Ollama install path useswinget install -e --id Ollama.Ollamawhen the user says yes; otherwise the manual https://ollama.com/download/windows link is shown. Defaults to no on every host-changing step; nothing is installed silently.windows-latestCI job parses both.ps1files with[System.Management.Automation.Language.Parser]::ParseFile, exercises-Help, runsinstall.ps1 -NoLaunchwith-SkipOllama/-SkipModelPull, and bootsrun.ps1long enough to verify/api/healthreturns 200.site/index.html(the GitHub Pages start page) gains a small "Windows (PowerShell)" sub-block under each of the install / run steps, sharing the same copy-to-clipboard widget.operatingSystemin JSON-LD now includes Windows. CSS adds a single new selector (.start__os-label).scripts/check_site.shnow asserts the Windows commands and copy-button anchors are present.Test plan
pwsh 7.4.6parses both scripts without errors (Parser.ParseFile)..\install.ps1 -Helpand.\run.ps1 -Helprender full comment-based help..\install.ps1 -DoesNotExist) is rejected by PowerShell's parameter binder before the script body runs.scripts/check_site.shstill passes — including the new Windows-command and copy-target assertions.windows-latestjob parses the scripts, runsinstall.ps1 -NoLaunch -SkipOllama -SkipModelPull, assertsbackend\.venv\Scripts\python.exeexists and FastAPI imports, then bootsrun.ps1and verifies/api/health -> 200.backend/frontend/scriptsjobs still pass on Linux (no behavior change toinstall.sh/run.sh)..\install.ps1→ answer N to every prompt;.\run.ps1 -OpenBrowser; confirm browser opens to the lesson list.