Skip to content

feat(ci): publish Gateway MSIX releases - #32

Closed
RomneyDa wants to merge 3 commits into
chore/document-artifact-signing-setupfrom
feat/publish-gateway-msix-release
Closed

feat(ci): publish Gateway MSIX releases#32
RomneyDa wants to merge 3 commits into
chore/document-artifact-signing-setupfrom
feat/publish-gateway-msix-release

Conversation

@RomneyDa

@RomneyDa RomneyDa commented Sep 12, 2026

Copy link
Copy Markdown
Member

Summary

  • derive official MSIX identity versions from the reviewed Gateway tag (v2026.9.42026.9.4.0, v2026.7.1-22026.7.1.2)
  • validate that the approved Gateway tag, commit, payload version, MSIX version, hashes, manifests, and file inventories agree before signing
  • compose and test an x64/ARM64 .msixbundle on every workflow run, then recursively sign it with Azure Artifact Signing for official releases
  • create the corresponding tag and GitHub Release on successful official runs
  • publish the signed bundle and standalone packages as permanent, versioned release assets
  • prepend package/download details to GitHub-generated release notes
  • reject prerelease tags until they have a Windows-safe upgrade-order mapping

This PR is stacked on #24. Merge #24 first; GitHub will then retarget this PR to main automatically.

Why .msixbundle, not .appinstaller

The bundle is the installable artifact: it carries both architecture packages and lets Windows select the correct one. An .appinstaller is 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
  • Ruby YAML parse of .github/workflows/gateway-msix.yml
  • PowerShell bundle/version/policy/workflow tests and real MakeAppx bundle composition run in GitHub Actions
  • authorization opens the unsigned bundle, verifies its identity/package manifest, and byte-compares both embedded MSIX files with the independently authorized standalone packages; the test suite proves a substituted embedded package is rejected
  • x64, ARM64, NativeAOT, package, and CodeQL validation run in GitHub Actions

Worked on by

@clawsweeper

clawsweeper Bot commented Sep 12, 2026

Copy link
Copy Markdown

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review in progress

ClawSweeper is reviewing this revision. This supersedes any previous blocked status.

View the workflow run.

@clawsweeper clawsweeper Bot added P2 Normal priority bug or improvement with limited blast radius. merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. merge-risk: 🚨 security-boundary 🚨 Merging this PR could weaken sandboxing, authorization, credentials, or sensitive data. rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. labels Sep 12, 2026
@clawsweeper

clawsweeper Bot commented Sep 12, 2026

Copy link
Copy Markdown

Codex review: blocked before merge. Reviewed September 11, 2026, 9:56 PM ET / September 12, 2026, 01:56 UTC (Revision 2).

ClawSweeper review

What this changes

The 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
Reviewed head: 546bc513395343753d94f745a3089ee46d77ecc7
Owner decision: Required. See Decision needed.

Review scores

Measure Result What it means
Overall readiness 🐚 platinum hermit (4/6) The patch is focused and addresses the previous authorization concern; installation compatibility remains the material validation gap.
Proof confidence 🌊 off-meta tidepool Not applicable: The member author is exempt from ordinary contributor proof. The new content checks resolve the specific bundle-substitution uncertainty behind the prior authority-proof request, so that request is not carried forward automatically; Windows installation compatibility remains a separate review requirement.
Patch quality 🐚 platinum hermit (4/6) No actionable review findings were identified.

Verification

Check Result Evidence
Real behavior Not applicable Not applicable: The member author is exempt from ordinary contributor proof. The new content checks resolve the specific bundle-substitution uncertainty behind the prior authority-proof request, so that request is not carried forward automatically; Windows installation compatibility remains a separate review requirement.
Evidence reviewed 10 items Pinned contribution and current-main boundary: The host identifies c4f56ba..546bc51 as the introduced delta. Current main retains standalone signing and short-lived artifacts without the new bundle or publish-release job.
Previous authority concern addressed: The current validator checks bundle identity, exactly two distinct architecture entries, their filenames and versions, and SHA-256 equality with authorized standalone packages. The workflow requires authorization success before entering the protected signing job, which downloads the same named artifacts from the current run.
Regression coverage and review continuity: The latest commit adds a substituted embedded-package rejection test using the production validator. This addresses the earlier request to bind bundle contents to authorized inputs. The tests construct ZIP fixtures; they do not establish Windows installation or standalone-to-bundle upgrade behavior.
Findings None None.
Security None None.

How this fits together

This 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]
Loading

Decision needed

Question Recommendation
What installation evidence is required before making the signed bundle the recommended release download? Require installation and upgrade results: Record fresh-install and existing-standalone-to-bundle upgrade results before accepting the release path.

Why: Build and authorization checks establish package composition, but do not settle Windows servicing compatibility for existing installations.

Before merge

  • Resolve merge risk (P1) - The new recommended bundle and release-derived version scheme have no supplied Windows fresh-install or existing-standalone upgrade results; an installation transition failure could require manual recovery.
  • Complete next step (P2) - Resolve the Windows installation and upgrade evidence requirement, and land the prerequisite signing setup PR chore(ci): finalize Artifact Signing setup #24 before this stacked PR.
  • Resolve maintainer decision - Resolve the maintainer decision shown above before merge.
Agent review details

Security

None.

Review metrics

