You can sometimes get away with commit built artifacts to a repo, but it's often not a great practice.
In our case it seems to work. However there may be advantages to a "cleaner" approach, such as: http://www.mokacoding.com/blog/carthage-no-build/
Also not the primary goal of this goal, manually integrating dependencies may let us reduce the number of embedded frameworks, which is impacting load time.
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • AMroczkowski | T157374 iOS Tech Review | |||
| Resolved | JoeWalsh | T158213 Investigate ways to not commit Carthage/Build to the repo | |||
| Resolved | • AMroczkowski | T158219 README instructions for running tests is incorrect |
The mokacoding suggestion (adding carthage dependencies as projects to the workspace) puts us back in the realm of cocoapods - having to re-build every dependency on a clean build.
From Carthage's instructions about Carthage/Build:
You are not required to commit this folder to your repository, but you may wish to, if you want to guarantee that the built versions of each dependency will always be accessible at a later date.
So committing the built products isn't totally against their workflow.
The other suggested workflow is to gitignore Carthage/Build and for new users to run carthage bootstrap --platform iOS to checkout and build the versions specified in Cartfile.resolved. For our project, this takes a significant amount of time. 6 minutes and 23 seconds on this 2015 MacBook Pro, 11 minutes on the Mac Mini that runs Jenkins.
The downside to this approach is that whenever dependencies are updated, developers and our CI machine(s) would be out of date. This would be alright if there was a quick way to update only the changed dependencies as a step in the build process. Unfortunately, I couldn't find a way to do this. If you run bootstrap again, it re-builds all frameworks regardless of whether or not they're already built and the same version ). So we would either need some way to detect for dependency version changes & run bootstrap in those cases, adding 6 minutes to those builds or just run bootstrap with every build.
I think the quickest way to make this work for us would be to add a step in the build process that checks if the Cartfile.resolved has changed since the last bootstrap run on this machine, and if so, re-runs bootstrap.
Proof of concept here: https://github.com/wikimedia/wikipedia-ios/compare/bug/T158213
The biggest downside to this approach is that it looks like XCode is broken while it's sitting there for 6 minutes on the run script build step.
Also forgot about this issue https://github.com/travis-ci/travis-ci/issues/4195 - unless you have GITHUB_ACCESS_TOKEN set, the initial checkouts can fail due to GitHub API rate limiting.