Skip to content

Cache the emulator system image (measuring whether it is worth it) - #25

Merged
jpcottin merged 2 commits into
mainfrom
ci/cache-system-image
Jul 26, 2026
Merged

Cache the emulator system image (measuring whether it is worth it)#25
jpcottin merged 2 commits into
mainfrom
ci/cache-system-image

Conversation

@jpcottin

Copy link
Copy Markdown
Owner

Adds actions/cache for the ps16k system image in the preview-emulator composite action, plus timing instrumentation so the cold/warm numbers come from a real runner instead of an estimate.

The preview emulator package is deliberately not cached — it moves often, and pinning a stale build would defeat the purpose of these jobs. sdkmanager still runs after a cache hit, so a newer image revision is still picked up.

Measurement plan: this first run is a cold cache (miss + save); a re-run then hits it. Comparing the SYSIMG-INSTALL seconds= lines gives the real saving, to weigh against the ~2 GiB the entry occupies of the repo's 10 GB cache budget — which is shared with the Gradle caches every job uses.

I'll report both numbers here before proposing we keep or drop it.

jpcottin added 2 commits July 26, 2026 15:42
The ps16k system image is the one large download in the preview jobs
(system.img is ~4.1 GiB, ~2 GiB compressed at the zstd level actions/cache
uses). Restore it from cache when possible.

The preview emulator package is deliberately not cached: it moves often and
pinning a stale build would defeat the purpose of these jobs. sdkmanager
still runs after a cache hit, so a newer image revision is still picked up.

Whether this is actually worth its share of the repo cache budget is an open
question, so the install step now logs SYSIMG-CACHE / SYSIMG-INSTALL /
SYSIMG-SIZE lines. The cold-cache and warm-cache numbers can then be read
off the job log directly.
actions/cache never re-saves on an exact key hit, so the fixed key froze the
cached image at whatever revision was current when it was first saved. Once
Google published a new ps16k revision, sdkmanager would fetch the delta on
every run and the cache would never catch up -- turning the saving into a
small permanent loss while CI quietly tested a stale image.

Put the ISO week in the key and keep the old key as a restore-keys prefix, so
a rotation restores the previous copy and sdkmanager fetches only the delta
instead of paying for a full 4.4 GB download.

Measured on the runner: the install step goes from 52s/39s cold to 3s/3s
warm, and the whole setup step from 82s/69s to 66s/50s -- restoring and
decompressing the image costs back about 33s of the download saved, so the
net is roughly 16-19s per job. The entry is 2.07 GB against a 10 GB repo
budget currently holding 2.73 GB total, so there is room for it.
@jpcottin
jpcottin merged commit b0ddbd2 into main Jul 26, 2026
13 checks passed
@jpcottin
jpcottin deleted the ci/cache-system-image branch July 26, 2026 23:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant