[Bug] Problem with `git flow` and Microsoft Azure Pipelines

[black-snake]

Hi there,
thanks for your great project -- it eases configuration management.

Describe the bug

I'm trying to use GitVersion on Microsoft Azure Pipelines together with git flow but I'm experiencing some difficulties that may be related to a bug or the problem is simply sitting in front of the monitor: hotfixes get the wrong version.

Expected Behavior

The build of the commit with tag 0.5.12 should produce version 0.5.12.

Actual Behavior

The build of the commit with tag 0.5.12 produces version 0.6.0-tags-0-5-12.1+13.

Possible Fix

What I found out is that when I am quickly enough with pushing the branches master and develop (including tags), the CI build of the (last commit of) hotfix/0.5.12 branch will produce a version 0.5.12. This, of course, is due to the fact that git flow tags the last commit of the hotfix branch and then merges into the branches master and develop.

However, when I'm slower with pushing the branches master and develop, the actual behavior is observed (see above).

IMHO, the stable version should not be built on the hotfix branch but on the master branch by the merge into it.

Steps to Reproduce

I use git flow to create a new hotfix by typing git flow hotfix start 0.5.12 and then commit and push on the hotfix branch. After finishing my changes I close the hotfix with git flow hotfix finish 0.5.12. Some minutes later, I push the branches master and develop to the remote (Microsoft Azure DevOps).

Context

I'm trying establish a hotfix release process with proper versioning.

Your Environment

• Version Used: 5.2.4
• Operating System and version: Ubuntu 18.04

GitVersion.yml

assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
branches: {}
ignore:
  sha: []
merge-message-formats: {}

azure-pipelines.yml

trigger:
  branches:
    include:
      - '*'
    exclude:
      - master
  tags:
    include:
      - '*'

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: pack_and_publish
  variables:
  - group: Release Configuration
  displayName: Packing and Publishing
  dependsOn: build_and_test
  steps:
    - task: UseGitVersion@5
      displayName: GitVersion
      inputs:
        versionSpec: '5.x'
    - task: DotNetCoreCLI@2
      displayName: dotnet restore
      inputs:
        command: 'restore'
        feedsToUse: 'select'
        verbosityRestore: 'Normal'
    - task: DotNetCoreCLI@2
      displayName: dotnet pack
      inputs:
        command: 'pack'
        packagesToPack: '**/*.csproj'
        includesymbols: true
        versioningScheme: 'byEnvVar'
        versionEnvVar: 'GitVersion_NuGetVersionV2'
        verbosityPack: 'Normal'
    - task: PublishBuildArtifacts@1
      displayName: publish build artifacts
      inputs:
        PathtoPublish: '$(Build.ArtifactStagingDirectory)'
        ArtifactName: 'packages'
        publishLocation: 'Container'

[asbjornu]

GitVersion don't support tools per se, it supports Git workflows. Sorry, but I have no idea what happens under the hood when you type git flow hotfix start 0.5.12 or git flow hotfix finish 0.5.12. Can you please show the commit log, or even better – submit a pull request containing a RepositoryFixture test that reproduces the commit log and the problem you experience?

[black-snake]

Hey,

thanks for your quick reply. I understand that you cannot support other tools and flows but git flow is particularly mentioned in your documentation and that is what I use.

Anyway, I now constructed a minimal example without using git flow.

The only thing I want GitVersion is to derive the correct version from a subsequently tagged commit, in this case 0.5.12.

steps to reproduce

1. tag a commit on master branch with 0.5.11
2. create branches develop and hotfix that point to the same commit on the master branch mentioned in (1)
3. push all branches to remote
4. checkout hotfix branch
5. make a commit on hotfix branch and push it
6. wait for Microsoft Azure Pipelines to build the commit of (5)
7. tag the commit on hotfix branch with 0.5.12
8. merge hotfix branch into master and develop branches
9. delete hotfix branch
10. push all branches with all tags

expected behavior
the subsequently tagged commit from hotfix branch (latest commit on that branch) is built again because of the tag trigger, resulting in version 0.5.12

actual behavior
the subsequently tagged commit from hotfix branch (latest commit on that branch) is built again because of the tag trigger, resulting in version 0.6.0-tags-0-5-12.1+1

output of git log --branches --remotes --tags --graph --decorate

* commit dda83e461033c657bd02e498c083bd2eca51e638 (HEAD -> develop, tag: 0.5.12, origin/master, origin/hotfix, origin/develop, origin/HEAD, master)
| Author: AUTHOR <>
| Date:   Fri Mar 27 15:02:39 2020 +0100
| 
|     added new-file
|   
*   commit 837a12818fd63a737b37f84f9567fde6147f3784 (tag: 0.5.11)
|\  Merge: 049d705 f5376a4
| | Author: AUTHOR <>
| | Date:   Fri Mar 27 08:17:39 2020 +0100
| | 
| |     Merge branch 'master' of https://dev.azure.com/AUTHOR/Demo/_git/Demo
| | 
| * commit f5376a4c28def6c899374a005c85ddcc3038b9a6
| | Author: AUTHOR <>
| | Date:   Fri Mar 27 08:15:21 2020 +0100
| | 
| |     initial files
| | 
* | commit 049d705a99dabb419dc79e42a0c9fbbdd8799341
|/  Author: AUTHOR <>
|   Date:   Fri Mar 27 08:15:21 2020 +0100
|   
|       initial files
| 
* commit f338e8ff204636d1c0f4cc762c78cdc17b4d8a36
  Author: AUTHOR <>
  Date:   Fri Mar 27 07:09:51 2020 +0000
  
      Added README.md

GitVersion.yml

assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
branches: {}
ignore:
  sha: []
merge-message-formats: {}

simple azure-pipelines.yml that only executes GitVersion

trigger:
  branches:
    include:
      - '*'
    exclude:
      - master
  tags:
    include:
      - '*'

pool:
  vmImage: 'ubuntu-latest'

jobs:
- job: GitVersion
  steps:
    - task: UseGitVersion@5
      displayName: GitVersion
      inputs:
        versionSpec: '5.x'

[asbjornu]

GitVersion supports git flow as described, not necessarily as implemented in various tools that have different interpretation of specific details. Point 7 here, is wrong, imho:

7. tag the commit on hotfix branch with 0.5.12

Tags should be on the master branch, and specifically on the merge-commits:

If you apply the tag to the correct branch, the resulting version number should also be correct.

[black-snake]

Hi,

I understand. I am also familiar with this figure and was wondering myself, why the official git flow (version 0.4.2 from the official Fedora repositories via sudo dnf install gitflow) is deviating from this – especially because the figure from this post seems to be from the git flow author or associated with him/her.

However, whether to tag the merge commit or not, is something others in the official git flow repository have also come across: nvie/gitflow#432
They explicitly wonder about a change in this regard.

So what to do with this?

[asbjornu]

Thanks for pointing out nvie/gitflow#432. The fact that this has, indeed, changed makes sense and may also explain #1830. This change makes all previous descriptions of Git Flow obsolete, or at least means we need to support both implementations somehow.

[HHobeck]

It makes absolutely no sense to tag the commit on the release branch and merge it afterwards with a dedicated merge commit to the main branch IMO. Normally if you are done with your deployment to production you are going to delete the release branch as well. In this situation if you get the tagged source code, GitVersion cannot know which branch this version is related to!! Ergo it's detached head and GitVersion doesn't support detached head mode.

I would recommend you to do a merge with a fast-forward strategy and delete the release branch afterwards -> the commit on release and on main branch is then the same. Anyway I would like to close this issue because the behavior is on the one hand no bug and on the other hand very abstruse and I think it's out of scope of GitVersion.

@black-snake are you agree with closing it?