Metric Value Why it matters
Code growth Production scripts +262/-1; tests and workflow-contract checks +269/-3; workflow +212/-4 The growth supports the stated bundle construction, authorization, versioning, and release-publication scope.

Merge-risk options

Maintainer options:

  1. Establish the Windows servicing transition (recommended)
    Provide installation and upgrade results before recommending the bundle to existing users.
  2. Stage bundle adoption separately
    Keep standalone packages as the initial release path while bundle compatibility remains unverified.

Technical review

Best 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.

Labels

Label changes:

  • add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
  • add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The member author is exempt from ordinary contributor proof. The new content checks resolve the specific bundle-substitution uncertainty behind the prior authority-proof request, so that request is not carried forward automatically; Windows installation compatibility remains a separate review requirement.
  • remove rating: 🦐 gold shrimp: Current PR rating is rating: 🐚 platinum hermit, so this older rating label is no longer current.
  • remove status: 📣 needs proof: Current PR status label is status: 👀 ready for maintainer look.
  • remove merge-risk: 🚨 security-boundary: Current PR review merge-risk labels are merge-risk: 🚨 compatibility.

Label justifications:

  • P2: Permanent Windows package distribution is a bounded improvement without evidence of an urgent production regression.
  • merge-risk: 🚨 compatibility: The recommended installation format and official version scheme change without supplied Windows upgrade results.
  • rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
  • status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: The member author is exempt from ordinary contributor proof. The new content checks resolve the specific bundle-substitution uncertainty behind the prior authority-proof request, so that request is not carried forward automatically; Windows installation compatibility remains a separate review requirement.

Evidence

What I checked:

  • Pinned contribution and current-main boundary: The host identifies c4f56ba..546bc51 as the introduced delta. Current main retains standalone signing and short-lived artifacts without the new bundle or publish-release job. (.github/workflows/gateway-msix.yml:620, 6f89905a5349)
  • Previous authority concern addressed: The current validator checks bundle identity, exactly two distinct architecture entries, their filenames and versions, and SHA-256 equality with authorized standalone packages. The workflow requires authorization success before entering the protected signing job, which downloads the same named artifacts from the current run. (scripts/Test-SigningInputs.ps1:348, 546bc5133953)
  • Regression coverage and review continuity: The latest commit adds a substituted embedded-package rejection test using the production validator. This addresses the earlier request to bind bundle contents to authorized inputs. The tests construct ZIP fixtures; they do not establish Windows installation or standalone-to-bundle upgrade behavior. (scripts/Test-SigningInputs.Tests.ps1:548, 546bc5133953)
  • Upgrade-sensitive distribution change: Official builds switch from run-derived 0.x versions to Gateway release versions, and the recommended download becomes a bundle. Standalone downloads remain available and automatic updates are explicitly excluded. The supplied body reports build and policy validation, but contains no fresh-install or existing-install upgrade results. (README.md:177, 546bc5133953)
  • Release availability: The repository releases endpoint returned an empty list; no shipped release was available to establish this capability as already implemented.
  • Stack dependency and human discussion: The supplied body explicitly stacks this work on the still-open signing setup PR chore(ci): finalize Artifact Signing setup #24. The subsequent member comment requests re-review and adds no installation evidence.

Likely related people:

  • Linus Huang: Raw commit c3fc553 adds scripts/Get-WorkflowPackageVersion.ps1:24 relative to its recorded parents. This identifies author metadata, not feature responsibility or a PR merger. (role: source-line author; confidence: high; commits: c3fc553c1301; files: scripts/Get-WorkflowPackageVersion.ps1)
  • RomneyDa: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

  • Provide redacted Windows fresh-install and existing-standalone-to-bundle upgrade results, including package identity, installed version, command aliases, and preservation of existing user state.

Rating scale

Score Internal tier Crab rank Meaning
6/6 S 🦀 challenger crab Exceptional readiness
5/6 A 🦞 diamond lobster Very strong readiness
4/6 B 🐚 platinum hermit Good normal PR; ordinary maintainer review
3/6 C 🦐 gold shrimp Useful, but confidence is limited
2/6 D 🦪 silver shellfish Proof or implementation needs work
1/6 F 🧂 unranked krab Not merge-ready
N/A NA 🌊 off-meta tidepool Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

  • ClawSweeper keeps one durable marker-backed review comment per issue or PR.
  • Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
  • A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
  • PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
  • Maintainers can also comment @clawsweeper review to request a fresh review only.
  • Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
  • Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
  • Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

History

Review history (1 earlier review cycle)
  • reviewed 2026-09-12T01:47:39.725Z sha eaf67d6 :: needs real behavior proof before merge. :: none

@RomneyDa

Copy link
Copy Markdown
Member Author

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Sep 12, 2026

Copy link
Copy Markdown

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

@clawsweeper clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR. and removed rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. merge-risk: 🚨 security-boundary 🚨 Merging this PR could weaken sandboxing, authorization, credentials, or sensitive data. labels Sep 12, 2026
@RomneyDa
RomneyDa deleted the branch chore/document-artifact-signing-setup September 12, 2026 07:30
@RomneyDa RomneyDa closed this Sep 12, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-risk: 🚨 compatibility 🚨 Merging this PR could break existing users, config, migrations, defaults, or upgrades. P2 Normal priority bug or improvement with limited blast radius. rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. status: 👀 ready for maintainer look ClawSweeper has no concrete contributor-facing blocker left for this PR.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant