background:
The company projects its own private CocoaPods get a warehouse, I will private warehouse by pod repo add privatefactory "http://xxx.xx.xx.xx/mygit.git"
adding to the local
modified a pod, the latest version 1.3.5 of the pod pushed to the warehouse
and then by local pod repo update privatefactory
update the local repository
problem:
The content of the Podfile is as follows:
platform :ios, '7.0'
source 'http://xxx.xx.xx.xx/mygit.git'
source 'https://github.com/CocoaPods/Specs.git'
target 'Sample' do
pod 'SamplePod','~> 1.3.1'
end
After pod install --no-repo-update
installing the pod, it turns out that the SamplePod version 1.3.1 is still used instead of the latest 1.3.5.
the reason
Looking at the /.cocoapods/repos
directory, I found that my private warehouse has two folders, the privatefactory I manually added and a 2-mygit folder. The SamplePod in the privatefactory folder is the latest version 1.3.5, and the version in 2-mygit is the old version 1.3.1.
After some debugging and comparison, I found the reason:
because in my Podfile, the source is configured with a git address, so when pod install is executed, it will not use the private factory private warehouse I manually added, but go to the 2-mygit warehouse. If it does not exist, it will be re-pulled. If it already exists, the warehouse will be used directly and the warehouse will not be updated.
My problem is that the 2-mygit warehouse existed before, and the version of SamplePod was 1.3.1, and I manually updated the privatefactory warehouse, the 2-mygit warehouse was not updated, and 2-mygit was not updated during pod install. So the old git was used.
Solution
After testing, it is found that if the name of the local warehouse is the same as the name of the git warehouse project, the warehouse name will be used directly when pod install.
Therefore, requiring everyone to set the name of the local warehouse to the name of the warehouse project seems to be able to solve this problem, and there will be no problem of multiple warehouses.
However, such a solution is risky. If a developer does not follow the requirements and is packaged on his own machine, there will be a problem of using the old pod.
Therefore, the safest way is to use jenkins to package on a dedicated packaging machine to avoid code integration problems due to the native environment.