-
-
Notifications
You must be signed in to change notification settings - Fork 71
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
Weird race condition with targets #321
Comments
See https://github.com/gitfool/GitInfo.Dungeon for a repro. I injected some sleeps after It doesn't want to repro within 10 test builds on github but it always fails within 10 runs on my local machine:
|
I tweaked the sleeps and after a few runs via MSBuild Log Viewer I captured the following binlog: GitInfo.Dungeon.binlog.zip |
Describe the Bug
I'm hitting a weird race condition with the
GitInfo
target due to incremental buildInputs
andOutputs
short-circuiting targets causing their returned properties to sometimes be empty.Specifically, I'm trying to add a custom target that runs after the
GitInfo
target to use its properties to derive a base version using theGitCommitDate
; however sometimes this property is empty due to being skipped based on incremental buildInputs
andOutputs
properties.I've been investigating this weirdness with MSBuild Log Viewer and other properties associated with the
GitInfo
target are also randomly affected.Steps to Reproduce
Add the following files to the root directory next to the solution file:
Directory.Build.props
:Version.targets
:In my scenario I have a solution with only 4 projects but they all want to generate the same version - which highlights another issue that the git info cache default directory should probably be common to all projects; either in the
.git
directory (preferred) like GitVersion or next to the solution file. Is there any reason this is not the default?Anyway, if I repeatedly rebuild the solution it eventually fails, usually within the first 10 attempts, with the following:
Expected Behavior
Always succeed rather than randomly fail.
Version Info
3.3.3
Additional Info
MSBuild Log Viewer screenshot (redacted):
Shows that after the
GitInfo
target was run, several of its properties, includingGitCommitDate
where I expand its target_GitCommitDate
, were not populated due to the incremental build skipping them:Looking around this repo's source it seems to me that the targets that populate the
GitInfo
properties do not need to leverage the incremental build properties (Inputs
andOutputs
) since they are also short circuited by their conditions when the cache is hit and the values can be read from the previous build.Am I doing something wrong or missing something?
PS. I'm happy to submit a pull request if we can understand the issue and decide how best to fix it. Along the same lines, would you accept a pull request to add this "git commit date" based versioning strategy once I get it working robustly? 🙏
The text was updated successfully, but these errors were encountered: