#2578: Retry some file reads and writes to avoid 'file in use' on gitversion.json

[MarkusHorstmann]

Description

Retry some file reads and writes to avoid 'file in use' on gitversion.json. Up to 6 attempts will be made on any IO exception, with exponential back-off between retries. The contentious operations typically write and read the entire gitversion.json file and tend to be sub-second on typical systems.

Also retry LibGit2Sharp.LockedFileException failures on some GIT operations.

Related Issue

Closes #2578.
Mitigates #1031.

Motivation and Context

With multi-targeted projects and solutions with many projects, there is read/write contention on the gitversion.json files, resulting in intermittent failures. See linked issue for one repro.

How Has This Been Tested?

Used in local builds on our repos. Reproduced failures like this, and confirmed the fix eliminates them. https://github.com/TRUMPF-IoT/cdePlugins/pull/23/checks?check_run_id=1827871101.

Checklist:

• [x ] My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• [ x] All new and existing tests passed.

[arturcic]

@MarkusHorstmann we already have a class for retry mechanism, do you mind checking this one

GitVersion/src/GitVersion.Core/VersionCalculation/Cache/GitVersionCache.cs

Line 50 in 8937c25

var retryOperation = new OperationWithExponentialBackoff<IOException>(new ThreadSleep(), log, WriteCacheOperation, maxRetries: 6);

and update ?

[MarkusHorstmann]

@MarkusHorstmann we already have a class for retry mechanism, do you mind checking this one

GitVersion/src/GitVersion.Core/VersionCalculation/Cache/GitVersionCache.cs

Line 50 in 8937c25

var retryOperation = new OperationWithExponentialBackoff<IOException>(new ThreadSleep(), log, WriteCacheOperation, maxRetries: 6);

and update ?

Absolutely. Missed that helper.

2 questions (not familiar with the codebase so asking for guidance before I start):

1. There is no logger in the context of the operations to be retried. OK to extend the retry mechanism to allow for no logger? Try to plumb a logger through? Implement a null logger?
2. One of the operations returns a result. OK to add another retry helper with a Task return value?

[MarkusHorstmann]

Took a stab at the above. Hope this is not too impactful.

[arturcic]

Please rebase on top of main before continuing

[arturcic]

Looks good, do you think we can move the retry from the GitRepository and from the LibGit2Sharp implementation upper the stack to the consumer. That will make it more consistent.

[arturcic]

@MarkusHorstmann thank you so much for your contributions 👍

[jetersen]

Should this PR have closed #2410 or do we intend to introduce the file lock?