-
Notifications
You must be signed in to change notification settings - Fork 263
Disable implicit dependency finding and parallelized builds for Xcode schemes #95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…t schemes This is an attempt to resolve intermittent build failures that have the appearance of being caused by a race condition.
Neat! @mike-ferris-apple, could we kick off a test for this? Can't wait to see if this finally fixes our OS X CI...! |
@swift-ci please test |
Wow, I can't believe it!! The OS X build succeeded and all tests passed! But it looks like a Jenkins failure failed the entire build. Can we try again? |
Awesome! Though, to be fair, I'm not confident that my changes are responsible for the Foundation build having gone through this time, we could still have a case of intermittent failures on our hands with this one. Regarding the Jenkins failure, it looks like the XCTest job may need some configuration adjustment. There seem to be a bunch of folks talking about this particular failure, e.g. http://slopjong.de/2014/10/15/jenkins-xunitpublisher-aborted-due-to-exception-the-types-section-is-required/ @shahmishal could you have a look at this when you get a chance? 🙇 |
Yes, it looks like a config issue. |
Well, looks like the previous failure showed up again. I find it very interesting to note that builds #38 and #40 both failed with the odd Xcode assertion and both ran on the Mac-OSX-07 worker, while build #39 passed that stage and ran on a different worker. @shahmishal Could you help us understand how the OSX workers do/don't perform cleans, and what those cleans look like? I've got a hunch about what's going on here that I'll try to explore shortly. |
I managed to repro the scenario occurring on Mac-OSX-07 by running the build script as it existed before swiftlang/swift#2036 and then running it again in its new form. When building in a configuration that involves the I've opened swiftlang/swift#2137 which I believe will solve this problem. |
Errm, this is the other PR that I actually meant when asking for a CI request before |
@swift-ci please test |
The Linux build failed due to unrelated test failures. This change to the Xcode project only affects OS X builds--and the OS X CI build passed! The build also pointed out some warnings introduced by swiftlang/swift#2433:
|
This is an attempt to resolve intermittent build failures that have the appearance of being caused by a race condition, as in the latest OS X CI run on #77.
Even if this doesn't directly fix that CI issue, it's probably a good idea to make this change anyway. Corelibs Foundation has these flags off also, and we have very little to gain from parallelized target builds due to the shape of our dependency graph.