repro: Disable run-cache if --no-commit.

[daavoo]

No description provided.

[daavoo]

@dberenbaum In the issue there was also a point about dvc repro -f should disable restoring the run or outputs. but I found this is already working as expected (unless I misunderstand the point)

[codecov]

Codecov Report

Base: 93.54% // Head: 93.55% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (a1729ac) compared to base (0e5674f).
Patch coverage: 100.00% of modified lines in pull request are covered.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #8718   +/-   ##
=======================================
  Coverage   93.54%   93.55%           
=======================================
  Files         457      457           
  Lines       36236    36237    +1     
  Branches     5259     5260    +1     
=======================================
+ Hits        33896    33900    +4     
+ Misses       1835     1832    -3     
  Partials      505      505           

Impacted Files	Coverage Δ
dvc/stage/__init__.py	93.99% <100.00%> (+0.01%)	⬆️
tests/func/test_data_cloud.py	99.41% <100.00%> (ø)
tests/func/test_repro.py	99.04% <100.00%> (ø)
tests/unit/repo/experiments/conftest.py	95.31% <0.00%> (+4.68%)	⬆️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[dberenbaum]

Thanks @daavoo! It's been a very long time since I looked into this issue, and I'm no longer sure about it, and I'm hesitant to put it in a minor version release.

Let's say I'm using experiments, and my training stage outputs both a model that's cached in dvc and metrics that aren't. With the recent name changes, we made it possible to have duplicate experiments, but it didn't seem so bad because duplicate stages would still be cached and skipped. With this PR, I will end up duplicating all the computation of this training stage.

It also makes dvc much more reliant on dvc.lock. Before this PR, It's possible to have a workflow where you treat dvc.lock as ephemeral and don't commit or share it. As long as you share the run-cache, it's still easy to recover everything. After this PR, there's no way to recover the outputs from a stage with cache: false outputs unless you have dvc.lock.

Should dvc be saving the git hash for objects that have cache: false instead of the dvc md5? In the typical case for cache: false where those files are being tracked by git, it seems like it's still useful to have the run-cache but there's no need to add those files to the dvc cache since they can be found in git objects.

What do you think?

[daavoo]

What do you think?

I think there are a lot of things to discuss there 😅

WDYT about the first commit/part of the P.R. (repro: Disable run-cache if --no-commit)?

I think we can start by discussing/merging that and continue discussing cache: false behavior separately.