Better handling of docker cache on CI

[clemsos]

Currently we tarball the docker cache and save it to disk after each run to prevent re-downloading all deps (yarn on monorepo can take up to 20min).

This is not ideal and could be improved, as there are there better docker caching strategies out there, for instance : https://gist.github.com/UrsaDK/f90c9632997a70cfe2a6df2797731ac8

[clemsos]

docker caching has been deactivated for now on gh actions

@julien51 said

It looks like we have more docker issues on Github. Looking at the job I see we restore and save to docker a lot. But I wonder if we can only backup docker once, instead of in every single test in the matrix. Also we should probably only backup the docker setup once something is merged in the master branch successfully?

And also it looks like we treat the docker cache to be "distinct" for each subfolder in the monorepo but iirc they are actually all identical, aren't they? So, here is my thinking: 1/ We should have a unique docker cache (since everything is built from the same images anyway) 2/ We should load the unique docker cache on every action 3/ we should only overwrite the docker cache on the master branch when it has successfully built all tests

Ok in the interest of resuming builds I just removed all caching... which is going to make things slow but should not block - https://github.com/unlock-protocol/unlock/commit/d2958415c07cc6ca6fc15b170dfa8f6a41cf691c

[clemsos]

Turns out disabling docker cache worklfow made tests much faster 😓

without caching

run-all-tests / Unit Tests smart-contracts succeeded in 22m 15s https://github.com/unlock-protocol/unlock/runs/5401103381?check_suite_focus=true

with caching

run-all-tests / Unit Tests smart-contracts succeeded in 31m 1s https://github.com/unlock-protocol/unlock/runs/5396299840?check_suite_focus=true

[clemsos]

To add some context here, the main use of docker cache is to speed up the yarn install which can be very slow locally as it will install deps for the entire repo - fetching all deps from package host esp takes time.

Turns out Github is caching npm fairly well.

The yarn install step takes 393.7s on fresh install without docker cache, while it takes 143.9s using docker cache. So the whole docker cache backup logic needs to take less than (393-143)/60 = 4.2 min to outweight the pros of just keeping running gh actions without caching docker. Before it was taking up to 10min to tarball / extract it which explain why its actually faster without

[clemsos]

maybe can try that one

export DOCKER_BUILDKIT=1

# Build and cache image
$ docker build --tag mjhea0/docker-ci-cache:latest --build-arg BUILDKIT_INLINE_CACHE=1 .

# Build image from remote cache
$ docker build --cache-from mjhea0/docker-ci-cache:latest .

https://testdriven.io/blog/faster-ci-builds-with-docker-cache/

[julien51]

Yes! Since we use docker-compose though we will have to see if we can use that?

[clemsos]

It also works with compose, even support overrides for config (which we need).