gym hangs on xcrun

[yocontra]

When gym runs xcrun, it never continues because the xcrun command never closes itself.

Running xcrun xcodebuild -list -project './platforms/ios/Charmed.xcodeproj' by hand shows this:

It seems as if gym is expecting that xcrun will print the info then close, but in reality it is printing the info and staying open so gym never continues.

[yocontra]

Okay - this is really weird: having xcode open makes the xcrun command close as expected. But only when xcode is open.

If anyone else is having this problem: keep xcode open while gym is running.

[BKAppsmart]

I too had this issue, the fix was to have xcode open whilst gym occurs, however I am trying to create a process that fully automates the process and to open xcode is a massive flop in this system, is there a way around it that? I want to just be able to enter gym and done, rather than open xcode, enter gym and done ...

[KrauseFx]

I just tested, it's working fine for me without having to run Xcode. Which version of Xcode and gym are you using?

[KrauseFx]

Are you connected via ssh or locally?

[BKAppsmart]

gym 1.1.5
xcode 7.1
locally :)

• yeah for some reason it just hangs at that xcode line :S

[yocontra]

gym 1.1.5
xcode 7.1.1
local

[filipesperandio]

Having the same problem.
gym 1.1.5
Xcode 6.4
Yosemite
locally

[BKAppsmart]

Any news on this? as Im creating like a fully automated upload system and last night I set off like 10 apps going and it hung on the first one all night because of this:

�[37m[19:15:09]: �[0m�[33mxcrun xcodebuild -list -project 'PATH_TO_PROJ.xcodeproj'�[0m

I even made a work around where I use a bash script to open the xcode project first and sleep for a few seconds due to the loading time of xcode but that wasn't even long enough. please let me know if there is anything I can do to help...

[filipesperandio]

I had to do the same. Very hacky!
I don't have much knowledge around xcode to think of an alternative.
Also waiting for ideas...

[kugaevsky]

Had the same trouble few days ago.
My problem was that xcrun xcodebuild -list -project looking for user scheme in project directory. xcuserdata is where it should be located.

The solution for me was to install xcodeproj gem – gem install xcodeproj.
Create small script to recreate user schemes

#!/usr/bin/env ruby
require 'xcodeproj'
xcproj = Xcodeproj::Project.open("MyProject.xcodeproj")
xcproj.recreate_user_schemes
xcproj.save

And execute it. After this xcrun xcodebuild -list -project runs smooth.
Hope it helps you!

[filipesperandio]

Still hangs...

[kugaevsky]

@filipesperandio Do you have xcuserdata in your project directory after running script?

[vorobievalex]

The same for me.
gym 1.1.6
scan 0.3.2
Xcode 7.1.1
El Capitan
ssh

scan also freezes after 'Build Succeeded'.

[filipesperandio]

@kugaevsky: It is a Cordova/Ionic project, so after creating the xcode project with ionic build ios I end up with .xcodeproj directory but xcuserdata is only created after opening XCode, which is exactly what I am trying to avoid. You might have some clue there?

[filipesperandio]

@kugaevsky: I've also run the script you mentioned, it creates the xcuserdata but gym hangs the same way.

I also noted that opening XCode from the .xcodeproj directory creates a project.xcworkspace besides xcuserdata. Is there a way we can automate that?

[kugaevsky]

@filipesperandio Yep, there is a in my previous comment.

[filipesperandio]

Thanks, @kugaevsky.
The fact that I didn't even have a project.xcworkspace was the root cause of my problem.
I've made a workaround script to basically add those files based on what XCode generates, not good for long term, but got me unblocked... =\

[tabrindle]

The issue here isn't really with gym - as @kugaevsky has pointed out it is a cordova issue where schemes are not created with the project, and so xcodebuild hangs. Xcodebuild should throw an error for this. and return a nonzero exit code.

In any case, the xcproj.recreate_user_schemes script works for me.

@KrauseFx Would there be any merit in having a timeout on the xcrun xcodebuild -list command in your script where after a set timeout it returns a status code < 0? A lot of us are using this in a CI environment, and we need to know that something isn't working. If the script never exits, no error will be reported.

[filipesperandio]

That sounds good! 👍

[yocontra]

Instead of erroring on hang, why not fix it by running recreate_user_schemes and move along?

[vorobievalex]

In my case this did not reproduce under another user on the same mac. It seems that something screwed up for the particular user only. No cleanup helped, so I have just changed user at this machine.

[lacostej]

We had the same issue on the xcode plugin in jenkins a while back. The solution was to add a 10 second timeout.

Issue: https://issues.jenkins-ci.org/browse/JENKINS-24874
Fix: https://github.com/jenkinsci/xcode-plugin/pull/58/files

See also the current stackoverflow explanation for the timeout http://stackoverflow.com/questions/5959382/building-with-xcodebuild-timed-out-waiting-for-ideworkspace-0x2004cebc0-runc

[lacostej]

See fastlane-old/fastlane_core#69 for the PR. Sorry for the above duplicated notifications, I was cleaning my repo...

[KrauseFx]

Thank you so much @lacostej! 👍 I just pushed a new release, please test it and let us know if it works 👍

[jk]

I've read the issue but none of the proclaimed solution works for me.

When I run xcrun xcodebuild -list -workspace './MyProject.xcworkspace' manually (without an open Xcode, since its a CI build using gitlab-ci) I see all my targets etc. But: from time to time my builds pass - so this looks like a timeing issue. When I run time xcrun xcodebuild -list -workspace './MyProject.xcworkspace' the command needs at most 1 sec. Looks like fastlane-old/fastlane_core#69 didn't fix the issue :(

Any ideas?

[jk]

By the way, I never had the issue while running on 1.48.0.

[nikolaykasyanov]

Any hope to get a fix/workaround?

[dnstevenson]

We see this frequently on our slower build machines (i.e. a 3 year old mac mini). Modern machines (my MBP August 2015 for instance) never gets this.

[willm]

As a workaround see my answer re the xcode gem
On 3 Feb 2016 17:02, "dnstevenson" notifications@github.com wrote:

We see this frequently on our slower build machines (i.e. a 3 year old mac
mini). Modern machines (my MBP August 2015 for instance) never gets this.

—
Reply to this email directly or view it on GitHub
#143 (comment).

[dnstevenson]

@willm unfortunately that didn't resolve the timeouts on our slow machines.

[nikolaykasyanov]

@dnstevenson I can confirm this, our CI Mac is Mac Mini

[jk]

@dnstevenson Same here, Mac mini as CI server

[snod]

@dnstevenson Same issue here, also a Mac mini as Jenkins Slave

[lacostej]

I think there are 2 problems to fix:

1. some people might want to override the timeout value.
2. using timeout only wasn't maybe the most rock solid solution, processes must be killed properly. (see https://redmine.ruby-lang.org/issues/4681)

I've spent 2 hours yesterday trying to find a proper way to run the program, but I always end up having a child process running after killing it upon time out. I've tried IO, open3, open4, etc.

I'll try to propose a patch to solve the first one at least. That may unlock some people

[lacostej]

I implemented #2 to allow to override the timeout. Someone wants to try that out ?

use FASTLANE_XCODE_LIST_TIMEOUT=0 for example.

gem 'rails', :git => 'git://github.com/lacostej/fastlane_core.git', :branch => 'timeout_xcode_list'

[lemonkey-medhelp]

Same here, Jenkins on Mac Mini. Always happens on the first build of the day, then it's fine for subsequent builds.

[acerbetti]

same here, old mac mini for CI.

[Ricowere]

Hi guys,

We were struggling a lot with this timeouts recreating the user schemes. Since the new environment FASTLANE_XCODE_LIST_TIMEOUT included in Fastlane and after evaluating it in our CI system during a while, everything is working like a charm.

Many thanks guys. You're awesome. ;)

PS: Server machine specs:

• Mac mini Server (Late 2012)
• Processor: 2.3GHz Intel Core i7
• RAM: 16GB`

[fastlane-bot-helper]

This issue was migrated to fastlane/fastlane#1844. Please post all further comments there.

fastlane is now a mono repo, you can read more about the change in our blog post. All tools are now available in the fastlane main repo 🚀