feat(ci): publish Gateway MSIX releases - #32
Conversation
|
🦞👀 Pull request received. I will update this pull request when review starts. ClawSweeper review in progressClawSweeper is reviewing this revision. This supersedes any previous blocked status. |
|
Codex review: blocked before merge. Reviewed September 11, 2026, 9:56 PM ET / September 12, 2026, 01:56 UTC (Revision 2). ClawSweeper reviewWhat this changesThe PR adds release-derived Windows package versions, validates and signs a combined x64/ARM64 MSIX bundle, and publishes permanent GitHub Release downloads. Merge readiness⛔ Blocked before merge - 3 items remain Keep open: this remains useful work absent from current main, and the author is a repository member. The latest commit addresses the previous bundle-substitution concern; Windows installation and upgrade compatibility remain unverified. Priority: P2 Review scores
Verification
How this fits togetherThis repository packages the OpenClaw Gateway for Windows. Its workflow turns a reviewed upstream revision into architecture-specific packages, authorizes their contents, and signs the downloadable installation artifacts. flowchart TD
A[Reviewed Gateway revision] --> B[x64 and ARM64 packages]
B --> C[Combined installation bundle]
B --> D[Release policy and content checks]
C --> D
D --> E[Protected Azure signing]
E --> F[GitHub Release downloads]
F --> G[Windows installation or upgrade]
Decision needed
Why: Build and authorization checks establish package composition, but do not settle Windows servicing compatibility for existing installations. Before merge
Agent review detailsSecurityNone. Review metrics
Merge-risk optionsMaintainer options:
Technical reviewBest possible solution: Ship permanent signed downloads with verified Windows installation and standalone-to-bundle upgrades that preserve package identity, command aliases, and existing user state. Do we have a high-confidence way to reproduce the issue? Not applicable: this adds a release-distribution capability, and no concrete introduced runtime defect was established. Is this the best way to solve the issue? Yes, the existing packaging and signing pipeline is the appropriate place for permanent downloads; Windows servicing evidence is still needed to validate the bundle transition. AGENTS.md: not found in the target repository. Codex review notes: model internal, reasoning medium; reviewed against 6f89905a5349. LabelsLabel changes:
Label justifications:
EvidenceWhat I checked:
Likely related people:
Rank-up movesOptional improvements that raise the rating; they are not merge blockers.
Rating scale
Overall follows the weaker of proof and patch quality. Workflow
HistoryReview history (1 earlier review cycle)
|
|
@clawsweeper re-review |
|
🦞🧹 I asked ClawSweeper to review this item again. |
Summary
v2026.9.4→2026.9.4.0,v2026.7.1-2→2026.7.1.2).msixbundleon every workflow run, then recursively sign it with Azure Artifact Signing for official releasesThis PR is stacked on #24. Merge #24 first; GitHub will then retarget this PR to
mainautomatically.Why
.msixbundle, not.appinstallerThe bundle is the installable artifact: it carries both architecture packages and lets Windows select the correct one. An
.appinstalleris update-channel metadata pointing at hosted MSIX assets. This change intentionally does not opt installations into an automatic-update channel yet.Validation
git diff --check.github/workflows/gateway-msix.ymlWorked on by