GitVersion slow, not sure if config is correct

[kyberias]

I have a repo where running Gitversion takes anywhere from 15-30 minutes. Because the log is filled with commit details (why?), I cannot post it here. I suspect Gitversion tries to do something it really shouldn't be doing.

For example if I run the GV in our develop branch, the log is filled with these:

INFO [11/22/17 9:44:41:51] Begin: Finding merge base between 'release/0.17.0' and 'foobar'
INFO [11/22/17 9:44:41:60] Begin: Finding merge base between 'release/0.17.0' and 'foobar2'.
INFO [11/22/17 9:55:48:18] End: Finding merge base between 'release/0.17.0' and 'origin/sttCR'. (Took: 114.30ms)

So it seems to be looking at "merge bases" between all the different branches and it takes a lot of time. Does it really have to do all this? We have lot of (feature) branches that are named quite randomly (with no feature prefix). Is GV slow because it's confused about those branches? Is there a way to configure it to ignore those?

The documentation refers to "source-branches" config but no released version seems to support that. Kinda annoying that the documentation is not in sync with the latest release.

[kyberias]

I'm running 4.0.0-beta0011.

My config is the default generated:

mode: ContinuousDeployment
branches:
  master:
    regex: master
    mode: ContinuousDelivery
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
  release:
    regex: releases?[/-]
    mode: ContinuousDelivery
    tag: beta
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: true
  pull-request:
    regex: (pull|pull\-requests|pr)[/-]
    mode: ContinuousDelivery
    tag: PullRequest
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    tag-number-pattern: '[/-](?<number>\d+)[-/]'
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
  hotfix:
    regex: hotfix(es)?[/-]
    mode: ContinuousDelivery
    tag: beta
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
  support:
    regex: support[/-]
    mode: ContinuousDelivery
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
  develop:
    regex: dev(elop)?(ment)?$
    mode: ContinuousDeployment
    tag: unstable
    increment: Minor
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: true
    is-release-branch: false
  feature:
    regex: .*
    mode: ContinuousDelivery
    tag: useBranchName
    increment: Inherit
    prevent-increment-of-merged-branch-version: false
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
ignore:
  sha: []

[normanhh3]

Just as an aside, we updated to the 4.0 Beta and that included this PR which seems to have addressed the issue for us.

#1100

[kyberias]

As I said earlier: "I'm running 4.0.0-beta0011."

[normanhh3]

@kyberias honestly, one of my team found that the PR listed previously was the critical one, I'm not sure if those changes were included in the version you are using. I just wanted to share what we found was working as lots of folks seemed to be reporting the issue, but no one seemed to have reported any solutions. My apologies if this doesn't resolve the issue for you. Someone else will likely need to respond to address your question.

[asbjornu]

@kyberias: If you only have the default config, please delete it and see if the behavior changes. Other than that, it's absolutely a problem that you don't have common prefixes for your branches. GitVersion uses the prefixes to figure out which type of branch it is. If you never delete merged branches, that might also affect the performance.

[kyberias]

@asbjornu, thanks for the advice. Where could I find more (hopefully precise) information about how to name the branches?

Our feature branches don't have a naming convention. May I ask again: Is there a way to configure it to ignore those [branches]? If they don't follow some naming convention, why is Gitversion looking at them? Why isn't the default behavior to ignore them?

I'm really struggling to understand how Gitversion works or is supposed to work with the documentation that is not in sync with the implementation.

BTW, my company might be willing to actually pay some bucks to Gitversion developers to sort this thing out. Let me know if some of you is interested.

[kyberias]

@asbjornu, I don't quite understand what it means to delete default config. If my config file is the same as what is generated by default, why would it change the behavior? Isn't that the purpose of a default config. It is default. :)

[asbjornu]

@kyberias: The configuration might change over time. Please delete it and see if GitVersion behaves the same. To understand which flows GitVersion supports, please see the example and read on from there. TL;DR: GitVersion supports Gitflow and GitHub Flow (aka. Mainline).

The default naming convention for branches in both of these flows are:

• Feature: feature/* or feature-*
• Support: support/* or support-*
• Hotfix: hotfix/* or hotfix-*
• Release: release/* or release-*
• Develop: develop
• Master: master

If you follow these naming conventions and one of the supported flows, GitVersion should behave well and as expected.

[kyberias]

Ok, we're using TFS with pull-requests. Typical workflow: developer fixes a bug, for example, and selects any random branch name (e.g. foobar). This gets pushed to remote and a PR created off of that branch. This results in many remote branches with weird names. A build is triggered off of that branch and even the PR gets nicely versioned by GitVersion, but it takes e.g. 15 minutes. Now, it's not super critical, but gets very annoying fast.

Based on this discussion, am I correct to assume that Gitversion seems to get confused about these branches? Is there a way to configure gitversion not to get confused and just ignore them? I fail to understand that if there is a naming convention, why can't it ignore the branches then?

It seems the branch configuration page in the documentation tries to tell me something and I'm sure it's easy for the Gitversion developers to understand it when you guys know the inner details of how it works, but for mere mortals it's impenetrable.

So is there a specific config setting that would stop Gitversion looking at no other than develop, release/*, hotfix, master branches?

(I think this is actually the third time I ask the same question) :)

[asbjornu]

I agree waiting 15 minutes for GitVersion to complete is bonkers. But I don't think you've answered this question: Do you delete merged branches?

If you do git branch -a, how many remotes/* do you get?

So is there a specific config setting that would stop Gitversion looking at no other than develop, release/*, hotfix, master branches?

No. You can ignore individual commits or commits before a given date, but not swaths of branches like that.

[kyberias]

Do we delete merged branches? Sometimes we do, sometimes we don't. TFS actually suggests deleting the branch when PR is completed, but that doesn't always happen. So yes, we have a lot of branches that have wild names.

I don't understand why GitVersion considers them though. Why would it care that sometimes there was a branch named "foobar", for example? It seems Gitversion's algorithm is not very efficient here.

[asbjornu]

I assume all of the branches take a long time to iterate over and that this is done a lot, since they can't be excluded with some prefix filter. I don't really know. Can you please provide a log file of a problematic build so we can at least pinpoint where in the code the latency is coming from?

[stale]

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.