Cocoapods: Pod cache automatically clean on CI machine.

[Serena1993]

I have met a problem with the CI machine.
When the different source control in Podfile.lock.
One is 1.9.1 and another is 1.9.3.
When two CI jobs run concurrently.
The pod cache has version control, too.
The two jobs will affect each other.
I found clean cache will cause the job to fail.
Is there any method that can resolve this problem?
Thanks

• [x] I've read and understood the CONTRIBUTING guidelines and have done my best effort to follow.

Report

What did you do?

ℹ Please replace these two lines with what you did.
bundle exec pod install --repo-update

What did you expect to happen?

Install all pod dependencies correctly.
Provide a method that can manage different version pod cache.
Not always automatic remove instead.

What happened instead?

Provide a method that can manage different version pod cache.
Not always automatic remove instead.

CocoaPods Environment

ℹ Please replace these two lines with the output of pod env.

Stack

   CocoaPods : 1.9.1
        Ruby : ruby 2.6.0p0 (2018-12-25 revision 66547) [x86_64-darwin18]
    RubyGems : 3.0.8
        Host : Mac OS X 10.15.3 (19D76)
       Xcode : 11.4 (11E146)
         Git : git version 2.24.1 (Apple Git-126)
Ruby lib dir : /Users/user/.rvm/rubies/ruby-2.6.0/lib
Repositories : private-ios-repo - git - https://xxx.git
               master - git - https://github.com/CocoaPods/Specs.git @ b03992ca780dd821b1ae43269cae640f1f32e3b1

Installation Source

Executable Path: /Users/user/.rvm/gems/ruby-2.6.0/bin/pod

Plugins

cocoapods-bin                         : 0.1.29
cocoapods-deintegrate                 : 1.0.4
cocoapods-disable-podfile-validations : 0.1.1
cocoapods-generate                    : 1.6.0
cocoapods-packager                    : 1.5.0
cocoapods-packager-pro                : 1.5.4
cocoapods-plugins                     : 1.0.0
cocoapods-search                      : 1.0.0
cocoapods-stats                       : 1.1.0
cocoapods-tdfire-binary               : 2.0.9
cocoapods-trunk                       : 1.5.0
cocoapods-try                         : 1.2.0

Podfile

source 'https://github.com/CocoaPods/Specs.git'
source 'https://git.xxx.com/privateSpecs.git'
platform :ios, '11.0'

use_frameworks!

install! 'cocoapods', disable_input_output_paths: true

def add_multi_target_pods
...
end

target 'Main' do

  add_multi_target_pods


  post_install do |installer|
      ...
    # Patch CCGestureLock
    `patch -p0 < Patches/CCGestureLock.swift.diff`

    # Write the acknowledgements

  end

end

target 'Widget' do

  add_multi_target_pods

end

Project that demonstrates the issue

ℹ Please link to a project we can download that reproduces the issue.
You can delete this section if your issue is unrelated to build problems,
i.e. it's only an issue with CocoaPods the tool.

[Serena1993]

https://github.com/CocoaPods/CocoaPods/issues/7915

[Westacular]

The CocoaPods cache can break in more ways than just this when two pod commands are run concurrently. (e.g. two repo-update commands can clash when both trying to modify things in ~/.cocoapods/ at the same time, and two pod install commands can conflict/race each other if they both try to download the same pod to the cache at the same time, even if the same version of cocoapods is used for both)

The way I've worked around this for concurrent CI jobs is with a lock file to ensure only one job is performing a pod command at a time. We use Fastlane, so I used the filelock gem and just enclosed every call to cocoapods in a block like

fastlane_require 'filelock'
Filelock [some_lock_file_path], :timeout => 1200, :wait => 3600  do
    ... cocoapods commands...
end

which ensures that any other jobs will block and wait until it's safe to continue.

I think Cocoapods should probably implement similar locking behaviour internally.

[dnkoutso]

Seems like something to heavily improve. The workaround posted here might be OK for folks who hit this issue.

[Serena1993]

still following this question