-
Notifications
You must be signed in to change notification settings - Fork 87
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
Conversation
a995302
to
545f1f4
Compare
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. |
545f1f4
to
724f638
Compare
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/) |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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!
Anything else that needs to be changed before merging? |
There was a problem hiding this 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?
62a35dd
to
233dc65
Compare
Hey @eliperkins I've just rebased |
Shoot...have an issue the iOS build in Travis...will have to fix when i'm back at a computer. |
3f95853
to
dacbbe1
Compare
@eliperkins it looks like the error code on the iOS build is the infamous error code 65 and that job |
@eliperkins just thought I'd check in on the status of this PR. Hope you're doing well. |
Hi @loudmouth, could you rebase once more? There appears to be an Interaction.swift conflict |
7a20a7f
to
713bad7
Compare
Add swift build to the script
7603602
to
c510295
Compare
c510295
to
e95a58e
Compare
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? |
@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 :-) |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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} \ |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 😛
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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. 👍
There was a problem hiding this comment.
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) |
There was a problem hiding this comment.
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!
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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 👍
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 😉 )
2e7c4a1
to
26a9d1a
Compare
26a9d1a
to
13118e5
Compare
I think that's all the things. I'll leave it up to you guys at this point :-) |
@eliperkins @kiliankoe @dmiluski any chance we can merge? I wanna rebase #80 so that CI passes there. |
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 thereforeswift test
fails as cassettes cannot be found. Once support for bundling other resources withswift build
, then we should update the travis script to runswift test
.Lastly, this fixes the travis builds that were broken on
master
.Addresses #67