chore: Scope cirrus caches by branch, with fallback to main#24372
chore: Scope cirrus caches by branch, with fallback to main#24372
main#24372Conversation
efe1848 to
f4b10f3
Compare
| MM_INFURA_PROJECT_ID: ${{ secrets.MM_INFURA_PROJECT_ID }} | ||
|
|
||
| # Cache build artifacts with the pre-build fingerprint | ||
| - name: Cache build artifacts |
There was a problem hiding this comment.
This step was redundant because the cache is already getting updated by the cirruslabs/cache step above, which has an identical path and key.
cirruslabs/cache restores when it's first run, than saves at the end of the workflow automatically.
13f46f2 to
0a91a1f
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates GitHub Actions workflows to implement branch-scoped caching with a fallback to main, addressing potential cache corruption issues from the cirruslabs/cache action's global cache behavior.
Changes:
- Modified cache keys to include
github.ref_namefor branch-specific scoping - Added separate restore steps for
mainbranch fallback usingcirruslabs/cache/restore - Updated build and repack conditions to check both branch and main cache hits
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| .github/workflows/build-ios-e2e.yml | Implements branch-scoped caching for Xcode derived data and iOS app builds with main fallback |
| .github/workflows/build-android-e2e.yml | Implements branch-scoped caching for APKs and Gradle dependencies with main fallback |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Qbandev
left a comment
There was a problem hiding this comment.
LTGM! The Copilot naming comments seem valid.
0b6db00 to
890381f
Compare
890381f to
3b15dfc
Compare
The `cirruslabs/cache` action we use is identical to `actions/cache` in most ways, except that it is not scoped by branch. `actions/cache` is scoped by branch with a fallback to `main`, but `cirruslabs/cache` uses "global" caches (by repository). This means that the cache can get corrupted on a branch by accident fairly easily, e.g. if the data being cached is changed in a way not reflected by the cache key. I believe this has led to cache corruption in the past (we had a few incidents where we never found the cause, but where this is a plausible explanation). Our workflows have been updated to make our usage of `cirruslabs/cache` work like `actions/cache` does. It scopes caches by branch, first attmepting to restore from the branch cache. If there is no hit, it tries to restore from the `main` cache but doesn't update it at the end of the workflow in the fallback case. This ensures that any "cache corruption" is limited in scope just to a single branch, unless it gets merged to `main`. At least if it's merged to `main` we'll have an easier time finding and understanding the problem.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
3b15dfc to
15e3beb
Compare
🔍 Smart E2E Test Selection⏭️ Smart E2E selection skipped - skip-smart-e2e-selection label found All E2E tests pre-selected. |
|
|
Curious question, if cirrus cache now is pretty the same as action cache, what is the advantage to use cirrus cache? |
Description
The
cirruslabs/cacheaction we use is identical toactions/cachein most ways, except that it is not scoped by branch.actions/cacheis scoped by branch with a fallback tomain, butcirruslabs/cacheuses "global" caches (by repository).This means that the cache can get corrupted on a branch by accident fairly easily, e.g. if the data being cached is changed in a way not reflected by the cache key.
I believe this has led to cache corruption in the past (we had a few incidents where we never found the cause, but where this is a plausible explanation).
Our workflows have been updated to make our usage of
cirruslabs/cachework likeactions/cachedoes. It scopes caches by branch, first attempting to restore from the branch cache. If there is no hit, it tries to restore from themaincache but doesn't update it at the end of the workflow in the fallback case.This ensures that any "cache corruption" is limited in scope just to a single branch, unless it gets merged to
main. At least if it's merged tomainwe'll have an easier time finding and understanding the problem.Changelog
CHANGELOG entry: null
Related issues
N/A
Manual testing steps
N/A
Screenshots/Recordings
N/A
Pre-merge author checklist
Pre-merge reviewer checklist
Note
Aligns cirrus cache behavior with actions/cache to reduce cross-branch cache contamination and speed CI.
github.ref_namemaincaches (read-only) when branch cache miss occursWritten by Cursor Bugbot for commit 15e3beb. This will update automatically on new commits. Configure here.