chore(ios): clear swift-format debt blocking iOS CI#7
Merged
Conversation
main's iOS workflow has been failing swift-format --strict since PR #1 merged (auto-merge bypassed the check since no branch protection). Every Phase 0 code review flagged "pre-existing swift-format issues in unrelated files" and deferred. This clears the debt so CI goes green for PR #2 and future iOS changes. Changes: - Ran `swift-format format --in-place` which auto-fixed 17 whitespace, indentation, and AddLines errors across RootView, AppleSignInService, and SignUpWallView. - Hand-added 4 docblocks swift-format required: - MWButtonPress.body(content:) full param/return doc - MWScreen.body one-line /// - MWAccentKey.mwAccent(_:) — Returns: section - Borders.mwStroke(...) — Returns: section - Rewrote the 164-char string in SignUpWallView as a 3-part concatenation so no disable pragma is needed. Compiler folds the concatenation at compile time. - Added `opening_brace` to .swiftlint.yml's disabled_rules. swift-format wraps long protocol-conformance lists onto multiple lines with the opening brace on its own line (see AppleSignInService:81-86); SwiftLint's opening_brace rule fights that. Same precedent as the existing trailing_comma disable — swift-format is authoritative. Verified: - `swift-format lint --strict Flashcards` → exit 0 - `swiftlint --strict Flashcards` → 0 violations, 38 files - `xcodebuild test` → TEST SUCCEEDED (19 FlashcardsTests + 1 UI test) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2 tasks
lchogan
pushed a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lchogan
pushed a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lchogan
pushed a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lchogan
pushed a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lchogan
pushed a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
lchogan
added a commit
that referenced
this pull request
Apr 22, 2026
The post-PR-#7 iOS run on main failed at the Coverage step — not tests. Build succeeded, all 20 tests passed, but: $(find ~/Library/Developer/Xcode/DerivedData -name '*.xcresult' | head -1) expanded to empty because xcodebuild wrote DerivedData somewhere the find command didn't look (runners don't always honor the default ~/Library path). xcrun xccov view got called with an empty arg and failed with "Must supply a report or archive to view", which bubbled up as an overall CI failure. Two changes: 1. Pin DerivedData to ios/build/DerivedData via -derivedDataPath, so the xcresult lives at a known, workspace-relative location. 2. Make the Coverage step tolerant of a missing xcresult — log + exit 0 instead of crashing. Coverage reporting is informational; a missing report should never fail the pipeline. Also added `set -o pipefail` to the Build & Test step so a future xcodebuild failure isn't hidden by xcbeautify's exit code. Co-authored-by: Luke Hogan <lukehogan@Mac.localdomain> Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes the iOS CI failure surfaced on PR #2 (Dependabot's actions/checkout bump) by clearing ~25 swift-format errors that have been accumulating on main since Phase 0.
Root cause: PR #1 merged via auto-merge without branch protection, so a failing iOS${\color{red}build-test}$ check didn't block it. Every Phase 0 code review flagged "pre-existing swift-format issues" and deferred. Now any PR that touches `ios/**` or the iOS workflow fails CI.
Effect: iOS CI on main will go green after this merges, unblocking PR #2 and all future iOS PRs.
Changes
1. Auto-formatted (swift-format --in-place)
Swept 17 whitespace / indentation / AddLines errors:
2. Hand-added 4 docblocks
swift-format's `ValidateDocumentationComments` and `AllPublicDeclarationsHaveDocumentation` rules required:
3. String-literal rewrite (no disable pragma)
The 164-char email explanation in SignUpWallView.swift previously used `// swiftlint:disable:next line_length`. Rewrote as a 3-part string concatenation — Swift compiler folds literal concatenations at compile time, so zero runtime cost, and no pragma dance when swift-format re-flows the file.
4. New `.swiftlint.yml` disabled_rule: `opening_brace`
swift-format wraps long protocol conformance lists onto multiple lines with the opening brace on its own line (see AppleSignInService:81-86 — NSObject + ObservableObject + ASAuthorizationControllerDelegate + ASAuthorizationControllerPresentationContextProviding is too long for one line). SwiftLint's `opening_brace` rule insists the brace stay on the declaration line. The existing precedent in this file (commit `ed6d8eb`) is that swift-format is authoritative; same rationale applies here.
Test plan
After merge, PR #2 (actions/checkout bump) should re-run and go green.
🤖 Generated with Claude Code