test: showcase impact of cache disabled

[Khady]

Adding a test to show the different behaviors of dune build --cache=disabled depending on how the shared cache is setup.

[Khady]

I would have preferred to cat _build/log but some lines are starting with $ and it confuses the cram tests on subsequent runs.

[Khady]

given that _build is still populated from the previous build, why do we have more stuff being built?

[Khady]

here is it the same as during the second build, as expected

[Khady]

shared cache is warm but more stuff is built?

[Khady]

given that _build is still populated from the previous build, why do we have more stuff being built?

[rgrinberg]

Whether an action is decided to be re-executed depends on whether the cache is set. It is done this way so that running a build with the cache enabled will always populate the cache if possible (the cache is populated after the cache is re-ran).

So all of this is expected behavior. It might be suboptimal, but dune isn't really meant to be used with the cache toggled on and off. I think there's already a test for this behavior, do you mind checking the tests to confirm? I don't want to add more duplication to the test suite.

[Khady]

I think I don’t understand what “the cache is set” means then. Because to me as a user there’s no obvious reason for the things to happen this way, and especially to have different behavior with cache=disabled depending on the shared cache being on for user rules or not. In all cases _build already contains the final artifacts.

[rgrinberg]

Could you add a DCO please?

[Khady]

added dco