Please Cache docker images via Github Action

[ZackDeRose]

Feature request

Is your feature request related to a problem? Please describe.

The request is to cache docker images, as this tends to be the bottleneck in CI times, as CI machines will always need to pull down the images from docker, even if they've been used in prior runs. Using the github cache action seems like it would be able to avoid this, but it's unclear to most users how to set this up for docker images, so it'd be nice to have a pre-built solution from supabase for this.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

[Idicious]

I second this request, the vast majority of the job is taken up by pulling the docker images currently (3 minutes of a 4 minute total job). If this could be cached based on the cli version that would be fantastic.

[sweatybridge]

I've done some testing with caching docker images. The fastest way seems to be using GHCR image mirror.

• supabase start took 2m45s
• supabase db start took 1m06s

If you need other containers for integration tests, like gotrue or postgREST, I'd suggest using the exclude flag to avoid starting containers unnecessarily. For eg. supabase start -x migra,studio would start without downloading migra and studio.

The alternative I considered is to save the images after first pull using @actions/cache. Subsequent job runs then load from actions/cache instead of remote docker registry. Unfortunately this does not lead to faster start time.

• Saving postgres image to actions cache took 2m55s
• Loading postgres image from actions cache took 2m25s

I used docker-cache action for the tests above.

The latest setup-cli action v1 or v1.1.3 sets the default registry to ghcr.io, so these optimisations should already be available to your GHA runners. If anyone has other ideas for speeding up docker image pulls, please feel free to comment.

[riderx]

Another option is to slimmer down the current image. The current image could be slimmer, at least for CI env.

[Mr-Pepe]

Unfortunately this does not lead to faster start time.

That doesn't match my experience with docker-cache. It reduced the time to run supabase start from ~1:40 minutes to ~0:40 minutes for me.

[sweatybridge]

@Mr-Pepe would you like to share your GitHub action / docker cache config so that the rest of users may benefit?

[Mr-Pepe]

I just followed the instructions from the docker-cache docs:

# test.yml

- name: Install Supabase CLI
  uses: supabase/setup-cli@v1
  with:
    version: 1.172.2

- name: Cache Docker images
  uses: ScribeMD/docker-cache@0.5.0
  with:
    key: docker-${{ runner.os }}-${{ hashFiles('.github/workflows/test.yml') }}

- run: supabase start -x=storage-api,imgproxy,inbucket,edge-runtime,logflare,vector

I set the cache key based on the workflow file because that changes when I change the Supabase version.

Before, 1m 33s:

After, 44s:

[sweatybridge]

Could you show the time it took for the entire workflow instead of the just supabase start step? It won't make much difference overall if images are simply downloaded in a previous step.

Also, try doing this on a new git branch every time. Git pushes to an existing branch will be significantly faster regardless of whether you use docker-cache because the images have already been downloaded to the github action runner.

[Mr-Pepe]

Good point. I might have to take everything back and claim the opposite 🥲

The Docker cache action restores the cache in an earlier step. Downloading the cached images is fast, but it then calls docker load --input ~/.docker-images.tar which takes over 1 minute, thus actually increasing the overall runtime of the workflow :\

Here is a related issue: https://github.com/ScribeMD/docker-cache/issues/785

It seems there is no quick win. Are there other options, like what @riderx suggested, reducing the image size? The action currently requires downloading 1065MB of image for my invocation.

I also noticed that although I exclude some components with supabase start -x=storage-api,imgproxy,inbucket,edge-runtime,logflare,vector, some related containers still get downloaded:

ghcr.io/supabase/edge-runtime:v1.53.3 ghcr.io/supabase/gotrue:v2.151.0 ghcr.io/supabase/studio:20240422-5cf8f30 ghcr.io/supabase/realtime:v2.28.32 ghcr.io/supabase/storage-api:v1.0.6 ghcr.io/supabase/postgres:15.1.1.41 ghcr.io/supabase/postgres-meta:v0.80.0 ghcr.io/supabase/postgrest:v12.0.1 ghcr.io/supabase/kong:2.8.1

I don't know which of these are the biggest ones, but maybe there are savings there?