grain.social/grain-ios

Switch repository

Loading…

What changes

ci_scripts/ci_post_clone.sh no longer uses Homebrew. It downloads pinned git-lfs 3.8.1 and XcodeGen 2.46.0 releases, checks their SHA-256, and puts them on PATH. The rest of the script is unchanged.

Why

The TestFlight archive for 1dc3cca failed in this script. Xcode Cloud ran it on Intel (x86_64, macOS Tahoe 26.5.1), which Homebrew stopped supporting in September 2026. git-lfs 3.8.1 has no Intel bottle, so brew set out to build 19 dependencies from source, including LLVM and Rust, and failed in the first it compiled: clang: error: unsupported argument 'westmere' to option '-march=' in openssl@4.

XcodeGen still has an Intel bottle, but Homebrew no longer builds them, so a future release would fail the same way. Pinning both removes the dependency and makes the tools reproducible. git-lfs has an Intel build, and XcodeGen's bundle is universal.

How it was checked

sh -n passes. The new download section was run on an arm64 Mac: both checksums pass and both tools land on PATH. git-lfs's checksums match the release's sha256sums.asc. lipo shows x86_64 in the Intel git-lfs and x86_64 and arm64 in XcodeGen. Before this change, git lfs pull, xcodegen generate and the Package.resolved copy passed from a fresh GitHub clone using the Mac's Homebrew tools.

Shortcomings

• The pinned binaries were not executed here, and nothing short of Xcode Cloud exercises this script on Intel. Merging starts a TestFlight build, which is the real test.
• XcodeGen's checksum was computed from the download; the release publishes none to compare with.
• The archive will also be the first compile of GalleryDraft's alt change, and does not run testEveryPhotoWriteCarriesAlt.

Review

A quick look at the script.

🤖 Generated with Claude Code

This replaces brew install in ci_post_clone.sh with pinned git-lfs and XcodeGen downloads. Each is checked against a SHA-256 and put on PATH. I read the whole script and found nothing that needs changing.

• set -e stops the script if a download, a checksum or an unzip fails. The case fails loudly on an architecture it doesn't know.
• The git-lfs zip unpacks to git-lfs-<ver>/git-lfs, and the later git lfs install and git lfs pull find it through PATH. The XcodeGen bundle path matches the layout you describe, with the resource bundle beside the binary.
• The checksums are pinned in the script, so I couldn't verify them from here. As your body says, the XcodeGen one comes from your own download, so it only guards against the file changing later.

As you note, the Intel run on Xcode Cloud is the real test, since nothing here executed the binaries there.