e3a1a9dccf
My experience recently playing around with our locking behaviour is that, while mostly seamless and not seen by users, it's leaks implementation details a bit too heavily. As a result, the following improvements are in this commit: - Ensure that, whenever possible, we tell the user the actual command that is holding a given lock instead of the lock name (an internal implementation detail) - Make the locking error output a little more consistent and user friendly - Add a `DownloadLock` class to simplify locking downloads - Add a `HOMEBREW_LOCK_CONTEXT` variable to allow adding additional context for logging error messages - Lock paths and leave deciding how this translates to lock names up to the locking code itself - Lock the Cellar/Caskroom paths explicitly rather than implicitly Co-authored-by: Carlo Cabrera <30379873+carlocab@users.noreply.github.com>
37 lines
848 B
Ruby
37 lines
848 B
Ruby
# frozen_string_literal: true
|
|
|
|
require "lock_file"
|
|
|
|
RSpec.describe LockFile do
|
|
subject(:lock_file) { described_class.new(:lock, Pathname("foo")) }
|
|
|
|
describe "#lock" do
|
|
it "does not raise an error when already locked" do
|
|
lock_file.lock
|
|
|
|
expect { lock_file.lock }.not_to raise_error
|
|
end
|
|
|
|
it "raises an error if a lock already exists" do
|
|
lock_file.lock
|
|
|
|
expect do
|
|
described_class.new(:lock, Pathname("foo")).lock
|
|
end.to raise_error(OperationInProgressError)
|
|
end
|
|
end
|
|
|
|
describe "#unlock" do
|
|
it "does not raise an error when already unlocked" do
|
|
expect { lock_file.unlock }.not_to raise_error
|
|
end
|
|
|
|
it "unlocks when locked" do
|
|
lock_file.lock
|
|
lock_file.unlock
|
|
|
|
expect { described_class.new(:lock, Pathname("foo")).lock }.not_to raise_error
|
|
end
|
|
end
|
|
end
|