Skip to main content
All CollectionsKnowledge BaseGeneral issues
Committing your dependencies into your repository
Committing your dependencies into your repository
Updated over a week ago

Issue

Should I commit my dependencies into my repository?

Possible solutions

We recommend including your dependencies inside your repository whenever possible.

Bitrise, of course, supports using dependency managers and package managers. But we do think that having full control over dependency changes and having a more reliable setup provides enough advantage in most cases. Let’s see the reasons!

Reliability

Network issues are a lot less likely to cause problems: builds won’t fail just because a dependency manager’s server is down.

Similarly, using different versions of the dependency manager tool in different environments can normally cause problems: version updates can introduce changes that break compatibility with previous versions. With your dependencies stored in the repository, you are not forced to use the exact same version of the tool across your team and on the CI service.

Packages/dependencies can disappear from the dependency manager. This can break the project at the worst time and is avoidable by not relying on the dependency manager.

Speed

This is fairly obvious: your builds will be faster if there are no dependencies to download. For example, if you use CocoaPods and commit your Pods directory and the .xcworkspace generated by CocoaPods, you can remove the CocoaPods Install Step from your Bitrise configuration.

Control

With the dependencies stored in the repository, you see every single dependency update in your repository and you can review the changes in git. You have full control over whether to upgrade to a newer version of any dependency.

There are no more issues with private submodules or private pods. Using private submodules can be tricky because granting access requires some sort of workaround to grant access with SSH keys. If you have every dependency in your repository, a single read-only deployment SSH key will be enough.

Did this answer your question?