@a-25 Thanks for the tackling this potential CI improvement. A good next step would be to demonstrate the performance improvement of using the buildcache plugin. That might be easier to do in your forked repo and then provide links that show the advantage of the cache.

@paulb777: Hello. I made some measurements, they are below. Used only core.yml file for instance.

We are interested in "iOS Unit Tests" and "Post Run mikehardy/buildcache-action@v1" sections.

• Without buildcache - https://github.com/a-25/firebase-ios-sdk/runs/4440188088?check_suite_focus=true
• With buildcache, first time (cache warm up) - https://github.com/a-25/firebase-ios-sdk/runs/4440226702?check_suite_focus=true
• With buildcache, second time (no files changed) - https://github.com/a-25/firebase-ios-sdk/runs/4440252091?check_suite_focus=true

As I see, the cache at least doesn't slow the process down. And building with cache gives about 40% increase.
I think the more accurate statistics should be collected later, after using. But as I see most files will remain unchanged (because one PR is usually devoted to only one project while others stay the same).
Also I tried to use separate caches for different OS to reduce cache rebuilding.

Thanks @a-25 . The 40% improvement is great!

For security concerns, we're not comfortable depending on a third-party action specified with a tag. Would you update to a commit hash? See https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions and https://michaelheap.com/improve-your-github-actions-security/

@a-25 Let me know if you want to continue this. Otherwise I can pick it up in the next week or two.

@paulb777: Hello. Yes, I'm going to finish this one soon. Was busy lately.

@paulb777: updated the hash, waiting for the checks to prove everything is working.

@a-25 Thanks. Sorry for the delay in unblocking the CI. It looks like something about the change is causing the jobs to be cancelled before even starting.

@paulb777: hello.
This looks strange, I tested this configuration in my repository, and it's working fine: https://github.com/a-25/firebase-ios-sdk/runs/4520127644?check_suite_focus=true
Reverted buildcache-action to previous stable version - let's see if it helps.
The other option that I see - I can update version to current master commit and test. It is risky because it was not released so far but there would be the newest action version.

Hi @a-25. Thanks for continuing to work through this.

It looks like the build is fixed now. I compared a few times and seeing the jobs in this PR slower than usual. Is that because this is the first run to seed the cache - and the next run will be faster?

@paulb777: I think yes.

I compared two jobs:
Without cache - https://github.com/firebase/firebase-ios-sdk/runs/4516567370?check_suite_focus=true
With cache - https://github.com/firebase/firebase-ios-sdk/runs/4521400838?check_suite_focus=true
Slowing is about 15% as I see. And the last job had almost no cache hits.

Maybe you could replay the last job to compare the results for the second time? Or you can merge this PR and see if it helps on the longer prospective. If not - it will be easy to revert it, I guess, because there are just additions, not code changes.

@a-25 Good point about merging and giving it a try for a few days and reverting if we don't see a real improvement. Let's get one more approval and then we can merge.

Thanks for the contribution @a-25! We'll merge this now and keep and eye on our CI times.

Hey @a-25 I'm working on Google Open Source Peer Bonus nominations and would like to recognize your contributions on this PR and others. I couldn't find a name or email address for you, so if you're interested, please email them to paulbeusterien at google.com and I'll make the nomination.