CI: experiment state cache for incremental build

[cometkim]

The compiler build takes up half of the entire CI workflow, and build speed is a huge bottleneck, especially on the Windows runner.

Idea

OCaml has a great incremental build experience. There's no reason why CI can't leverage this too.

In real tests, actions with a _build directory cache can be completely omitted if there are no changes. Even if there are some changes, the load is greatly reduced because only minimal work is done along the dependency tree.

The build state almost always changes. Therefore, it is important to update it infrequently to find a reasonable hit rate.

We can optionally perform cache writes only on master push events. We can even create a "warming job" that updates the shared cache entry once every day or two.

[cometkim]

Well, there is less boosting than I expected. I may have missed a critical path that stores shared cache..

[cometkim]

Only 15~20% faster with no changes, not so incremental

[cknitt]

Only 15~20% faster with no changes, not so incremental

Question is if it is worth it then?

Also, does it not depend on our opam cache, too? If the opam cache cannot be restored, it could be that we get a newer version of dune and so things might break?

[cometkim]

Question is if it is worth it then?

before

after

It is 30s~50s on Windows runner so I guess so? It's a pretty nice one that was made in a few steps without much complexity.

Each cache entry is around 100 MiB, so, no storage pressure.

[cknitt]

Yes, it's still a noticeable speedup 👍, I meant "worth it" in terms of CI build issues it might cause.

[cometkim]

Yes, it's still a noticeable speedup 👍, I meant "worth it" in terms of CI build issues it might cause.

Let's see, this should be easy to revert anyway.

I'll make it cache based on the master merge.

[cknitt]

Ok, let's go ahead then!