Broken Pipe in Gitlab With xcpretty
• 2 minute read
The constellation of GitLab CI, xcodebuild and xcpretty may result in an odd error and job failure. The missing piece to success is an environment variable.
To reduce the verbose output of xcodebuild during test runs we wanted to use xcpretty (again).
Note: we run test plans and Swift package tests as jobs in a GitLab CI pipeline.
Surprisingly, the jobs failed with a error I could not make sense of.
. test_GIVEN_cancelled_WHEN_performCallbackOnData_THEN_commandGetsFinished (0.038 seconds)
/Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/lib/xcpretty/parser.rb:434:in `===': invalid byte sequence in US-ASCII (ArgumentError)
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/lib/xcpretty/parser.rb:434:in `update_test_state'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/lib/xcpretty/parser.rb:307:in `parse'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/lib/xcpretty/formatters/formatter.rb:88:in `pretty_format'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/lib/xcpretty/printer.rb:19:in `pretty_print'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/bin/xcpretty:84:in `block in <top (required)>'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/bin/xcpretty:83:in `each_line'
from /Users/dev-mobile/.gem/ruby/2.6.0/gems/xcpretty-0.3.0/bin/xcpretty:83:in `<top (required)>'
from /Users/dev-mobile/.gem/ruby/2.6.0/bin/xcpretty:23:in `load'
from /Users/dev-mobile/.gem/ruby/2.6.0/bin/xcpretty:23:in `<main>'
2023-02-07 15:52:40.574 xcodebuild[33825:1130941] NSFileHandle couldn't write. Error: Error Domain=NSCocoaErrorDomain Code=512 "The file couldn’t be saved." UserInfo={NSUnderlyingError=0x600002a6daa0 {Error Domain=NSPOSIXErrorDomain Code=32 "Broken pipe"}}
The last error line repeats a lot of time from thereon.
Searching the web for “xcodebuild xcpretty broken pipe the file couldn’t be saved” yielded mixed results. Luckily, some of them were in context of GitLab CI already. I quickly found this helpful article about my exact problem.
So the root cause appeared to be that LC_ALL was undefined.
I quickly checked that on the systems in the macOS Terminal and indeed, its value was empty.
However I was not really satisfied with manipulating the service launch configuration.
Also, because we use automatically provision and configure our macOS CI machines.
I wanted something simpler and stable and checked whether there is a more direct way.
I found it in the GitLab documentation.
There is a possibility to add or override environment variables of runners in the ~/.gitlab-runner/config.toml.
Adding the following line to it and restarting the service quickly resolved the problem:
environment = ["LC_ALL=en_US.UTF-8"]
Yay, an xcpretty no longer got a sour stomach on xcodebuild output. 🎉