Repository navigation
Build and verify every platform in one CI Verify job (PR 1/20) - #69
Conversation
|
Warning Review limit reached
Next review available in: 53 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: QUIET Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (10)
📝 WalkthroughWalkthroughThe PR configures signed Mac verification and named CI build targets, updates build documentation, and renames EOF semaphore locals in ChangesBuild verification and CI targets
Process output synchronization
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
f65a257 to
095f5d6
Compare
095f5d6 to
db3e640
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Makefile`:
- Line 41: Align the Verify configuration and documentation with the signed Mac
Verify contract: in Makefile lines 41 and 74-85, use the signed Mac product and
matching signing roots, product claims, and confirmed simulator handling instead
of build all. Update .github/workflows/ci.yml lines 54-62, AGENTS.md line 67,
and README.md lines 21-22 to document the same separate named-target invocations
for Catalyst, iPhone simulator, and daemon builds, including matching signing
checks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: QUIET
Plan: Pro Plus
Run ID: b80d1236-1218-483c-8717-16c75d43441f
📒 Files selected for processing (5)
.github/workflows/ci.ymlAGENTS.mdMakefileREADME.mdTools/CellTunnelDev/ProcessSupport.swift
db3e640 to
5a3f61f
Compare
5a3f61f to
95aee42
Compare
95aee42 to
1c53e7d
Compare
1c53e7d to
7c8e156
Compare
SWIFT_VERIFY_BUILD_CMD builds every platform through CellTunnelDev `build all`, so one Verify job compiles the Mac agent and tunnel, the Catalyst app, the iPhone simulator app, the iPhone device app, and the daemon. These targets carry App Groups and Network Extension entitlements, so each needs a provisioning profile. CI runners are not registered devices, so development provisioning cannot work there; only App Store distribution profiles, which carry no device list, sign on an unregistered machine. The ci-provision setup step runs fastlane before the build to create or renew one App Store profile per target through the App Store Connect API key (fastlane/Fastfile), so profiles do not expire out from under CI. Project.swift pins each profile by name and signs manually with the Apple Distribution certificate when TUIST_DEVELOPER_ID_SIGNING is set; local builds keep automatic development signing. ci.yml imports the distribution certificate and runs ci-provision, and no longer installs static profiles. SWIFT_MK_VERIFY_SIGNING_ROOTS verifies every runnable product is signed with the team and is not ad-hoc, skipping the ad-hoc simulator product. The separate build-catalyst, build-iphone-sim, and build-daemon extra-target jobs are removed because the one build produces them all. Rename ProcessSupport EOF semaphore locals. Co-authored-by: Codex <noreply@openai.com> Co-authored-by: Claude <noreply@anthropic.com>
7c8e156 to
4d5656c
Compare
|
nice |

Summary
CI builds every platform in one Verify job and verifies each product's signature, replacing the Mac-only Verify plus separate extra-target jobs.
Change
SWIFT_VERIFY_BUILD_CMDbuilds every platform throughCellTunnelDev build all, so one Verify job compiles and signs the Mac agent and tunnel, the Catalyst app, the iPhone simulator app, the iPhone device app, and the daemon. The signing override signs every product, and the App Store Connect API key (already inherited) drives automatic signing for the iPhone and Catalyst products.SWIFT_MK_VERIFY_SIGNING_ROOTS = Productsmakes the engine discover each runnable.appthe build dropped underProductsand verify its signature: a strictcodesign --verify --deepon each app plus a team and non-ad-hoc check. The engine skips the iPhone simulator app, which is ad-hoc by design. The pre-build settings check confirms the signing identity. Thebuild-catalyst,build-iphone-sim, andbuild-daemonextra-target jobs are removed because the one build produces them all.Depends on the engine
verify-signing productscapability (swift-makefile #186).Testing
make verify CONFIG=Debugbuilds every platform, signs each, and verifies each runnable product.