[brentvatne]

A run's matrix jobs now share one hosted repack by the native fingerprint they repack, instead of by the build each job found to repack.

Why

In brentvatne/euxy#179 (review run 40042718931), four iOS targets were meant to share one repack:

• Three of them did. iPhone, Duo open and Duo half-open looked up a build to repack and found 7f6b592a. iPhone repacked it, and the other two waited for that repack.
• Duo closed didn't. Its capture started 8 minutes later. By then the newest build with the fingerprint was the iPhone's fresh repack, 2ebcfd8d, because a repack is itself a build with the same profile and fingerprint.
• Its key couldn't match. The share key named the native build id, so Duo closed's key was different. It waited the full 3 minutes for a shared repack it could never find, then made a second iOS repack.
• It was the slowest job in the run (17 minutes, against 7–12 for the others), and it used an extra EAS build.

existingBuild does prefer a build Explore didn't repack, but only among the 20 it lists. On euxy, the 50 most recent iOS explore builds are all repacks, so it falls back to the newest one, and that changes as repacks finish.

Change

• hostedRepackShareKey takes the native fingerprint in place of nativeBuildId (contract v3). A follower now runs the leader's repack of whichever build with that fingerprint the leader found. That's the native code the fingerprint covers. What a repack keeps from its source beyond that, such as its Info.plist and the toolchain it was built with, can differ between builds of one fingerprint. existingBuild already treats such builds as interchangeable, so the change adds little risk, and it makes the targets more consistent with each other.
• prepareHostedRepack passes the fingerprint prepareExactSourceBuild already has.
• Comments and CI-FLOW §4.1 describe the lookup and the key as they now work: existingBuild's doc, the repackWaits comment, and CI-FLOW's item 1 and the paragraph on what the key holds.

Tests

• ci-map.test.mjs, the incident end to end. The leader repacks and its build finishes. A late target whose lookup returns that repack as its build to repack looks once, finds the finished repack, downloads it and makes no repack of its own. The test fails against main's eas-build.ts.
• hosted-repack.test.mjs: two different source build ids with the same fingerprint give the same key, and a different fingerprint still gives a different key.

An independent adversarial review found no case where the new key shares wrongly. It checked head and base, reruns (the attempt is in the scope), mixed versions (the release is in the key), the native-build-made-here path (no marker) and the environment-fetch-failure path (no share).

Not changed: follow-ups

• A follower's reported metadata. A follower reports nativeEasBuildId, and the fallback app version and build number, from the build it found, not from the leader's repack it runs. On main this already happens whenever all 20 listed builds are repacks. A wrong build number would also need EAS remote versioning plus a new native build landing mid-run.
• Chains of repacks are the steady state on a busy project. existingBuild almost never finds a true native build, and nativeEasBuildId often names a repack. Writing the source build id into the repack's message would let lookup and reports name the real native build.

🤖 Generated with Claude Code

[github-actions]

This preview was deleted on 2026-10-31, a week after the pull request closed. The links below no longer open.

Viewer preview of edf0a60 · reports from brentvatne/euxy#163

Report	Changes	Open
Android · sdk_gphone64_x86_64 15.0	5	Map · Screens · Compare
iPhone 17 · iPhone 17 26.5 · light + dark	11	Map · Screens · Compare
iPhone Duo (closed) · iPhone Duo 27.1 · light + dark	34	Map · Screens · Compare
iPhone Duo (open) · iPhone Duo 27.1 · light + dark	34	Map · Screens · Compare

The link stays the same on every push. Deploy run