Skip to content

Conversation

Khady
Copy link
Contributor

@Khady Khady commented Aug 26, 2025

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

Signed-off-by: Louis Roché (Ahrefs) <[email protected]>
@Khady Khady force-pushed the louis/test-cache-disabled branch from 1818c94 to e4ed9b0 Compare August 26, 2025 03:19
Initial build, populating cache

$ dune build --config-file config
$ wc -l _build/log
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


$ dune build --cache=disabled --config-file config
$ wc -l _build/log
22 _build/log
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


$ dune build --cache=disabled --config-file config
$ wc -l _build/log
17 _build/log
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

$ dune clean --config-file config
$ dune build --config-file config
$ wc -l _build/log
22 _build/log
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shared cache is warm but more stuff is built?

$ dune clean --config-file config
$ dune build --config-file config
$ wc -l _build/log
22 _build/log
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@rgrinberg
Copy link
Member

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
Copy link
Contributor Author

Khady commented Aug 26, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants