Try out caching in CI
Opened this issue · 3 comments
...now that setup-ocaml v2 supports it.
Using setup-ocaml@v2 has sped up the build by about 50% — it looks like it caches the compiler. The greater potential speedup would be from also caching the opam deps, which AFAICT is not done. I opened ocaml/setup-ocaml#159 about that.
As of right now, the build is still several times slower than it would be in Travis (but Travis has become too weird with its migrations, etc.)
This will be difficult with GHA built-in caching. I just ran a build that shows the gzipped sizes of the directories that it is most important to cache for build speed. The six opam jobs would have .5 GB caches. The two esy jobs would have 1.3 GB caches. This already adds up to 5.6 GB, more than GHA's 5 GB per-repository limit. The overall size would grow with time, as we would want to gradually add more jobs.
Possible solutions:
- Cache only some jobs, for a fast answer from the most important builds.
- Use S3. This has the major drawback that S3 donwloads cost about $0.10 after the first GB. For 5.6 GB of caches per build, that will cost about $0.45 per build. Dream is currently doing about 100 builds per month, so $45 per month, in addition to the about $60 per month currently used for building and hosting deployment examples.
- Switch to Travis, which has a much nicer caching setup, assuming it is intact on travis-ci.com (as opposed to travis-ci.org, which I have experience with).
I want to point out that backblaze b2 + cloudflare offer free egress https://www.backblaze.com/blog/backblaze-and-cloudflare-partner-to-provide-free-data-transfer/
This action needs to be adopted https://github.com/papix/action-cache-s3 to support custom s3 endpoint.