Skip to content

[Improvement] Build Server detached HEAD optimization #2427

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

Closed
michal-ciechan opened this issue Oct 17, 2020 · 4 comments
Closed

[Improvement] Build Server detached HEAD optimization #2427

michal-ciechan opened this issue Oct 17, 2020 · 4 comments

Comments

@michal-ciechan
Copy link

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)
@erikbra
Copy link
Contributor

erikbra commented Dec 7, 2020

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

@michal-ciechan
Copy link
Author

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.

@asbjornu
Copy link
Member

asbjornu commented Dec 8, 2020

It is recommended to normalize the repository before running GitVersion. GitVersion's requirements are outlined in #2194.

@stale
Copy link

stale bot commented Mar 19, 2021

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.

@stale stale bot added the stale label Mar 19, 2021
@stale stale bot closed this as completed Jun 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants