Fix MistDemo Integration static build for Swift 6.4

[leogdion]

Summary

• Unblocks PR #459 / the failing Build static mistdemo job (tools-version 6.4 vs swift:6.3.2).
• Pins MistDemo-Integration.yml to swiftlang/swift:nightly-6.4.x-noble plus the matching 6.4.x-branch Static Linux SDK (musl), SyndiKit-style.
• Keeps --swift-sdk x86_64-swift-linux-musl, artifact path, and static linkage verify.

Test plan

• Build static mistdemo succeeds on this branch (or after merge into v1.0.0-beta.5)
• Artifact still reports musl/not a dynamic executable in Verify static linkage
• Live CloudKit Integration still runs when secrets are present

Made with Cursor

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 4402956c-557b-4602-8c2a-ed32680de5da

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review

Scope: single-file CI workflow change (.github/workflows/MistDemo-Integration.yml), pinning the build job to a Swift 6.4 nightly toolchain + matching Static Linux SDK snapshot to unblock #459. No Swift source changes, so this is purely a CI/reproducibility review.

Main concern — the container isn't actually pinned

The comment claims "Pin nightly container + 6.4.x-branch Static Linux SDK together," but only the SDK half is truly pinned:

• swift sdk install uses a dated snapshot URL (...-DEVELOPMENT-SNAPSHOT-2026-09-01-a...) + a 64-hex-char checksum — this is immutable and reproducible. ✅
• container: swiftlang/swift:nightly-6.4.x-noble is a floating tag — Swift's nightly images are rebuilt daily under the same tag, so this line will silently resolve to a different toolchain build every day without any diff to this file.

That mismatch is a real risk given the PR's own stated goal (build stability): if the container's compiler drifts ahead of the 2026-09-01 SDK snapshot, swift build --swift-sdk x86_64-swift-linux-musl can start failing on toolchain/SDK version-manifest mismatches with no corresponding code or workflow change to point to — exactly the kind of hard-to-diagnose CI flakiness this PR is trying to avoid on the 6.3.2 → 6.4 jump. Since GHCR/Docker Hub images are content-addressable, consider pinning by digest instead:

container: swiftlang/swift:nightly-6.4.x-noble@sha256:<digest>

and bumping the digest alongside the SDK snapshot when needed. If "SyndiKit-style" pinning intentionally accepts the floating tag as a tradeoff, it'd be worth a one-line comment saying so explicitly, since the current wording ("pinned... together") reads as a stronger guarantee than what's actually enforced.

Minor

• The rationale for the nightly container ("no 6.4 RELEASE image yet") and the "bump together" instruction are stated twice — once in the file header (lines ~20–26) and again right above container: (lines ~51–53). Not wrong, just slightly redundant; could collapse to one spot.
• Nightly-snapshot toolchains carry inherent regression risk vs. a release build — already acknowledged in the PR description as a temporary state until Apple ships a 6.4 release image, so no action needed, just flagging for the reviewer's awareness.

Other checks

• Checksum format: both the old and new SDK checksums are valid 64-hex-char SHA-256 values. ✅
• integration job is untouched and correctly stays on plain ubuntu-24.04 with no toolchain — unaffected by this bump. ✅
• No secrets/security changes; the "no pull_request trigger" note in the header still holds. ✅
• Test coverage: N/A (workflow-only change) — the PR's own checklist ("Build static mistdemo succeeds," "artifact still musl," "Live CloudKit Integration still runs") is the right verification and should be confirmed green before merge.

Overall: reasonable, well-commented unblock for the 6.4 tools-version bump. The one thing I'd want addressed (or explicitly accepted) before merge is the floating-vs-pinned container tag, since it undercuts the stated goal of a fully pinned, reproducible build.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.49%. Comparing base (e678b41) to head (b81e025).

Additional details and impacted files

@@                Coverage Diff                @@
##           v1.0.0-beta.5     #475      +/-   ##
=================================================
- Coverage          86.54%   85.49%   -1.05%     
=================================================
  Files                200      200              
  Lines               4882     4882              
=================================================
- Hits                4225     4174      -51     
- Misses               657      708      +51     

Flag	Coverage Δ
mistdemo-spm-macos	?
mistdemo-swift-6.4-jammy	?
mistdemo-swift-6.4-noble	?
spm	85.12% <ø> (-0.03%)	⬇️
swift-6.1-jammy	85.39% <ø> (+0.24%)	⬆️
swift-6.1-noble	85.37% <ø> (+0.10%)	⬆️
swift-6.2-jammy	85.28% <ø> (+0.04%)	⬆️
swift-6.2-noble	85.39% <ø> (+0.10%)	⬆️
swift-6.3-jammy	85.37% <ø> (+0.08%)	⬆️
swift-6.3-noble	85.33% <ø> (+0.04%)	⬆️
swift-6.4-jammy	85.12% <ø> (-0.05%)	⬇️
swift-6.4-noble	85.26% <ø> (-0.11%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[claude]

Review

Small, well-scoped CI-only change — pins the Build static mistdemo job to the 6.4 toolchain since MistDemo declares swift-tools-version: 6.4 and no 6.4 RELEASE image exists yet. This matches the precedent already established elsewhere in the repo (MistKit.yml, MistDemo.yml, examples.yml all use swiftlang/swift:nightly-6.4.x[-noble] for the 6.4 lane), so it's a reasonable, low-risk fix for the failing job blocking #459.

Nice touch: the Static Linux SDK snapshot is still checksum-pinned (swift sdk install --checksum ...), so supply-chain verification for the SDK download is preserved even though it moved from an exact release version to a dated development snapshot (2026-09-01-a). If the checksum is wrong/stale, swift sdk install fails loudly rather than silently accepting bad content, so this isn't a silent-corruption risk.

One thing worth flagging (not a blocker): the updated comment says "Pin nightly container + 6.4.x-branch Static Linux SDK together," but only the SDK side is actually content-pinned. swiftlang/swift:nightly-6.4.x-noble is a floating tag that gets overwritten by upstream nightly builds, so the compiler used by this job can drift on a re-run of the same workflow file, while the SDK snapshot stays fixed at 2026-09-01-a. Over enough time that combination could produce a toolchain/SDK ABI mismatch that's confusing to debug (build failures with no diff in this repo to point at). Since this same floating-tag pattern is already used elsewhere in the repo for the 6.4 lane, I don't think this PR needs to solve it — but it might be worth either pinning the container by digest (@sha256:...) if reproducibility here matters as much as it does for the release-branch pin discipline described in CLAUDE.md, or just softening the comment so it doesn't imply an exact pin that isn't there.

Minor: the PR description's test-plan checkboxes are all unchecked — worth confirming the static build + linkage check + live integration run actually went green before/after merge, since that's the entire point of this change and can't be verified from the diff alone.

No functional/library code touched, so no test coverage gap here — this is purely CI infra config.