Skip to content

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

Merged
merged 1 commit into from
May 7, 2016

Conversation

briancroom
Copy link
Contributor

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.

…t schemes

This is an attempt to resolve intermittent build failures that have the
appearance of being caused by a race condition.
@modocache
Copy link
Contributor

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...!

@parkera
Copy link
Contributor

parkera commented Apr 10, 2016

@swift-ci please test

@modocache
Copy link
Contributor

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?

@briancroom
Copy link
Contributor Author

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? 🙇

@shahmishal
Copy link
Member

Yes, it looks like a config issue.
lets try this again. @swift-ci Please test OS X platform

@briancroom
Copy link
Contributor Author

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.

@briancroom
Copy link
Contributor Author

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 install action (as the old script did), Xcode creates a symlink from the product in the BUILT_PRODUCTS_DIR to its installed location in DSTROOT. This symlink was never cleaned up when we stopped performing installs, which meant that attempts to create the real framework build product were failing because the old symlink was in the way. Note that all this is occurring in the system-wide DerivedData directory which seems to be fully persistent on the build machines.

I've opened swiftlang/swift#2137 which I believe will solve this problem.

@briancroom
Copy link
Contributor Author

Errm, this is the other PR that I actually meant when asking for a CI request before

@modocache
Copy link
Contributor

@swift-ci please test

@modocache
Copy link
Contributor

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:

/Users/buildnode/jenkins/workspace/swift-corelibs-xctest-PR-osx/swift-corelibs-xctest/Sources/XCTest/XCTestCase.swift:25:89: warning: single argument function types require parentheses
public typealias XCTestCaseEntry = (testCaseClass: XCTestCase.Type, allTests: [(String, XCTestCase throws -> Void)])
                                                                                        ^~~~~~~~~~
                                                                                        (         )
/Users/buildnode/jenkins/workspace/swift-corelibs-xctest-PR-osx/swift-corelibs-xctest/Sources/XCTest/XCTestCase.swift:84:53: warning: single argument function types require parentheses
    public required init(name: String, testClosure: XCTestCase throws -> Void) {
                                                    ^~~~~~~~~~
                                                    (         )
/Users/buildnode/jenkins/workspace/swift-corelibs-xctest-PR-osx/swift-corelibs-xctest/Sources/XCTest/XCTestCase.swift:36:30: warning: single argument function types require parentheses
    private let testClosure: XCTestCase throws -> Void
                             ^~~~~~~~~~
                             (         )

@modocache modocache merged commit 4a25dfc into swiftlang:master May 7, 2016
@briancroom briancroom deleted the unparallelize-builds branch May 11, 2016 04:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants