Key the system-image cache on the image revision - #26
Merged
Conversation
Weekly rotation bounded how long a stale entry could linger, but it still left a window: within a week the exact key already exists, actions/cache does not re-save on a hit, so a newly published image revision would be re-downloaded by sdkmanager on every run until the week rolled over. Split restore and save so the entry can be keyed on the revision that actually ended up on disk, which is only knowable after sdkmanager has run. Restore takes whatever copy exists via the key prefix, sdkmanager brings it up to date, and save writes it back under rev<N> -- guarded so it only writes when the restored entry was not already that revision. A new revision therefore enters the cache on the first run that sees it, and a steady state costs nothing. Correctness was never at risk either way: sdkmanager always installs the newest revision, so CI has never tested a stale image. This is purely about not paying for the same download repeatedly.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Replaces the weekly rotation from #25 with revision-based keying.
Why: weekly rotation bounded staleness but left a window. Within a week the exact key already exists,
actions/cachedoes not re-save on a hit, so a newly published image revision would be re-downloaded bysdkmanageron every run until the week rolled over. That is exactly the scenario you raised — a new image appearing tomorrow.How: split
restoreandsaveso the entry can be keyed on the revision that actually ended up on disk, which is only knowable aftersdkmanagerhas run.A new revision enters the cache on the first run that sees it; a steady state writes nothing.
Correctness was never at risk either way —
sdkmanageralways installs the newest revision, so CI has never tested a stale image. This is purely about not paying for the same download repeatedly.Current revision is 6, so the first run should restore via the prefix (matching an existing entry, no 4.4 GB download) and save
sysimg-v1-android-37.0-google_apis_ps16k-x86_64-rev6. Watch forSYSIMG-CACHE restored-from=andSYSIMG-REVISIONin the job log.