CALM/.github/workflows/windows-build-experiment.yml at main · Eilodon/CALM · GitHub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
name: Windows build experiment (probe, not release)

# Manual-only feasibility probe for native Windows support. Every
# dependency that could plausibly break a Windows build compiles C/C++ via
# the `cc` crate (rusqlite `bundled`, the `onig` regex engine, ~24
# tree-sitter grammar crates) — all of that is `#[cfg(unix)]`-free in
# calm's own code (verified: only the shared-daemon `calm connect`/
# `--listen` path is Unix-gated, and callers already skip it on non-Unix —
# see crates/calm-server/src/daemon.rs and scripts/mcp-launcher.sh), so the
# only real unknown is whether every C dependency's build script is happy
# under MSVC. This workflow exists to answer that empirically instead of
# guessing. Run with:
#   gh workflow run windows-build-experiment.yml
on:
  workflow_dispatch:

jobs:
  probe:
    runs-on: windows-latest
    # Safety net added after the companion macos-x64-build-experiment.yml
    # probe hung for ~6 hours on an unbounded smoke-test wait until GitHub's
    # default 360-minute ceiling force-cancelled it (2026-07-15). This job's
    # own smoke test uses Stop-Process -Force with no blocking wait, so it
    # wasn't at risk the same way — this cap is just defense in depth.
    timeout-minutes: 15
    steps:
      - uses: actions/checkout@34e114876b0b11c390a56381ad16ebd13914f8d5 # v4

      - uses: dtolnay/rust-toolchain@29eef336d9b2848a0b548edc03f92a220660cdb8 # stable
        with:
          targets: x86_64-pc-windows-msvc

      - uses: Swatinem/rust-cache@e18b497796c12c097a38f9edb9d0641fb99eee32 # v2
        with:
          key: x86_64-pc-windows-msvc

      # Default features on purpose (embeddings, tier0-5, scip-overlay) —
      # same reasoning as scripts/mcp-launcher.sh's Tier 3 build: this is
      # the actual shape a release binary would ship, not a stripped-down
      # build that could pass while the real target fails.
      - name: Build (release, default features)
        run: cargo build --release --bin calm --target x86_64-pc-windows-msvc

      - name: Smoke test — binary runs and reports the right version
        run: |
          $bin = "target\x86_64-pc-windows-msvc\release\calm.exe"
          & $bin --version
          if ($LASTEXITCODE -ne 0) { throw "calm --version exited $LASTEXITCODE" }

      # `calm serve` without `--listen` never touches the Unix-only daemon
      # path — this is the code path every non-daemon MCP client actually
      # uses, and the one that matters for Windows support.
      - name: Smoke test — plain `calm serve` starts and exits cleanly on Ctrl+C equivalent
        run: |
          $proc = Start-Process -FilePath "target\x86_64-pc-windows-msvc\release\calm.exe" `
            -ArgumentList "serve","--project-root",".","--db-path","$env:TEMP\calm-win-probe.db" `
            -PassThru -RedirectStandardOutput "$env:TEMP\calm-win-probe.out" `
            -RedirectStandardError "$env:TEMP\calm-win-probe.err"
          Start-Sleep -Seconds 8
          if ($proc.HasExited) {
            Write-Host "--- stdout ---"; Get-Content "$env:TEMP\calm-win-probe.out" -ErrorAction SilentlyContinue
            Write-Host "--- stderr ---"; Get-Content "$env:TEMP\calm-win-probe.err" -ErrorAction SilentlyContinue
            throw "calm serve exited early (code $($proc.ExitCode)) instead of staying up"
          }
          Stop-Process -Id $proc.Id -Force