You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
GitVersion is taking between 5-15 minutes to run. Which equated to about 60-85% of our build time on our Build Server (TFS2018).
Detailed Description
We noticed GitVersion is taking a very long time during our builds, and has been getting slower overtime.
We have a semi-mono repo with about ~20-30 people working on it. Not really huge like some companies I'm sure. But GitVersion has been taking longer and longer due to the number of branches (We have been bashing people for last 2 years to delete feature branches, but so far its a losing battle) and a large amount of commits/merges (Git Flow without single develop).
Turning normalize off [nonormalize flag] causes GitVersion to error saying it can't find the correct version, this seems to be because it is running in a "git detached HEAD" mode on the server (TFS way of working, at least on our TFS version!).
The fix I have currently implemented in our custom version of GitVersion is to use the same logic in GitVersionContextFactory for resolving the target branch based on the build agent branch if it is available.
These changes have increased performance by decreasing the time down to 5 seconds which is acceptable.
I am happy to do the work including tests, but want to find out if this is something you would consider merging.
Possible Implementation
GitVersionContextFactory resolves targetBranch using the same logic as GitPreparer.ResolveCurrentBranch which takes into account BuildAgent.GetCurrentBranch() if running on a build agent.
See my custom version commit for an example. By no means merge ready as there is a hack for late binding GitVersionOptions, some code copied that probably should live in its own class (ResolveCurrentBranch) and no tests. Ignore the azurepipelines-setparamskipisoutput switch as I have created a separate issue #2426 and branch with a test.
This could be the logic to use if
Running on BuildAgent
and maybe If only in detached HEAD mode?
An option switch is set (e.g. UseBuildAgentBranch)
The text was updated successfully, but these errors were encountered:
This is definitely interesting, as GitVersion uses ~5 minutes on our build server as well. So, it is really the detached head thing that is causing it, @michal-ciechan ? I have been wondering about this
In our case it was yes. When I run locally checking out a branch it works fast (seconds). When I checkout using commit ID, it was running for 5-6 min. Trying to crawl through a large number of check-ins/branches/merges etc.
This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.
GitVersion is taking between 5-15 minutes to run. Which equated to about 60-85% of our build time on our Build Server (TFS2018).
Detailed Description
We noticed GitVersion is taking a very long time during our builds, and has been getting slower overtime.
We have a semi-mono repo with about ~20-30 people working on it. Not really huge like some companies I'm sure. But GitVersion has been taking longer and longer due to the number of branches (We have been bashing people for last 2 years to delete feature branches, but so far its a losing battle) and a large amount of commits/merges (Git Flow without single develop).
Turning normalize off [
nonormalize
flag] causes GitVersion to error saying it can't find the correct version, this seems to be because it is running in a "git detached HEAD" mode on the server (TFS way of working, at least on our TFS version!).The fix I have currently implemented in our custom version of GitVersion is to use the same logic in
GitVersionContextFactory
for resolving the target branch based on the build agent branch if it is available.These changes have increased performance by decreasing the time down to 5 seconds which is acceptable.
I am happy to do the work including tests, but want to find out if this is something you would consider merging.
Possible Implementation
GitVersionContextFactory
resolvestargetBranch
using the same logic asGitPreparer.ResolveCurrentBranch
which takes into accountBuildAgent.GetCurrentBranch()
if running on a build agent.See my custom version commit for an example. By no means merge ready as there is a hack for late binding
GitVersionOptions
, some code copied that probably should live in its own class (ResolveCurrentBranch
) and no tests. Ignore theazurepipelines-setparamskipisoutput
switch as I have created a separate issue #2426 and branch with a test.This could be the logic to use if
The text was updated successfully, but these errors were encountered: