Skip to content
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

Swift package manager support #73

Merged
merged 10 commits into from
Jun 19, 2018
Merged

Conversation

loudmouth
Copy link
Contributor

@loudmouth loudmouth commented Sep 29, 2017

This PR restructures the repo's directories to enable Swift Package Manager.

It also adds a build job to the travis matrix that ensures swift build is working. Unfortunately, SPM does not enable including other resources (i.e. bundled content) like Xcode so therefore swift test fails as cassettes cannot be found. Once support for bundling other resources with swift build, then we should update the travis script to run swift test.

Lastly, this fixes the travis builds that were broken on master.

Addresses #67

@loudmouth loudmouth force-pushed the swift-package-manager branch 3 times, most recently from a995302 to 545f1f4 Compare September 29, 2017 11:08
@loudmouth
Copy link
Contributor Author

Only the iOS build has failed because of the infamous exit code 65 which is a known Xcode bug. Can somebody on the venmo org please restart the build? It should pass.

@loudmouth loudmouth force-pushed the swift-package-manager branch from 545f1f4 to 724f638 Compare September 29, 2017 11:18
Readme.markdown Outdated
[![Version](https://img.shields.io/github/release/venmo/DVR.svg)](https://github.com/venmo/DVR/releases) [![Carthage compatible](https://img.shields.io/badge/Carthage-compatible-4BC51D.svg?style=flat)](https://github.com/Carthage/Carthage)
[![Version](https://img.shields.io/github/release/venmo/DVR.svg)](https://github.com/venmo/DVR/releases)
[![Carthage compatible](https://img.shields.io/badge/Carthage-compatible-4BC51D.svg?style=flat)](https://github.com/Carthage/Carthage)
[![Swift Package Manager](https://rawgit.com/jlyonsmith/artwork/master/SwiftPackageManager/swiftpackagemanager-compatible.svg)](https://swift.org/package-manager/)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is probably the most minor of minor nitpicks ever, but the design of those two badges doesn't match up. How about using shields.io's custom badges for spm compatibility? 😊 E.g. https://img.shields.io/badge/SPM-compatible-brightgreen.svg

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick all you want @kiliankoe ;-)

Pushed with the badge you suggested. Thanks for the quick review!

@loudmouth
Copy link
Contributor Author

Anything else that needs to be changed before merging?

Copy link
Contributor

@eliperkins eliperkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems good to me! Thanks for looking into this.

Would you mind rebasing onto master to pickup the latest CI fixes?

@loudmouth loudmouth force-pushed the swift-package-manager branch 6 times, most recently from 62a35dd to 233dc65 Compare December 22, 2017 15:39
@loudmouth
Copy link
Contributor Author

Hey @eliperkins

I've just rebased

@loudmouth
Copy link
Contributor Author

Shoot...have an issue the iOS build in Travis...will have to fix when i'm back at a computer.

@loudmouth loudmouth force-pushed the swift-package-manager branch 3 times, most recently from 3f95853 to dacbbe1 Compare December 22, 2017 17:31
@loudmouth
Copy link
Contributor Author

@eliperkins it looks like the error code on the iOS build is the infamous error code 65 and that job
of the build should just be restarted and it will probably pass.

@loudmouth
Copy link
Contributor Author

@eliperkins just thought I'd check in on the status of this PR.

Hope you're doing well.

@dmiluski
Copy link
Contributor

Hi @loudmouth, could you rebase once more? There appears to be an Interaction.swift conflict

@loudmouth loudmouth force-pushed the swift-package-manager branch 2 times, most recently from 7a20a7f to 713bad7 Compare February 18, 2018 10:40
@loudmouth loudmouth force-pushed the swift-package-manager branch 5 times, most recently from 7603602 to c510295 Compare June 12, 2018 16:18
@loudmouth loudmouth force-pushed the swift-package-manager branch from c510295 to e95a58e Compare June 12, 2018 16:22
@loudmouth
Copy link
Contributor Author

Hey @dmiluski and @eliperkins

I'm really sorry it took me so long to get back to this—it's good to go now!

I had to update some code related to creating the test file for the upload test to pass on iOS, but everything is now green ✅

Any chance we can give this a merge and call it a day?

@loudmouth
Copy link
Contributor Author

loudmouth commented Jun 13, 2018

Just a note that we'll still need these two (duplicate) tickets in Swift Package Manager to be addressed for DVR to work with the swift build system on the command line:

SR-2866
SR-4725

Let's upvote there!

@loudmouth
Copy link
Contributor Author

@eliperkins @kiliankoe @dmiluski

I hope I don't become annoying in doing this, but i'd love to push forward this PR and then continue onto pushing for #80 after I rebase there.

This project is awesome and I use it to test the official Contentful Swift SDK, just wanna help keep it up-to-date and working for us all :-)

Copy link
Contributor

@eliperkins eliperkins left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, a few comments, but no blockers really.

set -x -o pipefail

if [[ "$SWIFT_BUILD" == "true" ]]; then
swift build
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is only running build and not test because of what you mentioned in this comment, correct? #73 (comment)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes exactly 👌


# -jobs -- specify the number of concurrent jobs
# `sysctl -n hw.ncpu` -- fetch number of 'logical' cores in macOS machine
xcodebuild -jobs `sysctl -n hw.ncpu` test -project DVR.xcodeproj -scheme ${TRAVIS_XCODE_SCHEME} -sdk ${TRAVIS_XCODE_SDK} \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this script taken from the Travis macOS config script? Is there a way we could shell out to that instead (so that we don't need to duplicate the code)?

Copy link
Contributor Author

@loudmouth loudmouth Jun 18, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, I'm not sure I understand. This is not a duplicate exactly of the script that was inlined int eh travis.yml previously. It's standard xcodebuild arguments, some of which consume environment variables which are set by Travis.

Is there a way we could shell out to that instead?

The travis yml is calling this script, as opposed to inlining the xcodebuild command.

Am I understanding correctly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, my question was more around "is there a version of this command that comes in the Travis container that we can use instead of rewriting it ourselves?"

That is, we can supply these Travis-specific env vars in the .travis.yml, and Travis will generate an xcodebuild command for us. I believe there's a build.sh script that is on the machine that's running the build, but I think it might be too late by the time our build has started to use this.

I don't think this should be a major blocker, but if we can figure out how to use the Travis env vars to generate an xcodebuild command rather than rewriting the command ourselves, we can save ourselves some headaches in the future.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said, I can't seem to find any documentation about this in the Travis docs. We can skip over this for now, unless you want to do any more digging or reverse engineering 😛

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh I see @eliperkins . I'm not too sure to be honest. I just googled around for a bundled build.sh for mac builds on travis but didn't find anything myself (it was a quick google to fair).

I'm not sure how different it is to delegate to a bash script, as you could see before my change the xcodebuild command was inlined right under script: in the yml file. The benefit of doing things this way is that we can have more fine grained control (i.e. if SWIFT_BUILD is set, then avoid running xcodebuild) and add more complexity to our build/test script. Of course we could have also done this inline in the yml file, but then it looks cluttered. It's just an approach I've taken on a lot of projects with travis, but I'm happy to revert and inline everything if you prefer. Just let me know.

The build is passing again, and I reverted the one env variable for the platform specification.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All good with me! Let's keep this as it is in this PR.

My main concern here was duplicating the usage of the Travis-specific variables. If Travis is going to dictate the API for variables like TRAVIS_XCODE_SCHEME and such, it would be good to ensure that we use their build command rather than duplicate it ourself.

Given that we can't seem to find how they use these variables beyond what we see in the output, I think it's fine to just roll our own. 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cool. i can investigate more as well and try to de-dup in my follow-up which i'm interested in #80

always happy to improve CI setup

@@ -86,8 +86,7 @@ class SessionUploadTests: XCTestCase {
}

private func writeDataToFile(_ data: Data, fileName: String) -> URL {
let documentsPath = NSSearchPathForDirectoriesInDomains(.documentDirectory, .userDomainMask, true)[0]
let documentsURL = URL(fileURLWithPath: documentsPath, isDirectory: true)
let documentsURL = try! FileManager.default.url(for: .documentDirectory, in: .userDomainMask, appropriateFor: nil, create: true)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this should throw instead of crashing... Not a blocker for this PR!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, i just figured since it's in the testing suite it didn't matter too much. if you think it's ok for now, i'll leave it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is totally fine! Either way, the test suite would crash anyway.

- xcode_scheme: DVR-macOS
xcode_sdk: macosx
env:
- DESTINATION="arch=x86_64"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did this need to change? I think we want to prefer attribute-based selection of destinations, rather than names (which Travis could change from underneath us at any time).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can try reverting this change and see how it goes 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so it turns out that both the platform and the architecture must be specified. the final command (with env variables filled in) is:

xcodebuild -jobs `sysctl -n hw.ncpu` test -project DVR.xcodeproj -scheme DVR-macOS -sdk macosx \
  -destination "platform=macOS,arch=x86_64" ONLY_ACTIVE_ARCH=YES CODE_SIGNING_IDENTITY="" CODE_SIGNING_REQUIRED=NO | xcpretty -c

I'm hoping Apple doesn't change the operating system name that often :-D

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome! I think "platform=macOS,arch=x86_64" is much better than OS X.

(especially when we need to do "platform=macOS,arch=arm64" down the line 😉 )

@loudmouth loudmouth force-pushed the swift-package-manager branch from 2e7c4a1 to 26a9d1a Compare June 18, 2018 16:03
@loudmouth loudmouth force-pushed the swift-package-manager branch from 26a9d1a to 13118e5 Compare June 18, 2018 16:03
@loudmouth
Copy link
Contributor Author

I think that's all the things. I'll leave it up to you guys at this point :-)

@loudmouth
Copy link
Contributor Author

@eliperkins @kiliankoe @dmiluski any chance we can merge?

I wanna rebase #80 so that CI passes there.

@dmiluski dmiluski merged commit 442afed into venmo:master Jun 19, 2018
@loudmouth loudmouth mentioned this pull request Jun 21, 2018
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