Add Swift Source Compatibility CI workflow

[leogdion]

Implements GitHub Actions workflow to test MistKit against multiple Swift toolchain versions (6.0, 6.1, 6.2, and 6.3-nightly) for source compatibility validation.

• Tests Swift 6.0, 6.1, 6.2 (stable) and 6.3-nightly
• Build-only approach using official Swift Docker containers
• Nightly failures allowed via continue-on-error flag
• Follows SyndiKit source compatibility suite pattern
• Runs on push to main, pull requests, and manual dispatch
• Uses explicit Swift 6 language mode for all builds

🤖 Generated with Claude Code

---

Perform an AI-assisted review on

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

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

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch 185-swift-source-compat-suite

---

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 and usage tips.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 14.29%. Comparing base (cf1451a) to head (bb2dfbb).
⚠️ Report is 1 commits behind head on v1.0.0-alpha.4.

Additional details and impacted files

@@                Coverage Diff                 @@
##           v1.0.0-alpha.4     #191      +/-   ##
==================================================
- Coverage           14.33%   14.29%   -0.05%     
==================================================
  Files                  67       67              
  Lines                7179     7179              
==================================================
- Hits                 1029     1026       -3     
- Misses               6150     6153       +3     

Flag	Coverage Δ
spm	14.27% <ø> (-0.05%)	⬇️
swift-6.1-jammy	14.27% <ø> (-0.02%)	⬇️
swift-6.1-noble	14.27% <ø> (-0.02%)	⬇️
swift-6.2-jammy	14.27% <ø> (ø)
swift-6.2-jammynightly	14.27% <ø> (ø)
swift-6.2-noble	14.27% <ø> (ø)
swift-6.2-noblenightly	14.29% <ø> (+0.01%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 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]

PR Review: Swift Source Compatibility CI Workflow

✅ Strengths

1. Good Matrix Coverage: Testing across Swift 6.0, 6.1, 6.2, and 6.3-nightly provides comprehensive version coverage
2. Proper Nightly Handling: Using continue-on-error for nightly builds is the right approach to prevent flaky failures
3. Consistent with Project Patterns: Follows existing CI patterns (ci skip message, workflow triggers)
4. Explicit Swift 6 Mode: Using -Xswiftc -swift-version -Xswiftc 6 ensures consistent Swift 6 language mode testing

🔍 Issues & Recommendations

1. Duplicate Swift 6.2 Entry (Minor)

The workflow includes swift:6.2 in the matrix, but the main MistKit.yml workflow already tests Swift 6.2 on Ubuntu (lines 18-20 in MistKit.yml). This creates redundant CI runs.

Recommendation: Consider if this duplication is intentional for source compatibility validation or if it should be removed.

2. Missing Swift 6.0 Test Coverage (Inconsistency)

The main workflow (MistKit.yml:18-19) only tests Swift 6.1 and 6.2, but this source compatibility workflow adds 6.0. While this is valuable, it's inconsistent.

Recommendation: Either:

• Add Swift 6.0 to the main workflow for consistency
• Document why source compat testing includes 6.0 but main testing doesn't

3. Build-Only vs Test Coverage (Missing Tests)

The workflow only runs swift build without swift test. This validates source compatibility for compilation but not runtime behavior.

Recommendation: Consider adding && swift test --disable-sandbox to catch runtime compatibility issues across versions:

- name: Test Swift 6.x For Source Compatibility
  run: swift build --disable-sandbox --verbose --configuration release -Xswiftc -swift-version -Xswiftc 6 && swift test --disable-sandbox

4. Package.swift Swift Version Mismatch (Potential Issue)

Package.swift declares // swift-tools-version: 6.1 but this workflow tests back to Swift 6.0. Swift 6.0 cannot build a package requiring tools version 6.1.

Expected Behavior: Swift 6.0 builds will fail with:

error: package at '/path' requires minimum Swift tools version 6.1.0 (currently 6.0.0)

Recommendation: Either:

• Remove swift:6.0 from the matrix (recommended if 6.1 is the true minimum)
• Lower swift-tools-version to 6.0 in Package.swift if 6.0 support is actually desired
• Add expected failure handling for 6.0 if this is a known limitation

5. Verbose Flag on Release Build (Minor)

Using --verbose on release builds generates a lot of output. This is fine for debugging but may clutter CI logs.

Recommendation: Consider removing --verbose or only enabling it on failure for cleaner logs.

6. No Platform Specification (Potential Issue)

The workflow uses Ubuntu (ubuntu-latest) but doesn't test source compatibility on macOS or Windows where platform-specific code paths might differ.

Recommendation: If the goal is comprehensive source compatibility, consider adding macOS runners for Apple platform validation.

🔒 Security

✅ No security concerns identified. The workflow uses:

• Official Swift Docker containers
• Checkout action v4 (latest)
• No credential handling or secret exposure

⚡ Performance

The workflow is efficient:

• Uses fail-fast: false to run all versions even if one fails
• continue-on-error for nightly prevents blocking
• Build-only approach is faster than full test suite (though less comprehensive)

📊 Test Coverage

Gap: This workflow doesn't run tests, so it only validates compilation, not runtime behavior across Swift versions. The main workflow has excellent test coverage but only for 6.1/6.2.

🎯 Best Practices Alignment

Comparing with MistKit.yml:

• ✅ Uses same ci skip pattern
• ✅ Consistent checkout action version
• ✅ Follows matrix strategy pattern
• ❌ Missing test execution (main workflow uses brightdigit/swift-build with tests)
• ❌ No code coverage integration (main workflow uses codecov)

📝 Suggested Changes

matrix:
  container:
    - swift:6.1  # Remove 6.0 due to tools version mismatch
    - swift:6.2  # Consider removing if main workflow already covers this
    - swiftlang/swift:nightly-6.3-noble

steps:
  - name: Checkout repository
    uses: actions/checkout@v4

  - name: Build and Test Swift 6.x For Source Compatibility
    run: |
      swift build --disable-sandbox --configuration release -Xswiftc -swift-version -Xswiftc 6
      swift test --disable-sandbox -Xswiftc -swift-version -Xswiftc 6

✅ Overall Assessment

This is a solid addition for source compatibility validation. The main issue is the Swift 6.0 tools version mismatch which will cause builds to fail. Once that's resolved, this workflow provides valuable early warning for Swift version compatibility issues.

Recommended Action: Update the matrix to match the Package.swift minimum version or adjust the package manifest accordingly.

---

Review generated with Claude Code following MistKit's CLAUDE.md conventions

[claude]

Code Review: Swift Source Compatibility CI Workflow

I've reviewed PR #191 and have the following feedback:

✅ Strengths

1. Well-structured workflow - The new workflow follows GitHub Actions best practices
2. Good version coverage - Testing against Swift 6.1, 6.2, and 6.3-nightly
3. Appropriate failure handling - Using continue-on-error for nightly builds
4. Consistent with existing patterns - Mirrors the style used in MistKit.yml

⚠️ CRITICAL Issues

1. Package.swift Changes Break CI Validation

The removal of these compiler flags is highly problematic:

• -warn-concurrency
• -enable-actor-data-race-checks
• -strict-concurrency=complete
• -enable-testing

These flags are ESSENTIAL for Swift 6 data race safety. Per CLAUDE.md, the project requires Sendable compliance and uses Swift Testing framework which needs -enable-testing.

2. Missing Swift 6.0 from Matrix

PR description mentions Swift 6.0 but it's not in the matrix.

3. Incomplete Testing

The workflow only builds but doesn't run tests. Should add 'swift test' step.

4. Unnecessary --disable-sandbox Flag

This flag should be justified or removed for security.

🔧 Recommendations

HIGH PRIORITY:

• Restore the removed compiler flags in Package.swift
• Add Swift 6.0 to matrix or update description

MEDIUM PRIORITY:

• Add test execution step
• Remove --disable-sandbox flag
• Remove redundant -Xswiftc -swift-version -Xswiftc 6

🎯 Summary

DO NOT MERGE AS-IS. The removal of Swift 6 concurrency checking flags undermines the project's safety guarantees. The workflow is well-structured but needs the Package.swift changes reverted.

Review by Claude Code

[claude]

Code Review: Swift Source Compatibility CI Workflow

Thank you for implementing this source compatibility workflow! Overall, this is a solid addition that follows good CI practices. Here's my detailed feedback:

---

✅ Strengths

1. Good Version Coverage: Testing Swift 6.1, 6.2, and 6.3-nightly provides comprehensive coverage of the Swift 6.x family.

2. Sensible Error Handling: Using continue-on-error for nightly builds is the right approach - nightly failures shouldn't block PRs.

3. Follows Project Patterns: The workflow structure aligns well with the existing MistKit.yml workflow (same ci skip pattern, similar job structure).

4. Package.swift Cleanup: Removing the unsafe concurrency flags from Package.swift makes sense - these should be handled by the Swift 6 language mode declaration at the top of the file (swift-tools-version: 6.1), not via unsafe compiler flags.

---

🔍 Code Quality Issues

Missing Swift 6.0 in Matrix

The PR description mentions testing Swift 6.0, but the matrix only includes 6.1, 6.2, and 6.3-nightly. Consider adding:

container:
  - swift:6.0  # Add this
  - swift:6.1
  - swift:6.2
  - swiftlang/swift:nightly-6.3-noble

Build-Only Approach May Miss Issues

The workflow runs swift build but not swift test. This means:

• Runtime issues won't be caught
• Test compilation issues won't be detected
• Platform-specific test failures will be missed

Recommendation: Consider adding swift test or at least document why build-only is sufficient for source compatibility validation.

Inconsistency with Main CI

The main MistKit.yml workflow:

• Tests on multiple OS variants (noble, jammy)
• Includes code coverage
• Tests both Swift 6.2 stable AND nightly

This workflow only tests on noble. For true compatibility validation, consider testing multiple OS variants.

---

⚠️ Potential Issues

Package.swift Changes May Break CI

Removing these flags from Package.swift:

-warn-concurrency
-enable-actor-data-race-checks
-strict-concurrency=complete
-enable-testing

Concerns:

1. -enable-testing: Required for @testable import - removing this may break test builds
2. Concurrency Checks: These flags provide valuable compile-time safety. Are they redundant with Swift 6 mode?
3. No Migration Path: The PR doesn't explain why these were removed or validate that builds still work without them

Recommendation:

• Document why each flag was removed
• Verify that -enable-testing isn't needed (or add it back)
• Consider keeping strict concurrency checking as it's valuable even in Swift 6

Verbose Flag in Production

run: swift build --disable-sandbox --verbose --configuration release

The --verbose flag will create large CI logs. Consider:

• Removing --verbose for cleaner logs
• Or document why verbose output is needed for source compatibility testing

---

🔒 Security & Best Practices

Sandbox Disabled

--disable-sandbox is needed in Docker containers, but:

• Document why it's required (Swift Docker containers need this)
• This is acceptable for CI but shouldn't be cargo-culted to other contexts

Checkout Action is Up-to-Date

Using actions/checkout@v4 is correct and secure. ✅

---

📊 Testing & Coverage

No Test Execution

As mentioned, this workflow doesn't run tests. Comparison with main CI:

Aspect	MistKit.yml	This PR
Platforms	Ubuntu, macOS, Windows, Android	Ubuntu only
Tests	Yes	No
Coverage	Yes	No
Matrix	OS variants + Swift versions	Swift versions only

Recommendation: Either:

1. Add swift test to validate runtime compatibility
2. Clearly document this is for build compatibility only
3. Explain the relationship with the existing MistKit.yml workflow

---

🎯 Recommendations

Priority Changes

1. ✅ Add Swift 6.0 to match PR description
2. ✅ Restore -enable-testing flag if tests need it
3. ✅ Document flag removal in commit message or PR description
4. ⚠️ Consider adding swift test for comprehensive validation

Nice-to-Have Improvements

• Add OS matrix (noble/jammy) for consistency with main CI
• Remove --verbose unless debugging is needed
• Add a comment explaining the relationship with MistKit.yml
• Consider adding a step to report Swift version:

- name: Report Swift Version
  run: swift --version

---

📝 Final Assessment

Overall Grade: B+ (Good with room for improvement)

Verdict: This PR adds valuable source compatibility testing, but needs clarification on:

• Why tests aren't run
• Why concurrency/testing flags were removed
• Whether Swift 6.0 should be included

Suggested Next Steps:

1. Address the -enable-testing flag concern
2. Document the build-only rationale
3. Add Swift 6.0 or update PR description
4. Consider running tests for comprehensive validation

Great work following the project's CI patterns and implementing fail-fast strategies! 🎉