Xcodebuild - Skip Finished requesting crash reports. Continuing with testing

Question

I'm running a CI machine with the Xcode.

The tests are triggered using fastlane gym. I see this line in the output:

2019-05-27 16:04:28.417 xcodebuild[54605:1482269] [MT] IDETestOperationsObserverDebug: (A72DBEA3-D13E-487E-9D04-5600243FF617) Finished requesting crash reports. Continuing with testing.

This operation takes some time (about a minute) to complete. As far, as I understand, the Xcode requests crash reports from Apple to show in the "Organizer" window.

Since this is a CI machine, the crash reports will never be viewed on it and this step could be skipped completely how can I skip it?

Answer 1

Your mileage may vary, but after setting up a new machine with the following configuration, I encountered the same issue OP details:

• macOS 10.15.2
• Xcode 11.3
• fastlane 2.139.0
• Simulators @ 13.3

When I run my fastlane test with 3 devices, I wind up at the following message and was sitting idle for about four minutes before I terminated it:

I then took the steps that I outlined in the comment to OP:

1. fastlane scan init
2. Edit my scanfile to look like this

I initially set disable_concurrent_testing(false), and when I ran the tests through fastlane, I got stuck again. Changing the value to disable_concurrent_testing(true) has allowed the tests to now run on my machine.

Answer 2

I think blaming "Finished requesting crash reports. Continuing with testing" may be a red herring. I was having several jobs stop at this step, but when I looked closer (I ran the lane locally and tailed the logs) I saw that my test was failing due to something else. It looks like Fastlane doesn't correctly show how long this step takes, in fact, I think if you're seeing that message, the process is already complete, and your tests are running. That changing concurrency fixes it for you may indicate your tests are failing due to a race condition.

So, anyway. Install fastlane locally, run your lane locally, tail -f the build output as well as the log file and see if the problem is revealed there. It was for me, but, as with everything, YMMV.