I havenât updated the this thread in a while, like I wanted to but we are struggling with a lot of things at the moment but things are looking better.
One feature that we rolled out lately is that we know collect xcactivitylogs which give much more information about certain failures. Please take a look in your artifacts.
I think this might be related to some Exit code 65 issues but not all, and it probably wont fix the UI tests issue. Itâs just something to try⊠but not yet last resort.
of course these 60 (!) seconds will not be taken into account for our build-minutes, right?
We already wasted quite a lot of minutes due to the problems with the Cocoapods Specs-repo cloning-issue, our builds took up to 45, 50 minutes then.
Since there was no solution in sight from Circles side and the Specs-repo was unfortunately not sharded back then, we created our own Specs repo with only the Specs we needed.
Then, upgrade to Xcode 8.1, the multiple devices issue.
Simulators not starting, crazy 65er errors, tbh, we are currently wasting a lot of time fixing issues with Circle.
This is not your fault, but I have the feeling that Circle should urgently hire more developers, because as far as I see it, you are too few people having a lot of pressure, which inevitably leads to regressions and long times for issues to be resolved.
weâre going to investigate alternative CI solutions since weâve lost days of dev time to circle issues. i realise no solution will be without problems, but we donât seem to be getting anywhere
To complete up my presence in this thread, i declare our build to be working again after several months - essentially since Xcode8 adoption. It was achieved through multiple changes. I donât claim any of it being the universal fix, but someone still can have an a-ha moment.
cleaned up, rethought and reapplied code signing. Xcode7 setup may not be good enough for Xcode8. Simulator builds do not âjust workâ anymore. Apple provisioning is damn complicated and clicking the shiny new âAutomatically manage signingâ will NOT fix your mess. Thanks @jeremyhu for this one.
migrate from Pods to Carthage. Podâs justification of basically taking over your project is âwill do everything for youâ. Since Xcode toolchain is being fragmented (and unfortunately also bugged so far) by Swift and its different runtime libs/frameworks philosophy, that justification does not apply anymore. In a complicated project with subprojects, various targets and mixed Swift/ObjC codebase, Pods required so many side hacks already, that Carthage actually made the build simpler.
solved exit code 65 with chruby system. Regarding adoption of upgraded system tools, Xcode toolchain is, uh, stiff somewhat. Anyone remember âresource-rules deprecatedâ in Xcode6? So thank you Circle for giving us the newest ruby as default, but our Xcode8 ipatool simply wonât work with any ruby>2.0.0. All you get to know is xcodebuild error âNo devices foundâ. Your build containers feel alone, it wants you to ssh in and read its xcactivitylogs.
Anybody having problems with iOS UI tests running, but failing on CircleCI? I have some simple XCTest cases that works fine when running locally on my machine, but when running on CircleCI they fail with errors like
"UI Testing Failure - No matches found for ScrollView" or other missing UI objects, and with exit code 65.
We have been having the same issue for a while as well: Exit Status: 65. We normally just do a manual rebuild and then it works after 1 or 2 times. But this really is a time suck.
Hello we are still getting this error very oftenly. We need a fix for that issue. We currently canât trust circle builds with that error always showing upâŠ
If youâre running into the error code 65 (and tests are passing) hereâs a command you can pipe on the end of your xcodebuild (assuming youâre running tests) command to get back more consistent results:
(XCODEBUILD_COMMAND_HERE) | awk 'BEGIN {success=0} $0 ~ /.* tests, with 0 failures \(.*/ {success=1} {print $0} END {if(success==0){exit 1}}
This looks for tests, with 0 failures ( in your output text, thus using the text output of xcodebuild instead of the status code of xcodebuild to determine success.
Note: Keep in mind, if you do something like NSLog(' tests, with 0 failures ('); in your code you make get a false positive, itâs very unlikely to happen by accident. You may have to update tests, with 0 failures ( in the awk script between updates of xcodebuild. But, having consistent results with xcodebuild is definitely worth that price.
After long looking for this Iâve just resolved an issue for one of our customers that had the exact same symptoms:
Sometimes exit code 65 during the build
UI test just wont run and fail with a missing element.
Youâre most likely running into issues with an UIAlert being on screen which expect user input, while the XCTest daemon quietly timesout in the background and eventually throws an error.
If you run into these issues please open a support ticket I would like to take a closer look at your builds and resolve this with you
Please checkout this post: Iâm looking to gather as much information as I possibly can in order to help Apple improve xcodebuild and the underlying toolchain for all of us.
If youâre interested please E-Mail me. All the data will be anonymized!