When using ContinuousDeployment, Version number restarts at 1 every day. (devops)

[vllama]

Describe the bug
In Azure Devops:
We have library set up for ContinuousDeployment when committing to a Sprint* or develop* branch. Every morning the preview number resets to 1. As well it resets to 1 when a build is manually run.

Expected Behavior

The preview number should increment indefinitely.

Actual Behavior

The Preview number resets to 1.

Possible Fix

N/A

Steps to Reproduce

assembly-file-versioning-format: '{Major}.{Minor}.{Patch}.{WeightedPreReleaseNumber ?? 0}'
assembly-versioning-scheme: MajorMinorPatch
branches:  
  release:
    regex: releases?[/-]
    mode: ContinuousDelivery
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: true
  develop:
    regex: ^(dev(elop)?(ment)?)|(Sprint.+)$
    mode: ContinuousDeployment
    tag: 'Preview'
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    tracks-release-branches: false
    is-release-branch: false    
ignore:
  sha: []

Context

Your Environment

• Version Used: Tool 'gitversion.tool' (version '5.12.0')
• Operating System and version (Windows 10, Ubuntu 18.04): windows-latest agent in devops
• Link to your project:
• Link to your CI build (if appropriate):

[HHobeck]

Dear Vlad,

First of all if you are figuring out that every morning the number goes to one then that indicates (in my opinion) that something happens in your repository every night. Have you done a diff of your repository or analysis the logs? Second without steps to reproduce it's not possible to help you.

If you done the analysis and think it's still a bug in git-version please try the preview version: https://github.com/GitTools/GitVersion/releases/tag/6.0.0-beta.2

[vllama]

Dont' know what additional steps to reproduce I could provide, other than submitting my whole repo.

It just randomly happened again, where the preview version jumped back on a feature branch for no reason at all.
We did six sequential pushes to the same branch, no other activity in the repo at all. the gitversion .yml file is the same on as above. Not sure what we are doing wrong to cause the preview number to go back to one,. I can't find any documentation on how the preview # logic works or is calculated.

[HHobeck]

I'm going to move this issue to the discussion section because it seems to me not a bug report.

[HHobeck]

I can't find any documentation on how the preview # logic works or is calculated.

@vllama Please take a look to the following sequence diagrams which documents how the pre-release number will be incremented in git-version: GitFlow Examples. There are a lot of integration tests existing in code which might be worth to take a eye on it.

[facusantillo]

My two cents:

I have reproduced this but only with commits instead of pull requests.

Let's say you have the following configuration:

  feature:
    mode: ContinuousDelivery
    label: useBranchName
    #increment: Inherit
    prevent-increment-of-merged-branch-version: false
    track-merge-target: true
    regex: ^featur(e|es)?[/-]
    source-branches:
      - feature
      - hotfix
      - develop
      - main
      - release
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: false
    pre-release-weight: 30000

If you perform a commit into the branch the PreReleaseNumber would be set to 1.

After another commit is made in the same feature branch, one could expect the PreReleaseNumber to be 2, but, it remains at 1.

My guess is while the ContinuousDeployment mode is setting the PreReleaseNumber with the CommitsSinceVersionSource (based on what I saw in the NextVersionCalculator.cs logic ) the ContinuousDelivery mode it's not taking into consideration any commits at all performed in that specific branch.

That being said, it could be probably an expected behavior to find some builds with the same PreReleaseNumber and in fact, I managed to reproduce it easily in a pipeline (see screenshot below)

I guess as a user, someone could expect an increment in the PreReleaseNumber tracking only the commits that specific branch has.

In summary:

• If you have 20 commits in your mainline and 3 commits in your feature branch while the mode is ContinuousDeployment: PreReleaseNumber should be 23
• If you have 20 commits in your mainline and 3 commits in your feature branch while the mode is ContinuousDelivery: PreReleaseNumber should be 3 (today is not adding up, and remains 1)

Thanks

[HHobeck]

@facusantillo When using the mode ContinuousDelivery this is expected behavior that the pre-release number remains.