Skip to content

Commit 2695e09

Browse files
committed
ci: stop piping the iOS xcodebuild through xcbeautify
Follows #391, which dropped xcbeautify from the macOS job and noted it was the only use of it in the repo. This branch forked before that landed, so rebasing brought it back for iOS — it should go the same way. Its stated failure mode showed up here too. Diagnosing the Release build on this branch, "** ARCHIVE FAILED **" and the failed-command list printed ~150 lines *before* the compiler errors that explained them, because xcbeautify's stdout is block-buffered through the pipe. The summary read as the whole story and pointed at the wrong cause. Raw xcodebuild output is verbose but complete and correctly ordered. It also makes the pipefail guard added earlier on this branch unnecessary: the step's exit code is now xcodebuild's own, so `shell: bash` goes too. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01UxzZtpa5Nz3F8ACXzX7Hww
1 parent 505df1f commit 2695e09

1 file changed

Lines changed: 8 additions & 4 deletions

File tree

‎.github/workflows/check.yml‎

Lines changed: 8 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -250,13 +250,17 @@ jobs:
250250
echo "::error::pod install kept failing with CocoaPods/CocoaPods#12866"
251251
exit 1
252252
- name: Build test app
253-
# `shell: bash` for pipefail, so xcbeautify's exit code can't mask a
254-
# failing xcodebuild. A bare `run:` uses `bash -e` without pipefail.
255-
shell: bash
253+
# Not piped through xcbeautify, for the reasons #391 gave when dropping
254+
# it from the macOS job: on a failure it prints the summary but not the
255+
# failing phase's own output, and block-buffers what it does print, so
256+
# the log arrives truncated and out of order. Raw xcodebuild output is
257+
# verbose but complete and correctly ordered, and the step's exit code
258+
# is xcodebuild's own, so no `set -o pipefail` guard is needed.
259+
#
256260
# C_COMPILER_LAUNCHER keeps Xcode's own clang and merely prefixes it
257261
# with ccache, so the compiler still matches the SDK. Explicit modules
258262
# needs opting in for a launcher, hence the second setting.
259-
run: xcodebuild archive -workspace ReactTestApp.xcworkspace -configuration Release -scheme ReactTestApp -destination "generic/platform=iOS Simulator" -archivePath ./build/test-app.xcarchive CODE_SIGN_IDENTITY="-" CODE_SIGNING_ALLOWED=YES C_COMPILER_LAUNCHER=ccache CLANG_ENABLE_EXPLICIT_MODULES_WITH_COMPILER_LAUNCHER=YES | xcbeautify
263+
run: xcodebuild archive -workspace ReactTestApp.xcworkspace -configuration Release -scheme ReactTestApp -destination "generic/platform=iOS Simulator" -archivePath ./build/test-app.xcarchive CODE_SIGN_IDENTITY="-" CODE_SIGNING_ALLOWED=YES C_COMPILER_LAUNCHER=ccache CLANG_ENABLE_EXPLICIT_MODULES_WITH_COMPILER_LAUNCHER=YES
260264
working-directory: apps/test-app/ios
261265
- name: Run test app
262266
run: |

0 commit comments

Comments
 (0)