Should Tests/Pods be checked into version control?

[rhgills]

The main argument I'm aware of for doing so is to ensure that all checkouts of the repo are able to successfully build, regardless of if any depended upon cocoapods have had their git repositories deleted or are otherwise unavailable. This obviously does not apply to the Typhoon pod, which is in the same repository as the Tests client; but it does apply to the other test dependencies, OCHamcrest and OCMockito.

In addition, by checking Tests/Pods into VCS, assuming we remember to run pod update or have a script to run pod update for us before each commit, we avoid the need for a pod install before being able to run unit tests with a fresh clone of the repo. We also avoid the need for a pod update when pulling changes from the repository.

On the other hand, we currently end up with redundant and duplicate changes. If we change a library source file, then run pod update, then commit, we will see two changes to the same source file; one change will be made to the 'actual' source file under Source, and the other made to the Tests/Pods copy. IIRC specifying a local path for a pod should usually result in an alias to the original file under Pods/, not a copy; I'll have to look into this as well.

EDIT: Okay, after deleting the Pods/ directory and running pod install, copies of Typhoon library files are no longer made under Pods/ - the original files under Source/ are used instead, as desired. This may or may not be related to having just updated coocapods. Manually deleting the Pods/ directory, and running pod install after some configuration changes appears necessary.

So, to summarize:

Check Pods/ into VCS?

For:

• risk of OCHamcrest and OCMockito repositories disappearing or being temporarily unavailable when we clone a fresh copy of the Typhoon repository and wish to run unit tests
• don't have to know to run pod install under Tests/ when cloning the fresh
• don't have to remember to run pod update under Tests/ after git pull

Against:

• have to remember to run pod update before committing (can be mitigated by automatically running as part of builds, see Add a run script build phase to all test targets that runs pod install #53)
• cocoapods clutter in changesets/commit messages (EDIT: No longer an issue as duplicates of source files are not made)

Currently I'm for, especially if I can figure out why copies are being made in Pods/ instead of aliasing to the original source files.

[jasperblues]

I while back, I was always hesitant to check them in. . . but it seems to work fine.

This question has turned up on the CocoaPods mailing list, and it seems to be their official recommendation, actually.

On Sep 1, 2013, at 1:42 AM, Robert Gilliam notifications@github.com wrote:

The main argument I'm aware of for doing so is to ensure that all checkouts of the repo are able to successfully build, regardless of if any depended upon cocoapods have had their git repositories deleted or are otherwise unavailable. This obviously does not apply to the Typhoon pod, which is in the same repository as the Tests client; but it does apply to the other test dependencies, OCHamcrest and OCMockito.

In addition, by checking Tests/Pods into VCS, assuming we remember to run pod update or have a script to run pod update for us before each commit, we avoid the need for a pod install before being able to run unit tests with a fresh clone of the repo. We also avoid the need for a pod update when pulling changes from the repository.

On the other hand, we currently end up with redundant and duplicate changes. If we change a library source file, then run pod update, then commit, we will see two changes to the same source file; one change will be made to the 'actual' source file under Source, and the other made to the Tests/Pods copy. IIRC specifying a local path for a pod should usually result in an alias to the original file under Pods/, not a copy; I'll have to look into this as well.

So, to summarize:

Check Pods/ into VCS?

For:

risk of OCHamcrest and OCMockito repositories disappearing or being temporarily unavailable when we clone a fresh copy of the Typhoon repository and wish to run unit tests

don't have to know to run pod install under Tests/ when cloning the fresh

don't have to remember to run pod update under Tests/ after git pull

Against:

have to remember to run pod update before committing (can be mitigated by automatically running as part of builds, see #53)

cocoapods clutter in changesets/commit messages

Currently I'm for.

—
Reply to this email directly or view it on GitHub.

[rhgills]

Interesting, that's good to know. We'll leave it checked in.