fix(macos): build x86_64 with the standalone spc binary - #2
Merged
Merged
Conversation
setup-php no longer supports Intel macOS runners, since Homebrew dropped them: the macOS x86_64 job hung for ~27 minutes in "Setup PHP" and then failed with "Could not setup PHP 8.4", so no release was created. Download the standalone spc binary of the pinned static-php-cli release instead of cloning it, which needs no PHP or Composer on the runner. See: shivammathur/setup-php#1112 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Note
Reviewed — No blocking findings · 🔵 2 minor points
🔍 Full review · 1 file reviewed
🔵 Minor points
.github/workflows/build-php.yml:180— Therun:step has noshell:, so GitHub Actions runs it withbash -e {0}, which has nopipefail. Ifcurlfails (for example a 404 on the release asset or a network error), the pipeline's exit status istar's. bsdtar may accept the empty stdin and exit 0. The step then fails later atmv spc/spc spc/bin/spcwith "No such file or directory", not at the download. Addset -o pipefailorshell: bashso the failure is reported where it happens..github/workflows/build-php.yml:180— The job downloads a prebuiltspcexecutable from a GitHub release and runs it (--version,doctor --auto-fix,download,build) without checking it against a known SHA-256. Release assets can be replaced after upload, so pinningSPC_VERSIONdoes not pin the bytes that run. This binary produces the PHP that is published in the release. Store the expected hash next toSPC_VERSIONand runshasum -a 256 -cbefore extracting.
Verification
- The binary moves to spc/bin/spc and later steps run after
cd spc, so output still lands in spc/buildroot/bin/php, the uploaded path. - The download URL uses the same SPC_VERSION (2.8.5) as the other jobs, so the release body's 'Built with static-php-cli v2.8.5' stays accurate.
- The Intel job no longer needs setup-php or composer, and GITHUB_TOKEN still comes from the workflow env for
spc download. - The download, build and upload steps are unchanged, so artifact naming and create-release inputs are the same.
No automated test covers this: the workflow only runs on workflow_dispatch. The only evidence is the manual test dispatch linked in the PR description.
Review details
- Commit: 253e3e7
- Model: claude-opus-5-5
Review 1 of 10 for this pull request · View the full run
Address review feedback: - Check the tarball against a pinned SHA-256, since a release asset can be replaced after upload and the binary builds the published PHP. The hash matches the digest GitHub recorded for the 2.8.5 asset. - Download to a file instead of piping curl into tar, so a failed download fails the step at curl rather than later at a missing file. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
pjcdawkins
added a commit
to upsun/cli
that referenced
this pull request
Sep 25, 2026
Security fixes since 8.4.23 in code the CLI uses include: - OpenSSL: TLS hostname verification fell back to the CN after a SAN mismatch (CVE-2026-91769), and a heap buffer overflow on a crafted wildcard CN (CVE-2026-91767). - HTTP stream wrapper: a cross-origin credential leak on redirects (CVE-2026-91766), and an out-of-bounds read on an empty Location header (CVE-2026-93682). - Phar: TAR entry injection via an integer overflow (CVE-2026-6103), and a crash via recursive symlinks (CVE-2026-7260, 8.4.24). - Windows: reserved device names were not rejected before file I/O (CVE-2026-17545). The binaries come from upsun/cli-php-builds, whose macOS x86_64 build now uses the standalone static-php-cli binary (upsun/cli-php-builds#2). Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
setup-php no longer supports Intel macOS runners, since Homebrew dropped them (setup-php#1112). The macOS x86_64 job hung for ~27 minutes in "Setup PHP" and failed with "Could not setup PHP 8.4", twice, so the 8.4.26 build created no release.
The Intel job now downloads the standalone
spcbinary from the pinned static-php-cli release (spc-macos-x86_64.tar.gz) instead of cloning it, so it needs no PHP or Composer on the runner. The other jobs are unchanged.spc doctor --auto-fixstill installs re2c, automake and bison with Homebrew on the Intel runner. That worked in the test run, but may need replacing if Homebrew stops working there.Tested with a dispatch on this branch (8.4.26, no release): https://github.com/upsun/cli-php-builds/actions/runs/36150992001. All platforms passed, and the darwin-amd64 artifact is an x86_64 Mach-O binary with PHP 8.4.26.
🤖 Generated with Claude Code