feat: windows support — build-tag split for upgrade restart logic, zip-aware extractor, re-add to release matrix

[liuooo]

Problem

GOOS=windows go build ./... fails on main:

internal/upgrade.go:170:48: unknown field Setsid in struct literal of type syscall.SysProcAttr

internal/upgrade.go uses Unix-only restart logic (exec.Command("sh", "-c", ...) + syscall.SysProcAttr{Setsid: true}) with no build tags, so windows has never actually compiled — the README's former windows cross-compile example was aspirational. PR #38 briefly added windows to the GoReleaser matrix and had to back it out (caught by automated review; the matrix-lockstep guard test added there will fail loudly if one side is changed without the other).

Work needed to ship windows

1. Split the restart logic the way lock_unix.go / lock_windows.go already are: move the sh -c + Setsid path into upgrade_unix.go (//go:build !windows), add upgrade_windows.go with a real windows restart (or a documented unsupported error)
2. Make the self-upgrade extractor format-aware: internal/upgrade.go hardcodes upgrade-download.tar.gz and only imports archive/tar; windows release archives would be .zip
3. Re-add windows to .goreleaser.yaml goos + zip format_overrides, re-add the two win32 pairs to PLATFORMS in npm/scripts/prepare-packages.js (+ shim map and exe handling) — the guard test enforces both sides move together
4. Extend the CI cross-compile step in ci.yml with windows/amd64, windows/arm64
5. Consider a windows-latest CI leg that installs and runs the generated npm package end to end
6. Note: octo-fleet rejects windows remote upgrades in v1 (createDaemonUpgradeTask), so install-only support is shippable before the upgrade path is

Context

Split out of #37 / PR #38 (npm distribution), where windows packages were descoped to keep that PR release-logic-only.

[lml2468]

📋 Dispatch → product-analyst

Decision: type:feature 未携带 spec-ready 标签 → 进入 spec 阶段
Routed to: product-analyst (477cbd1f-677e-4a52-9765-5e6d67df9b6e)

任务要求

请为 Windows 支持 编写 spec，包含：

1. 使用场景与用户价值
2. 功能范围（build-tag split / zip-aware extractor / release matrix 的边界）
3. 非功能性需求（CI 兼容性、构建时间影响、包大小约束）
4. 验收标准

完成后请在 issue 上留 comment 并添加 spec-ready 标签。

---

assigned_to: product-analyst · stage: spec · waiting: spec 产出

[lml2468]

Feature Analysis

Stakeholders

• Windows developers using octo-daemon-cli on Windows workstations
• Release/CI engineering managing cross-platform release matrix
• Fleet operators (octo-fleet) dispatching upgrade tasks to Windows devices

User Scenario Assumptions

1. A Windows user installs octo-daemon via npm (npm install -g @mininglamp-oss/octo-daemon)
2. The daemon registers with the fleet server and receives tasks
3. When a new daemon version is released, the fleet dispatches an upgrade task
4. The daemon self-upgrades via npm install and restarts gracefully
5. CI catches any cross-platform breakage before release

Key Code References

• internal/upgrade.go:stopForRestart() uses proc.Signal(syscall.SIGTERM) — Unix-only constant, breaks GOOS=windows build
• internal/lock_unix.go / internal/lock_windows.go — existing build-tag split pattern to follow
• .goreleaser.yaml — currently darwin+linux only (windows intentionally absent per inline comment)
• npm/scripts/prepare-packages.js:PLATFORMS — guard test enforces lockstep with goreleaser
• .github/workflows/ci.yml — cross-compile step iterates darwin/amd64 darwin/arm64 linux/amd64 linux/arm64

Findings vs Issue Body

• Issue body point 2 ("Make the self-upgrade extractor format-aware: internal/upgrade.go hardcodes upgrade-download.tar.gz and only imports archive/tar") — the current upgrade.go does NOT import archive/tar or reference tar extraction. The daemon upgrade path now uses npm install -g (InstallDaemonNpm), not direct archive download+extract. This work item is likely obsoleted by the npm-based upgrade refactor.
• Issue body point 1 (build-tag split for restart logic) — still needed. stopForRestart() uses syscall.SIGTERM which doesn't exist on Windows.
• Issue body points 3-5 (goreleaser, npm platforms, CI) — still needed, configuration changes.
• Issue body point 6 (octo-fleet rejects windows remote upgrades) — noted as context, not in scope for this repo.

Open Questions (none blocking)

• Confirm tar/zip extractor work is obsoleted by npm-based upgrade path (will be validated during implementation — if no extraction code exists, this AC is simply dropped)

---

analysis_by: leader · next: GenSpec

[lml2468]

实现方案（待人工审批）

Goal: Enable Windows as a supported platform for octo-daemon-cli — build, release, CI, and npm distribution — following the existing build-tag split pattern established by lock_unix.go / lock_windows.go.

---

User Stories

• US1: As a Windows developer, I want to install octo-daemon via npm so I can run the daemon on my Windows workstation.
• US2: As a release engineer, I want GoReleaser to produce Windows binaries (zip archives) so they can be distributed via npm.
• US3: As a CI operator, I want the CI pipeline to cross-compile for Windows so platform-specific build failures are caught at PR time.
• US4: As a fleet operator, I want the daemon to restart gracefully on Windows after self-upgrade so the new binary takes effect without manual intervention.

---

Acceptance Criteria (Gherkin)

AC1: Build-tag split for restart logic

Given the internal/upgrade.go file
When GOOS=windows go build ./... is executed
Then the build succeeds without errors

Implementation:

• Extract stopForRestart() from upgrade.go into platform-specific files:
  • upgrade_restart_unix.go (//go:build !windows): current proc.Signal(syscall.SIGTERM) implementation
  • upgrade_restart_windows.go (//go:build windows): os.Exit(0) — clean exit, supervisor (pm2/scheduled task) respawns on new binary
• Keep upgrade.go with all shared logic (npm install, version checks, report)
• Follow the exact same pattern as lock_unix.go / lock_windows.go

AC2: GoReleaser produces Windows archives

Given a release tag is pushed
When GoReleaser runs
Then windows/amd64 and windows/arm64 zip archives are produced alongside darwin/linux tar.gz

Implementation:

• Add windows to goos in .goreleaser.yaml
• Add format_overrides for windows → zip
• Remove the inline comment block explaining windows absence
• Update archive name_template comment to note windows zip convention

AC3: npm packaging includes Windows platforms

Given the prepare-packages.js PLATFORMS array
When the guard test runs
Then it matches the goreleaser matrix including windows pairs

Implementation:

• Add two entries to PLATFORMS:
  • { goOs: "windows", goArch: "amd64", npmOs: "win32", npmCpu: "x64" }
  • { goOs: "windows", goArch: "arm64", npmOs: "win32", npmCpu: "arm64" }
• Update shim map for .exe binary handling on Windows
• Guard test (prepare-packages.test.js) must pass — it enforces goreleaser ↔ npm lockstep

AC4: CI cross-compiles for Windows

Given a PR targeting main
When the CI build job runs
Then windows/amd64 and windows/arm64 are included in the cross-compile matrix

Implementation:

• Add windows/amd64 and windows/arm64 to the cross-compile loop in .github/workflows/ci.yml
• Keep in lockstep with goreleaser goos/goarch

AC5: Self-upgrade restarts gracefully on Windows

Given the daemon is running on Windows
When a fleet-dispatched upgrade task completes npm install
Then the daemon exits cleanly (exit 0) and the supervisor restarts it on the new binary

Implementation: Covered by AC1 — stopForRestart() on Windows uses os.Exit(0).

---

Non-Functional Requirements

• Build time impact: negligible (2 additional cross-compile targets in CI, ~30s each)
• Package size: Windows zip archives comparable to tar.gz (no compression regression target)
• CI matrix-lockstep guard test must continue to fail loudly if goreleaser and npm PLATFORMS drift

---

Out-of-Scope

• windows-latest end-to-end CI leg (future enhancement — noted in issue body point 5)
• octo-fleet Windows remote upgrade integration (issue body point 6 — separate repo)
• Self-extracting archive mechanism (obsoleted by npm-based upgrade — see analysis)
• Legacy binary-swap upgrade path (already removed)

---

Open Questions

• tar/zip extractor format-awareness: Resolved during analysis — current upgrade path uses npm install -g, no archive extraction in upgrade.go. If any extraction code is discovered during implementation, it will be handled with platform-aware format selection (zip on windows, tar.gz elsewhere).

---

Risk Assessment

• Low risk: Build-tag split follows established lock_unix.go/lock_windows.go pattern
• Medium risk: npm shim map for Windows .exe handling — needs careful testing of the installer path
• Mitigation: Guard test ensures goreleaser ↔ npm lockstep; CI cross-compile catches build failures at PR time

---

spec_version: v1 · spec_by: leader · 审批通过后由 leader/engineer 实现

[github-actions]

This issue has been automatically marked as stale due to inactivity. Please add an update or it will be closed.

[github-actions]

Closing due to inactivity. If this is still an issue, please retry on the latest release and share updated details. If you are sure it still happens, open a new issue with fresh reproduction steps.