-
Notifications
You must be signed in to change notification settings - Fork 1.2k
[cli,lock] Allow wait_for_lock #10784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
for more information, see https://pre-commit.ci
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #10784 +/- ##
==========================================
+ Coverage 90.68% 91.08% +0.40%
==========================================
Files 504 504
Lines 39795 40227 +432
Branches 3141 3179 +38
==========================================
+ Hits 36087 36640 +553
+ Misses 3042 2958 -84
+ Partials 666 629 -37 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
- unify lock in dvc/lock.py - improve dvc/cli/command.py - timeout takes precedence in HardlinkLock
for more information, see https://pre-commit.ci
Thank you for contributing. Just so you are aware, there are two kinds of lock in dvc: 1) Although this adds wait for the first kind of lock, you may still run into |
Many thanks, cheers! I'll need to see if this influences my use-cases when running bazel |
If we are running multiple instances of DVC in parallel in the same repo, commands can crash because they can't acquire a lock.
This is reasonable in most use-cases, but I've been using DVC in my bazel pipelines, which runs jobs in parallel. Therefore, I've added a
--wait-for-lock
flag that allows a process to be more patient.Note this is my first PR, so I may not be following all the conventions of the project. Feedback appreciated!
Fixes #2520