Repository navigation
ios-fleet: one shared four-digit build counter across iOS and macOS - #337
Conversation
Port of Congress.Trade #2892. Owner rule (Oct 28): marketing stays 0.1.0 and CFBundleVersion is a plain 4-digit integer from one counter per app: next = max(every iOS build, every macOS build, extra floors, 999) + 1. Replaces the dotted 0.1.0 (0.1.n) fixed-mode build.
|
@kody start-review |
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
|
Task description is insufficient for business logic validation. 🤔 Insufficient Task ContextI found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details. 🔍 What I need to validate:
💡 How to improve the task context:
|
Code Review Could Not Complete
|
| Options | Enabled |
|---|---|
| Bug | ✅ |
| Performance | ✅ |
| Security | ✅ |
| Business Logic | ✅ |
|
Task description is insufficient for business logic validation. 🤔 Insufficient Task ContextI found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details. 🔍 What I need to validate:
💡 How to improve the task context:
|
Code Review Completed! 🔥The code review was successfully completed based on your current configurations. Kody Guide: Usage and ConfigurationInteracting with Kody
Current Kody ConfigurationReview OptionsThe following review options are enabled or disabled:
|
|
Task description is insufficient for business logic validation. 🤔 Insufficient Task ContextI found a task linked to this PR, but it only contains minimal information (title only, no description or acceptance criteria). To perform a meaningful business rules validation, I need more details. 🔍 What I need to validate:
💡 How to improve the task context:
|
- pairedBuildFeed fetch is https-only, time- and size-bounded; failures name the feed URL - whitespace-tolerant <sparkle:version> scrape, max via POSIX tools (no /usr/bin/python3) - feed floor outside 1..9998 and an empty feed fail closed with a logged reason - macOS entries reverse-resolve their paired iOS bundle; both apps, both platforms join the counter - inventories fetched concurrently; page cap still fails closed - tests for each case
Replaces the per-train dotted build (
M.m.<n>) with one shared four-digit build counter per app across iOS and macOS forfixedMarketingVersionships.scripts/ios-fleet/shared-build.mjsnextSharedBuild(): next = max(1000, every iOS candidate +1, every macOS candidate +1, every extraFloor +1). Empty inventory starts at1000; range ends at9999. Legacy iOS UTC timestamp builds (first component >= 100000000) are ignored and counted inignoredIos; all macOS builds count. Requires complete inventory and rejects malformed inventory.asc-api.mjs next-dotted-buildwithnext-shared-build <bundleId> [macBundleId] [floor...]: read-only, fully paged inventory of every iOS build on all trains and every macOS build on all trains for the iOS app plus optional paired Mac app (macBundleId), plus integer floors. Numeric second arg is treated as a floor.ship-testflight.shasc_next_shared_build(): resolvesmacBundleIdandpairedBuildFeedSparkle appcast fromapps.json, uses max<sparkle:version>from the feed as an extra floor, callsnext-shared-build, and requires a four-digit1000..9999result. Fixed mode now works on iOS and macOS, validates operator--buildas four-digit and at-or-above the planned minimum, and otherwise auto-assigns the shared build.version-plan-contract.ymland contract tests: adds offlineshared-build.test.mjscoverage and verifies client and module agree onnext-shared-buildwith one iOS and one macOS inventory query.