macOS cache restore is extremely slow

[dexpota]

The macOS cache restore process is slow. I have created a repository that reproduces this slowness. You can find it here. Following is the screenshot of a run that took more than 2 hours.

This is the GitHub workflow.

name: Slow cache
on: [workflow_dispatch, push]
jobs:
  generate:
    name: Generate
    runs-on: macos-12
    steps:
      - uses: actions/checkout@v3
      - name: Add Specs repository
        run: pod repo add cocoapods https://github.com/CocoaPods/Specs.git
      - uses: actions/cache@v3
        with:
          path: ~/.cocoapods/repos/cocoapods
          key: ${{ runner.os }}-cocoapods-specs
  restore:
    name: Restore
    needs: generate
    runs-on: macos-12
    steps:
      - name: restore cached large file
        uses: actions/cache@v3
        with:
          path: ~/.cocoapods/repos/cocoapods
          key: ${{ runner.os }}-cocoapods-specs

Let me know if I can provide more information about it.

[jack828]

I've been looking into this in my use case as well (which just so happens to be identical to you!) and can see that it appears to be directly related to decompression performance.

wget "https://api.github.com/repos/CocoaPods/Specs/tarball/master" -O /tmp/cocoapods.tar.gz
tar xzf /tmp/cocoapods.tar.gz -C ~/.cocoapods/repos/master --strip-components=1

On my local mac, this takes ~120 seconds to extract. On the runner, this takes ~12 minutes.

Compared to zip:

wget "https://api.github.com/repos/CocoaPods/Specs/zipball/master" -O /tmp/cocoapods.zip
unzip -q /tmp/cocoapods.zip -d ~/.cocoapods/repos/master            

(note this gives some illegal byte sequence errors where tgz does not)

Local: ~150 seconds

Runner: ~13 minutes (it appeared to have failed)

I hope that helps the github team investigate somewhat.

EDIT: for anyone that manages to google their way here regarding corova and a pod setup error...I appear to have worked around it by just creating the required directory at ~/.cocoapods/repos/master and making sure plugins all reference the CDN instead of the monster specs repo.

[bishal-pdMSFT]

@pdotl @Phantsure

[dexpota]

I tested your commands on the runner and I got different results but the runner is still slower than a local run of those commands.

Here are the workflow's logs, and the following are the timings of execution.

With gtar.

real    4m13.946s
user    0m15.666s
sys 3m10.718s

With tar.

real    5m55.109s
user    0m33.185s
sys 4m40.387s

[penchef]

Here's an example repo/workflow caching node_modules

the cache restore seems to be particularly bad with lots of files, like the node_mules folder

https://github.com/penchef/slow-actions-cache/actions/runs/4433049196

[GMNGeoffrey]

AFAICT, it isn't just slow: it also gets stuck at a certain point and never makes any more progress. I had it hanging for an hour before timing out (before the default timeout was lowered to 10 minutes). That seems to be what's reported in https://github.com/actions/cache/issues/1136, but that appears to be talking about something called "pods", which I'm not familiar with. Here are several other cases:

• https://github.com/openxla/iree/actions/runs/4553579285/jobs/8030314534
• https://github.com/openxla/iree/actions/runs/4550517065/jobs/8023610919
• https://github.com/openxla/iree/actions/runs/4530137880/jobs/7978692296

Here's one with debug logging enabled: https://github.com/openxla/iree/actions/runs/4522483132/jobs/7990992043

Here's a very similar workload, but it succeeded in 3 minutes: https://github.com/openxla/iree/actions/runs/4516271068/jobs/7954411399

[thinkafterbefore]

Hey everyone,

I'm Adam, co-founder of BuildJet. Our customers often complain about reliability and speed issues like the one reported here. Today, we launched BuildJet Cache, a GitHub Cache alternative thats reliable, fast and free.

It’s fully compatible with GitHub’s Cache, all you need to do is replace action/cache with buildjet/cache. It works on any runner - be it official, self-hosted, or BuildJet. Whichever runner you choose, BuildJet Cache doubles your free storage, offering a generous 20 GB/repo/week storage space at no cost.

Head over to our launch post for more details: https://buildjet.com/for-github-actions/blog/launch-buildjet-cache

[bennettp123]

For anyone who stumbles onto this thread via google: if you're experiencing slow restores of cocoapods caches, make sure you're not using the cocoapods repo in your Podfile, as per https://blog.cocoapods.org/CocoaPods-1.7.2/

diff --git a/ios/Podfile b/ios/Podfile
index 10f8114..91bd817 100644
--- a/ios/Podfile
+++ b/ios/Podfile
@@ -1,6 +1,6 @@
 require_relative '../node_modules/react-native/scripts/react_native_pods'
 require_relative '../node_modules/@react-native-community/cli-platform-ios/native_modules'
-source 'https://github.com/CocoaPods/Specs.git'
+source 'https://cdn.cocoapods.org/'

 platform :ios, min_ios_version_supported
 prepare_react_native_project!

Before:

After:

Note that I also changed the restore key to prevent it from using the old cache:

diff --git a/.github/workflows/build-ios.yml b/.github/workflows/build-ios.yml
index cab57b3..0d04a17 100644
--- a/.github/workflows/build-ios.yml
+++ b/.github/workflows/build-ios.yml
@@ -125,20 +124,17 @@ jobs:
       - name: Cache CocoaPods
         uses: actions/cache@v3
         timeout-minutes: 5
         continue-on-error: true
         with:
           path: |
             ios/Pods
            ~/Library/Caches/CocoaPods
            ~/.cocoapods
-          key: ${{ runner.os }}-pods-${{ hashFiles('**/Podfile.lock') }}
+          key: ${{ runner.os }}-pods-trunkrepo-${{ hashFiles('**/Podfile.lock') }}
           restore-keys: |
-            ${{ runner.os }}-pods-
+            ${{ runner.os }}-pods-trunkrepo-

[github-actions[bot]]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[github-actions[bot]]

This issue was closed because it has been inactive for 5 days since being marked as stale.