Closed dexpota closed 8 months ago
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.
@pdotl @Phantsure
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
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
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:
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
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
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-
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.
This issue was closed because it has been inactive for 5 days since being marked as stale.
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.
Let me know if I can provide more information about it.