Skip to content

Conversation

@asbjornu
Copy link
Member

@asbjornu asbjornu commented Sep 23, 2020

A rebase and dotnet format fixed version of #2333. Hopefully the tests turn green so we can make this available in a beta for testing.

Resolves #2333. Hopefully fixes #1031. Hopefully fixes #1381.

teneko and others added 14 commits September 23, 2020 00:54
…an produce FileLockUses; FileLock wraps FileLockUse and implements IDisposable for being cleaned when disposing ServiceProvider
…executed action in assembly GitVersion.MSBuildTask
Remove because of false impression

Co-authored-by: Asbjørn Ulsberg <[email protected]>
Remove because of false impresssion

Co-authored-by: Asbjørn Ulsberg <[email protected]>
Remove due to implicit copyright

Co-authored-by: Asbjørn Ulsberg <[email protected]>
Remove because of false impression

Co-authored-by: Asbjørn Ulsberg <[email protected]>
@boexler
Copy link

boexler commented Oct 14, 2020

push 🎉

return fileStream;
}

private bool waitUntilAcquired(string filePath, out FileStream? fileStream, FileMode fileMode,
Copy link
Member

Choose a reason for hiding this comment

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

I guess in the code base we use the convention that all methods should follow Pascal Case. Can you adjust the method names to conform our conventions?

Copy link
Contributor

@dazinator dazinator left a comment

Choose a reason for hiding this comment

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

Lot of work here!
My only suggestion would be to consider making he locking abstraction more general purpose, and have the "file based" locking be one implementation:

ILocker locker = new FileLocker(); // we can switch implementations
using(var lock = locker.Aquire());
{

// do stuff here

}
The reason for that is that we might want to switch to other sorts of locking if we encounter issues with file based locking. For example, on .net core we may want to try a global (named) mutex implementation: https://docs.microsoft.com/en-us/dotnet/standard/threading/mutexes#local-and-system-mutexes

Other than that, I couldn't see any tests specifically for the file locker - I assume we are relying on higher level integration tests to verify that it works?

@arturcic
Copy link
Member

@asbjornu looks like the Locking interfaces are not used in our code base.
I guess this one should be made a draft PR as it's not finished?

@arturcic arturcic marked this pull request as draft October 22, 2020 08:37
@asbjornu
Copy link
Member Author

@asbjornu looks like the Locking interfaces are not used in our code base.

Good find! I haven't studied the code enough to discover that yet.

I guess this one should be made a draft PR as it's not finished?

Yes, indeed.

@riksking
Copy link

Hi, All.

Can you publish beta version with this fix.
I'm ready to test it.

@arturcic
Copy link
Member

@riksking this is still a draft, the code implementation is not finished

@dieterv
Copy link
Contributor

dieterv commented Jan 12, 2021

@asbjornu starting from your asbjornu:feature/lockfile branch, I rebased and applied the following changes:

I've been using GitVersion.MsBuild and GitVersion.CommandLine nuget packages with these two changes since yesterday for our CI builds on our private GitLab instance in addition to enabling parallel builds (msbuild /m parameter). I can confirm I haven't seen any error : LockedFileException: the index is locked; this might be due to a concurrent or crashed process message since doing so 😁 🎉

Base automatically changed from master to main January 31, 2021 12:46
@asbjornu
Copy link
Member Author

asbjornu commented Feb 8, 2021

#2581 should fix this in a satisfactory manner. If anyone wants to pick this up, please fork, complete the implementation and submit a new pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

7 participants