mirror of
https://github.com/Novaloop-AG/element-x-ios.git
synced 2026-10-31 16:24:11 +00:00
joel.poyet
d7a93dddea
Both documents told the reader to pin Xcode 26.4 and to install it via a Brewfile. A probe of novaloop-mac-studio-001 refutes the premise: it carries exactly one Xcode, 26.6, globally selected, with no versioned siblings and no 26.4 anywhere. The design justified the pin with "the runner has it and the legacy pipeline proves it works" — both halves are false, and a pin naming an absent version does not fail fast: xcodes starts a multi-GB authenticated download that no CI secret can satisfy, so before_all hangs. Record the no-pin decision and its cost — whatever Xcode the runner has is what ships, unrecorded — rather than only deleting the wrong instruction, so nobody reintroduces the pin from the same reasoning. Drop the Brewfile with it: its only purpose was installing xcodes for that pin, and brew has no business running on a shared release machine where it could upgrade xcodegen mid-release. Add the runner's real constraints (no passwordless sudo, single Xcode, five missing tools installed by hand) to the design, since they are why upstream's setup_github_actions_environment cannot run here. Two new risks. The legacy element-ios pipeline pins the same absent 26.4, so it is very likely broken right now — not this fork's problem to fix, but the human needs to know before the next legacy release. And with no pin, an Xcode upgrade on the runner silently changes the compiler for every subsequent release. The plan's embedded Fastfile and skill now match the branches that implement them byte-for-byte, so the plan cannot drift from the artefacts it describes.