Updating Documentation to Include Windows Support #36
Conversation
WalkthroughAdds Windows as a documented platform for swift-build and documents Windows-specific inputs and mappings in README and action.yml; updates a watchOS device name in the test workflow. No functional/public API changes. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests
Tip 👮 Agentic pre-merge checks are now available in preview!Pro plan users can now enable pre-merge checks in their settings to enforce checklists before merging PRs.
Please see the documentation for more information. Example: reviews: pre_merge_checks: custom_checks: - name: "Undocumented Breaking Changes" mode: "warning" instructions: | Pass/fail criteria: All breaking changes to public APIs, CLI flags, environment variables, configuration keys, database schemas, or HTTP/GraphQL endpoints must be documented in the "Breaking Change" section of the PR description and in CHANGELOG.md. Exclude purely internal or private changes (e.g., code not exported from package entry points or explicitly marked as internal).Please share your feedback with us on this Discord post. 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. Comment |
🔍 Pull Request Review: Windows Support Documentation UpdateThank you for updating the documentation to include Windows support! This is a valuable addition that reflects the action's expanded platform coverage. Here's my comprehensive review: ✅ Strengths
🎯 Code Quality & Best PracticesThe documentation follows the repository's established patterns well:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
action.yml (4)
333-341: Bug: Nested expressions in hashFiles prevent correct cache keying.
hashFiles('${{ inputs.working-directory }}/Package.resolved')won’t resolve the inner${{ ... }}; it hashes the literal string, breaking cache invalidation.Apply this diff:
- key: xcode-deriveddata-${{ runner.os }}-${{ env.XCODE_NAME }}-${{ hashFiles('${{ inputs.working-directory }}/Package.resolved') }}-${{ github.sha }} + key: xcode-deriveddata-${{ runner.os }}-${{ env.XCODE_NAME }}-${{ hashFiles(format('{0}/Package.resolved', inputs.working-directory)) }}-${{ github.sha }} @@ - xcode-deriveddata-${{ runner.os }}-${{ env.XCODE_NAME }}-${{ hashFiles('${{ inputs.working-directory }}/Package.resolved') }}- + xcode-deriveddata-${{ runner.os }}-${{ env.XCODE_NAME }}-${{ hashFiles(format('{0}/Package.resolved', inputs.working-directory)) }}-
437-445: Cache key should include working-directory; current key may miss in monorepos.On Ubuntu, paths are under
${{ inputs.working-directory }}, but the key hashesPackage.resolvedat repo root. Align the key with the cached paths.Apply this diff:
- key: spm-${{ env.OS_VERSION }}-${{ env.SWIFT_VERSION }}-${{ hashFiles('Package.resolved') }} + key: spm-${{ env.OS_VERSION }}-${{ env.SWIFT_VERSION }}-${{ hashFiles(format('{0}/Package.resolved', inputs.working-directory)) }}
462-471: Same cache key misalignment on Windows SPM cache.Mirror the Ubuntu fix so Windows caches invalidate when the package’s lockfile changes under a custom working directory.
Apply this diff:
- key: spm-windows-${{ env.SWIFT_VERSION }}-${{ hashFiles('Package.resolved') }} + key: spm-windows-${{ env.SWIFT_VERSION }}-${{ hashFiles(format('{0}/Package.resolved', inputs.working-directory)) }}
272-295: Fail fast on missing Windows inputs and pin compnerd/gha-setup-swift to v0.3.0
- Add an early validation step to abort Windows runs when inputs.windows-swift-version or inputs.windows-swift-build are missing.
- Pin the third‑party action to compnerd/gha-setup-swift@v0.3.0 (tag commit 581df1f) instead of @main.
- name: Detect OS shell: bash id: detect-os working-directory: ${{ inputs.working-directory }} run: | if [[ "$RUNNER_OS" == "macOS" ]]; then @@ fi + + # Validate Windows inputs early to provide a clear failure + - name: Validate Windows Swift inputs + if: steps.detect-os.outputs.os == 'windows' + shell: bash + run: | + if [[ -z "${{ inputs.windows-swift-version }}" || -z "${{ inputs.windows-swift-build }}" ]]; then + echo "::error title=Missing Windows Swift toolchain inputs::Provide 'windows-swift-version' and 'windows-swift-build' for Windows builds." + exit 1 + fi @@ - - name: Install Windows Swift toolchain + - name: Install Windows Swift toolchain if: steps.detect-os.outputs.os == 'windows' && inputs.windows-swift-version - uses: compnerd/gha-setup-swift@main + uses: compnerd/gha-setup-swift@v0.3.0 with: swift-version: ${{ inputs.windows-swift-version }} swift-build: ${{ inputs.windows-swift-build }}
🧹 Nitpick comments (5)
README.md (5)
38-39: Inconsistent Windows Swift minimum version.You later show 6.0 examples, but this line says “Windows (Swift 6.1+)”. Update to “6.0+” or remove the minimum.
-🌍 **Complete Platform Coverage** - Ubuntu (Swift 5.9-6.2) + macOS (iOS, watchOS, tvOS, visionOS, macOS) + Windows (Swift 6.1+) +🌍 **Complete Platform Coverage** - Ubuntu (Swift 5.9-6.2) + macOS (iOS, watchOS, tvOS, visionOS, macOS) + Windows (Swift 6.0+)
275-323: Matrix uses a top-level container key; verify behavior on macOS/Windows entries.
container: ${{ matrix.container }}may evaluate to null/empty for non‑Linux rows, which can break validation. Consider splitting Linux into a separate job or movecontainer:inside only the Ubuntu include rows.Would you like me to produce a corrected example with separate Ubuntu/macOS/Windows jobs?
820-821: Remove leftover internal marker.
[[memory:3814335]]looks like an internal note and will confuse readers.-| **[Swift Nightly](https://hub.docker.com/r/swiftlang/swift/tags)** | Development/nightly builds [[memory:3814335]] | `swiftlang/swift:nightly-6.2-noble` | +| **[Swift Nightly](https://hub.docker.com/r/swiftlang/swift/tags)** | Development/nightly builds | `swiftlang/swift:nightly-6.2-noble` |
1124-1132: Broken anchor in Troubleshooting ToC: “Windows Issues” section missing.Link points to
#-windows-issuesbut no matching heading exists. Add the section or remove the link.Suggested section to add later in Troubleshooting:
#### 🪟 Windows Issues Q: swift not found on Windows - Ensure you set `windows-swift-version` and `windows-swift-build`. The action installs Swift via compnerd/gha-setup-swift when both are provided. Q: Specified Windows Swift version/build not available - Cross-check available builds in compnerd/gha-setup-swift. Use a matching `swift-6.x-release` with a corresponding `6.x-RELEASE` build.
2012-2027: Caching paths in docs don’t match the action’s implementation.Docs claim user‑home caches (e.g.,
~/.cache/swift-pm,~/Library/Caches/...) are cached, but the action only caches project.build,.swiftpm, and.cache(and DerivedData on macOS). Adjust docs or expand the action.Do you want the action updated to include those user‑level caches, or should we scope the README to the currently cached paths?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
README.md(15 hunks)action.yml(3 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: Applies to .github/workflows/swift-test.yml : When invoking this GitHub Action in workflows, provide the required `scheme` input (and other inputs as needed) Applied to files:
README.md
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: For local Swift package testing, run `swift test --enable-code-coverage --cache-path .cache --force-resolved-versions` Applied to files:
README.md
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: For local Swift package testing, use `swift build --build-tests --cache-path .cache --force-resolved-versions` in test packages Applied to files:
README.md
🪛 markdownlint-cli2 (0.17.2)
README.md
1131-1131: Link fragments should be valid
(MD051, link-fragments)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (14)
- GitHub Check: claude-review
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, noble, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.2, noble, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (5.10, jammy, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, jammy, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.2, jammy, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, focal, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.0, jammy, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.0, noble, false)
- GitHub Check: Test Multi-Target Package (macOS) (tvos, macos-15, /Applications/Xcode_26.0.app, Apple TV 4K (3rd...
- GitHub Check: Test Multi-Target Package (macOS) (ios, macos-15, /Applications/Xcode_16.4.app, iPhone 16 Pro, 18.5)
- GitHub Check: Test Single Target Package (macOS) (watchos, macos-15, /Applications/Xcode_26.0.app, Apple Watch ...
- GitHub Check: Test Single Target Package (macOS) (tvos, macos-15, /Applications/Xcode_26.0.app, Apple TV 4K (3r...
- GitHub Check: Test Multi-Target Package (Windows) (windows-2025)
🔇 Additional comments (2)
action.yml (1)
95-99: Good mapping notes for Windows inputs.Clear, accurate cross-reference to compnerd/gha-setup-swift parameters.
Also applies to: 104-108
README.md (1)
55-56: Clear Windows parameter mapping.Good addition; reduces confusion when bridging to compnerd/gha-setup-swift.
Code Review: Updating Documentation to Include Windows Support✅ Overall AssessmentThis PR successfully adds comprehensive Windows support documentation to the swift-build GitHub Action. The changes are well-structured, thorough, and maintain consistency with the existing documentation style. 🎯 Strengths
🔍 Areas for Improvement
🐛 Potential Issues
💡 Suggestions
✅ Security Review
📊 Test CoverageThe existing test workflow ( 🎬 ConclusionThis is a solid PR that significantly enhances the action's cross-platform capabilities. With minor documentation improvements and the addition of Windows CI testing, this will provide excellent Windows Swift support. The implementation is clean, follows established patterns, and integrates well with the existing codebase. Recommendation: Approve with suggestions ✅ The PR is ready to merge after addressing the documentation gaps, particularly around error handling and troubleshooting for Windows-specific scenarios. 🤖 Generated with Claude Code |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
README.md (1)
275-323: Matrix mixes Linux containers with Windows runners — this will fail.A job-level
containerkey is not supported on Windows runners; usingcontainer: ${{ matrix.container }}still sets the key for Windows and will error. Split Windows into a separate job (nocontainer) or isolate Linux in its own job that uses containers.Apply this diff to remove Windows from this containerized job:
@@ - os: ubuntu-latest container: swiftlang/swift:nightly-6.2-noble swift: '6.2-nightly' - # macOS builds + # macOS builds - os: macos-14 xcode: /Applications/Xcode_15.1.app swift: '5.9' - os: macos-15 xcode: /Applications/Xcode_16.4.app swift: '6.0' - - # Windows builds - - os: windows-latest - windows-swift-version: swift-6.1-release - windows-swift-build: 6.1-RELEASE - swift: '6.1' @@ - uses: brightdigit/swift-build@v1.3.0 with: scheme: MyPackage-Package xcode: ${{ matrix.xcode }} - windows-swift-version: ${{ matrix.windows-swift-version }} - windows-swift-build: ${{ matrix.windows-swift-build }}Then add this separate Windows job (outside this block):
# Add alongside the above job test-windows: runs-on: windows-latest steps: - uses: actions/checkout@v4 - name: Display Swift Version run: swift --version - uses: brightdigit/swift-build@v1.3.0 with: windows-swift-version: swift-6.1-release windows-swift-build: 6.1-RELEASE
♻️ Duplicate comments (2)
README.md (2)
1371-1377: Remove “Use defaults” simulator guidance; it contradicts earlier rules.Docs elsewhere correctly require explicit
deviceName/osVersionfor simulators. This snippet will mislead users and cause failures.-**Quick fix - Use defaults** (recommended): -```yaml -- uses: brightdigit/swift-build@v1.3.0 - with: - scheme: MyApp - type: ios - # Omit deviceName/osVersion for reliable defaults -``` +Provide explicit `deviceName` and `osVersion` (required for simulator platforms). See validated combinations above.
64-66: Make deviceName/osVersion required for simulators here (matches Defaults).Line 64 says “optionally,” but Line 72 and the action’s behavior require them for non‑macOS simulator types.
Apply this diff:
-**Apple platform builds**: Require `scheme`, `type`, and optionally `deviceName`/`osVersion` +**Apple platform builds**: Require `scheme`, `type`, and `deviceName`/`osVersion` (except `macos`)
🧹 Nitpick comments (2)
README.md (2)
1124-1132: Fix invalid link fragment for “Windows Issues.”GitHub drops emoji from IDs; the correct fragment is likely
#windows-issues, not#-windows-issues. This also matches the linter hint (MD051).-- [🪟 Windows Issues](#-windows-issues) +- [🪟 Windows Issues](#windows-issues)
1185-1193: Use a validated iOS device/version in this example.Current values (
iPhone 17/26.0) don’t match the validated list above. Align with earlier combos to prevent copy-paste failures.- deviceName: iPhone 17 - osVersion: '26.0' + deviceName: iPhone 16 Pro + osVersion: '18.5'
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
README.md(16 hunks)
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: Applies to .github/workflows/swift-test.yml : When invoking this GitHub Action in workflows, provide the required `scheme` input (and other inputs as needed) Applied to files:
README.md
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: For local Swift package testing, run `swift test --enable-code-coverage --cache-path .cache --force-resolved-versions` Applied to files:
README.md
📚 Learning: 2025-09-01T19:23:42.609Z
Learnt from: CR PR: brightdigit/swift-build#0 File: CLAUDE.md:0-0 Timestamp: 2025-09-01T19:23:42.609Z Learning: For local Swift package testing, use `swift build --build-tests --cache-path .cache --force-resolved-versions` in test packages Applied to files:
README.md
🪛 markdownlint-cli2 (0.17.2)
README.md
1131-1131: Link fragments should be valid
(MD051, link-fragments)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (13)
- GitHub Check: claude-review
- GitHub Check: Test Single Target Package (Ubuntu) (6.1, focal, false)
- GitHub Check: Test Single Target Package (Ubuntu) (6.2, focal, true)
- GitHub Check: Test Single Target Package (Ubuntu) (5.10, noble, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, focal, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.0, noble, false)
- GitHub Check: Test Multi-Target Package (Windows) (windows-2025)
- GitHub Check: Test Single Target Package (macOS) (visionos, macos-15, /Applications/Xcode_16.4.app, Apple Visio...
- GitHub Check: Test Single Target Package (macOS) (tvos, macos-15, /Applications/Xcode_26.0.app, Apple TV 4K (3r...
- GitHub Check: Test Single Target Package (macOS) (watchos, macos-15, /Applications/Xcode_16.4.app, Apple Watch ...
- GitHub Check: Test Single Target Package (Windows) (windows-2022)
- GitHub Check: Test Single Target Package (macOS) (ios, macos-15, /Applications/Xcode_26.0.app, iPhone 17 Pro, 2...
- GitHub Check: Test Single Target Package (macOS) (ios, macos-15, /Applications/Xcode_16.4.app, iPhone 16 Pro, 1...
🔇 Additional comments (13)
README.md (13)
38-41: Windows platform addition reads well.Nice, concise scope statement with version guidance.
71-76: Defaults section is clear and accurate.Good correction on simulator requirements and Windows parameters.
79-81: Build-tool selection statement is accurate.SPM on Ubuntu/macOS/Windows; xcodebuild when
typeis set.
150-165: Windows quick-start example looks good.Minimal inputs and no
schemerequirement for SPM on Windows.
325-391: Windows examples are clear and consistent.Good coverage: basic, version matrix, and custom working directory.
732-747: SPM examples across platforms look good.Clear split between Ubuntu/macOS and Windows inputs.
799-805: Platform table correctly adds Windows with SPM + toolchain install.Accurate description of what the action provides on Windows.
828-830: Runner support row for Windows is accurate.Good to call out toolchain install and caching.
833-839: Feature bullets align with behavior.Windows-specific caching/toolchain notes are helpful.
1313-1315: SPM row corrected; Windows row clear.Accurately marks
schemeas optional for SPM and lists Windows requirements.
2344-2346: Template note aboutschemeon Windows is helpful.Keeps users from adding irrelevant inputs.
2447-2465: Windows-only template LGTM.Good parameter matrix and mapping note.
2805-2810: Windows diagnostics are useful and accurate.Covers common env queries on Windows.
| | `windows-swift-version` | Swift version for Windows toolchain | `null` | `swift-6.1-release` | `swift-6.0-release`, `swift-6.1-release`, `swift-6.2-branch` | **Windows builds only** - Maps to `swift-version` parameter in [compnerd/gha-setup-swift](https://github.com/compnerd/gha-setup-swift) | | ||
| | `windows-swift-build` | Swift build identifier for Windows | `null` | `6.1-RELEASE` | `6.1-RELEASE`, `6.2-DEVELOPMENT-SNAPSHOT-2025-09-06-a` | **Windows builds only** - Maps to `swift-build` parameter in [compnerd/gha-setup-swift](https://github.com/compnerd/gha-setup-swift) | |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Windows params → compnerd mapping looks correct; please verify against action.yml and upstream docs.
Confirm the input names exactly match your action.yml and compnerd/gha-setup-swift.
🌐 Web query:
Do the inputs for compnerd/gha-setup-swift use `swift-version` and `swift-build` and are their accepted values consistent with the examples (e.g., `swift-6.1-release`, `6.1-RELEASE`)? Provide the current docs link. 💡 Result:
Short answer: No.
- The action's inputs are named "branch" and "tag" (not swift-version / swift-build). The README shows examples using branch values like "swift-5.5-release" and tag values like "5.5-RELEASE" (note: tag is the build tag without the "swift-" prefix). [1]
Current docs (README): https://github.com/compnerd/gha-setup-swift (see "Usage" and "Parameters"). [1]
Source: compnerd/gha-setup-swift README. [1]
Incorrect README input mapping — use compnerd 'branch' and 'tag' (not 'swift-version'/'swift-build')
README.md (lines 55–56): replace windows-swift-version → branch and windows-swift-build → tag; examples should show branch values like swift-6.1-release and tag values like 6.1-RELEASE (tag omits the swift- prefix). Update action.yml/examples to match upstream README: https://github.com/compnerd/gha-setup-swift.
🤖 Prompt for AI Agents
In README.md around lines 55 to 56, the Windows Swift inputs are incorrectly mapped to compnerd/gha-setup-swift parameters; change the parameter names and examples so `windows-swift-version` maps to upstream's `branch` (e.g., `swift-6.1-release`) and `windows-swift-build` maps to upstream's `tag` (e.g., `6.1-RELEASE` — note the tag omits the `swift-` prefix), and update action.yml and any example usage to use `branch` and `tag` names consistent with the compnerd README and the examples linked. Pull Request Review: Windows Support DocumentationSummaryThis PR adds comprehensive Windows support documentation to the swift-build GitHub Action. The changes are primarily focused on documentation updates with one minor workflow update. Strengths
Issues Found1. Workflow File Change - Incorrect Device NameFile: .github/workflows/swift-test.yml:51
2. Missing Required Parameters DocumentationLocation: README.md lines 1185-1192 3. Incomplete Windows Troubleshooting SectionWhile Windows is listed in the troubleshooting table of contents (line 1184), there is no corresponding Windows Issues section with actual troubleshooting content. Suggestions for Improvement
Security Considerations
Code Quality
RecommendationApprove with changes - The PR provides valuable Windows support documentation, but the workflow file change needs to be reverted before merging. The incorrect device name change could break existing CI workflows. Required Changes Before Merge:
Nice to Have:
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/swift-test.yml (1)
238-239: Validate availability of windows-2025 runner label.If GitHub-hosted windows-2025 is not yet available in your org, these matrix entries will never schedule.
Options:
- Drop windows-2025 until available, or
- Gate it behind an env flag, or
- Set continue-on-error: true for those matrix rows.
You can quickly check runner availability in the repo: Settings → Actions → Runners → GitHub-hosted.
Also applies to: 259-260
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/swift-test.yml(1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
.github/workflows/swift-test.yml
📄 CodeRabbit inference engine (CLAUDE.md)
When invoking this GitHub Action in workflows, provide the required
schemeinput (and other inputs as needed)
Files:
.github/workflows/swift-test.yml
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (18)
- GitHub Check: claude-review
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, noble, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, jammy, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (5.10, jammy, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (6.1, jammy, true)
- GitHub Check: Test Multi-Target Package (Ubuntu) (5.10, focal, false)
- GitHub Check: Test Multi-Target Package (Ubuntu) (5.9, jammy, false)
- GitHub Check: Test Single Target Package (Ubuntu) (6.1, jammy, false)
- GitHub Check: Test Single Target Package (Ubuntu) (5.9, jammy, false)
- GitHub Check: Test Single Target Package (macOS) (watchos, macos-15, /Applications/Xcode_26.0.app, Apple Watch ...
- GitHub Check: Test Single Target Package (macOS) (watchos, macos-15, /Applications/Xcode_16.4.app, Apple Watch ...
- GitHub Check: Test Multi-Target Package (Windows) (windows-2025)
- GitHub Check: Test Multi-Target Package (macOS) (ios, macos-15, /Applications/Xcode_16.4.app, iPhone 16 Pro, 18.5)
- GitHub Check: Test Multi-Target Package (macOS) (ios, macos-15, /Applications/Xcode_26.0.app, iPhone 16 Pro, 18...
- GitHub Check: Test Single Target Package (macOS) (ios, macos-14, /Applications/Xcode_15.1.app, iPhone 15, 17.5)
- GitHub Check: Test Single Target Package (Windows) (windows-2022)
- GitHub Check: Test Multi-Target Package (Windows) (windows-2022)
- GitHub Check: Test Single Target Package (Windows) (windows-2025)
🔇 Additional comments (2)
.github/workflows/swift-test.yml (2)
77-83: LGTM: required inputs (scheme et al.) are provided to the Action.All invocation sites pass scheme, working-directory, and platform‑specific inputs. No action needed.
If desired, add a minimal smoke job that only resolves inputs without building, to catch future input‑name regressions.
Also applies to: 149-155, 247-252, 268-272
48-53: Confirm simulator device name for watchOS 26.0 (Xcode 26.0)Couldn't verify here (xcrun not available). Run the commands below on a macOS machine or macOS CI runner and confirm the exact device type name for watchOS 26.0; an exact name mismatch will break the job.
File: .github/workflows/swift-test.yml Lines: 48-53
export DEVELOPER_DIR="/Applications/Xcode_26.0.app/Contents/Developer" xcrun simctl list devicetypes | grep -i 'Apple Watch Ultra' xcrun simctl list runtimes | grep -i 'watchOS' xcrun simctl list devices | grep -i 'Apple Watch Ultra 3'
Summary by CodeRabbit