Skip to content

fix(ci): pin Tier-3 iOS cache key to Xcode version#631

Merged
TaprootFreak merged 1 commit into
stagingfrom
fix/tier3-cache-key-xcode-version
Jun 1, 2026
Merged

fix(ci): pin Tier-3 iOS cache key to Xcode version#631
TaprootFreak merged 1 commit into
stagingfrom
fix/tier3-cache-key-xcode-version

Conversation

@TaprootFreak
Copy link
Copy Markdown
Contributor

Problem

The Tier-3 `Build iOS simulator app` step failed on PR #626 with:

```
Swift Compiler Error (Xcode): File '/Applications/Xcode_16.4.app/.../iPhoneSimulator18.5.sdk/usr/lib/swift/shims/module.modulemap'
has been modified since the module file '.../ModuleCache.noindex/.../SwiftShims-2ZSRUUIS75TOI.pcm' was built:
mtime changed (was 1779274009, now 1779861061)
```

The cached `SwiftShims-*.pcm` referenced a previous SDK's `module.modulemap` mtime — its own `module.modulemap` had been rewritten by the runner image's Xcode upgrade between two macOS-latest runs.

Root cause

`Cache iOS DerivedData + Pods` keyed only on `runner.os + lock files`. `runner.os` is just `"macOS"` regardless of the runtime Xcode/SDK version, so a cache restored across an Xcode bump produces `.pcm` files that point at SDK file mtimes from the previous toolchain. Swift refuses to use them and the build fails.

Fix

Resolve `xcodebuild -version` at runtime and inject it into both the cache key and the restore-keys fallback. The cache now invalidates exactly when the active Xcode rolls, so a hit can only restore objects that were built against the current toolchain.

The version string is normalised (`tr '\n' '-' | sed 's/[^A-Za-z0-9.-]//g; s/-$//'`) so `Xcode 16.4 / Build version 16F6` becomes a safe cache-key fragment like `Xcode-16.4-Build-version-16F6`.

Validation plan

  • On first run after merge, cache misses (new key includes Xcode version that didn't exist in the old cache namespace) → clean build, populates a fresh cache.
  • Subsequent runs hit the cache as before, but only across the same Xcode version.
  • When the runner image upgrades Xcode next, the cache misses again instead of restoring stale modules — same one-time clean-build cost, no `mtime changed` failure.

The Tier-3 `Cache iOS DerivedData + Pods` step keyed only on
`runner.os + lock files`. When the macOS-latest runner image upgrades
Xcode (and the iOS SDK with it), the cached `SwiftShims-*.pcm` module
files reference SDK `module.modulemap` mtimes from the previous
toolchain. Swift then rejects the cached modules and the
`Build iOS simulator app` step fails with:

    File '...iPhoneSimulator18.5.sdk/usr/lib/swift/shims/module.modulemap'
    has been modified since the module file '...SwiftShims-*.pcm' was
    built: mtime changed (was X, now Y)

Resolving the active `xcodebuild -version` into the cache key (and the
restore-keys fallback) invalidates the cache exactly when the SDK rolls,
so cache-hits only restore objects that were built against the current
toolchain.
@TaprootFreak TaprootFreak marked this pull request as ready for review June 1, 2026 18:23
@TaprootFreak TaprootFreak added the tier3:full Opt-in: run Tier 3 Maestro handbook flows on this PR label Jun 1, 2026
@TaprootFreak TaprootFreak merged commit c08bca9 into staging Jun 1, 2026
11 checks passed
@TaprootFreak TaprootFreak deleted the fix/tier3-cache-key-xcode-version branch June 1, 2026 20:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

tier3:full Opt-in: run Tier 3 Maestro handbook flows on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant