avallete
commented
1 month ago Hi there, thanks for your feedback.
- It would be great if we could cache the images between CI runs with the cache action. However, that doesn’t help too much since the cache is scoped to a specific branch, so any new branch will still need to pull all the images.
Based on GitHub workflow runs and cache documentation, this could actually be the right approach, as long as your CLI version is the same between main and your PR branch:
Access restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. Workflow runs can restore caches created in either the current branch or the default branch (usually
main).
So, an action that would run start on main and cache the pulled Docker image would allow all subsequent PRs to reuse those cached images.
I tried this approach on a repo to see if it would really improve CI times, but unfortunately, it seems like a dead end. The "caching and restoring" of Docker images took as long as simply pulling them over:
Here, with cache, the total time is 2m24s:
Without cache 2m11s:
We could potentially add some logic to skip pulling images if services aren't being run, but sadly, that will likely result in only a very marginal performance improvement.
kwypchlo
Is your feature request related to a problem? Please describe. Starting containers with
supabase starttakes around 2-3 minutes on Github Actions CI.Describe the solution you'd like
supabase start, can we first pull all docker images in parallel before starting any service--exclude ...Describe alternatives you've considered
Additional context Github Actions CI spins up clean environment on every run so any docker images downloaded on different runs or workflows cannot be accessed and will be discarded after the job is completed.
Related Github CI workflow