Skip to content

ci: windows arm e2e fix#1655

Open
zerob13 wants to merge 6 commits into
devfrom
codex/windows-arm-e2e-fix
Open

ci: windows arm e2e fix#1655
zerob13 wants to merge 6 commits into
devfrom
codex/windows-arm-e2e-fix

Conversation

@zerob13
Copy link
Copy Markdown
Collaborator

@zerob13 zerob13 commented May 21, 2026

Summary by CodeRabbit

  • New Features

    • CI smoke checks for DuckDB/VSS on Windows ARM64.
    • Playwright launch smoke plus packaged-app process-level smoke testing for Windows ARM64.
    • Automated collection of Windows ARM64 diagnostics (app logs, event logs, native module inventory).
    • Main-process logs attached to E2E test artifacts.
  • Documentation

    • Expanded Windows ARM64 support plans, specs, tasks, and rollout checklist.
  • Chores

    • Bumped DuckDB Node API and Sharp versions.

Review Change Stack

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 21, 2026

📝 Walkthrough

Walkthrough

This PR upgrades DuckDB for Windows ARM64, adds a DuckDB/VSS CI smoke test, changes the Windows ARM64 E2E workflow to run Playwright launch and a packaged-exe process smoke, collects extensive diagnostics on failure, enhances E2E fixtures to attach main-process logs, and updates related docs and release/build workflows.

Changes

Windows ARM64 DuckDB Support & E2E Diagnostics

Layer / File(s) Summary
DuckDB VSS Smoke Test Script & Dependencies
scripts/smoke-duckdb-vss.js, package.json
New DuckDB smoke-test script runs an in-memory instance, installs/loads the vss extension, and logs progress; package.json adds smoke:duckdb:vss, upgrades @duckdb/node-api to 1.5.3-r.1, and bumps sharp to ^0.34.5.
Windows ARM64 E2E Workflow: Smoke Tests & Diagnostics Collection
.github/workflows/windows-arm64-e2e.yml
CI workflow runs the DuckDB/VSS smoke check, executes a Playwright launch smoke test, validates the packaged DeepChat.exe process remains stable via PowerShell, then always collects filesystem listings, app logs, native module inventory, and Windows Event logs and uploads them as deepchat-win-arm64-e2e-diagnostics.
E2E Fixture Main-Process Log Capture
test/e2e/fixtures/electronApp.ts
Electron fixture imports filesystem APIs, limits log attachment size, discovers/reads/truncates per-platform main-process logs, and attaches combined main-process.log to Playwright artifacts.
Windows Release / Build Workflow Updates
.github/workflows/build.yml, .github/workflows/release.yml
Windows build job naming and runner labels updated; release workflow expands Windows matrix to include arm64, uses per-arch unpacked dirs for plugin verification, copies arm64 artifacts, and merges per-arch YAMLs for release assets.
Windows ARM64 & DuckDB Upgrade Strategy Documentation
docs/features/windows-arm64-support/*, docs/issues/windows-arm64-duckdb-upgrade/*
Plans, specs, and task lists added/updated to describe staged DuckDB upgrade, CI-focused E2E strategy, packaged-exe process verification, diagnostics to upload, and validation criteria.
Windows Release Build Architecture Docs
docs/issues/windows-release-build-arch/*
New plan/spec/tasks describing release build architecture changes for separate x64/arm64 artifacts, runner choices, and validation checklist.

Sequence Diagram(s)

sequenceDiagram
  participant CI as CI Workflow
  participant DuckDB as smoke:duckdb:vss
  participant Playwright as Playwright Launch Test
  participant PackagedExe as Packaged DeepChat.exe
  participant Diagnostics as Diagnostics Collection
  participant Upload as Artifact Upload
  
  CI->>DuckDB: Run DuckDB/VSS smoke test
  DuckDB-->>CI: INSTALL vss & LOAD vss success
  CI->>Playwright: Run launch.smoke.spec.ts
  Playwright-->>CI: Test artifacts, logs captured
  CI->>PackagedExe: Start process, wait for stability
  PackagedExe-->>CI: Process remains alive
  CI->>Diagnostics: Collect filesystem/logs/events
  Diagnostics-->>CI: Diagnostics prepared
  CI->>Upload: Upload deepchat-win-arm64-e2e-diagnostics
  Upload-->>CI: Artifact stored
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

  • ThinkInAIXYZ/deepchat#1522: Modifies test/e2e/fixtures/electronApp.ts to attach renderer/main diagnostics to e2e artifacts, on which this PR's fixture enhancements build.
  • ThinkInAIXYZ/deepchat#1653: Related Windows ARM64 E2E workflow refinements; overlaps in smoke-test sequencing and diagnostics collection.
  • ThinkInAIXYZ/deepchat#511: Earlier sharp installation/build plumbing; relevant because this PR bumps sharp.

Poem

🐰 A rabbit tests with DuckDB bright,

installs VSS to make things right,
logs and events in a tidy stack,
ARM64 boots the app — no flak,
CI hops forward, tail in sight.

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (1 warning, 1 inconclusive)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check ❓ Inconclusive The PR title 'ci: windows arm e2e fix' is vague and lacks specificity about what the fix addresses or which components are changed. Replace with a more descriptive title that clarifies the specific changes, such as 'ci: add duckdb/vss smoke test and process diagnostics to windows arm64 e2e workflow' or similar.
✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch codex/windows-arm-e2e-fix

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
.github/workflows/release.yml (2)

429-454: ⚖️ Poor tradeoff

Consider extracting the YAML merge logic to reduce duplication.

The merge_windows_yml function (lines 429-454) is nearly identical to merge_mac_yml (lines 483-508), differing only in the input directory paths. This code duplication makes maintenance harder.

While fixing this would require refactoring both merge functions into a single parameterized helper, it would improve maintainability for future updates to the merge logic.

♻️ Example refactored approach
+         merge_platform_yml() {
+           local name="$1"
+           local platform="$2"
+           local x64="artifacts/deepchat-${platform}-x64/$name"
+           local arm64="artifacts/deepchat-${platform}-arm64/$name"
+           if [ -f "$x64" ] && [ -f "$arm64" ]; then
+             ruby -ryaml -e '
+               x64 = YAML.load_file(ARGV[0]) || {}
+               arm = YAML.load_file(ARGV[1]) || {}
+               merged = x64.dup
+               merged["version"] ||= arm["version"]
+               merged["releaseDate"] ||= arm["releaseDate"]
+               merged["releaseNotes"] ||= arm["releaseNotes"]
+               merged["path"] ||= arm["path"]
+               merged["sha512"] ||= arm["sha512"]
+               files = []
+               files.concat(x64["files"]) if x64["files"].is_a?(Array)
+               files.concat(arm["files"]) if arm["files"].is_a?(Array)
+               merged["files"] = files.uniq { |f| f["url"] }
+               File.write(ARGV[2], merged.to_yaml)
+             ' "$x64" "$arm64" "release_assets/$name"
+           elif [ -f "$x64" ]; then
+             cp "$x64" "release_assets/$name"
+           elif [ -f "$arm64" ]; then
+             cp "$arm64" "release_assets/$name"
+           fi
+         }
+
-         merge_windows_yml() {
-           local name="$1"
-           local x64="artifacts/deepchat-win-x64/$name"
-           local arm64="artifacts/deepchat-win-arm64/$name"
-           ...
-         }

-         merge_windows_yml latest.yml
-         merge_windows_yml beta.yml
+         merge_platform_yml latest.yml win
+         merge_platform_yml beta.yml win

Then replace merge_mac_yml calls similarly.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml around lines 429 - 454, The merge_windows_yml
function duplicates the YAML-merge logic in merge_mac_yml; extract the common
Ruby/YAML merge logic into a single parameterized helper (e.g., merge_yml) that
accepts the two source paths and output path/name, then have merge_windows_yml
and merge_mac_yml call that helper with their platform-specific input
directories (x64/arm64 or darwin/x64/arm64) so the Ruby snippet and file
existence/copy handling are implemented once and reused.

124-124: ⚡ Quick win

Refute invalid-runner concern for windows-2025-vs2026
GitHub-hosted Windows runner label windows-2025-vs2026 is a documented/available label (used for testing the Windows Server 2025 + Visual Studio 2026 image before the main migration). It shouldn’t cause the job to fail due to an unknown runner.

  • If the intent is the default/stable Windows 2025 image, consider switching to windows-2025/windows-latest; if the intent is to target the VS2026 image early, keep as-is.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/release.yml at line 124, The runner label
"windows-2025-vs2026" in the workflow may be intentional for testing the VS2026
image; either leave the runner as-is if you want the pre-release Visual Studio
2026 image, or replace the runner value in the workflow definition with a stable
label such as "windows-2025" or "windows-latest" to target the default/stable
Windows 2025 image and avoid any unknown-runner concerns.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/release.yml:
- Around line 429-454: The merge_windows_yml function duplicates the YAML-merge
logic in merge_mac_yml; extract the common Ruby/YAML merge logic into a single
parameterized helper (e.g., merge_yml) that accepts the two source paths and
output path/name, then have merge_windows_yml and merge_mac_yml call that helper
with their platform-specific input directories (x64/arm64 or darwin/x64/arm64)
so the Ruby snippet and file existence/copy handling are implemented once and
reused.
- Line 124: The runner label "windows-2025-vs2026" in the workflow may be
intentional for testing the VS2026 image; either leave the runner as-is if you
want the pre-release Visual Studio 2026 image, or replace the runner value in
the workflow definition with a stable label such as "windows-2025" or
"windows-latest" to target the default/stable Windows 2025 image and avoid any
unknown-runner concerns.

ℹ️ Review info
⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: fda9565d-6396-42c4-9229-adfe8f08921c

📥 Commits

Reviewing files that changed from the base of the PR and between b269bc3 and 676abe2.

📒 Files selected for processing (5)
  • .github/workflows/build.yml
  • .github/workflows/release.yml
  • docs/issues/windows-release-build-arch/plan.md
  • docs/issues/windows-release-build-arch/spec.md
  • docs/issues/windows-release-build-arch/tasks.md
✅ Files skipped from review due to trivial changes (2)
  • docs/issues/windows-release-build-arch/tasks.md
  • .github/workflows/build.yml

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant