Skip to content

GitVersion should only consider tags matching current branch config (was: GitVersion fails to return correct version when tag exists on commit) #2340

@DocZoid

Description

@DocZoid

Describe the bug
Tags have a too strong weight on the version evaluation which I feel is a bug. I am quite new to versioning and GitVersion, so I might be on the wrong track without knowing. I have read in some other issue that fast-forward merges for master are generally discouraged (forbidden?), and this is a part of my issue (#2). The proposed fix would as a side effect allow using fast-forward merges in my opinion.

There are two scenarios where the tag should not be used to evaluate the version:

  1. When I build a snapshot from the develop branch, tag the branch with the created version (e.g. 0.1.2-snapshot.2), and then branch this commit to a new release (release/0.1.2)
  2. When I build a release candidate from a release branch, tag the release branch with the new created version (e.g. 0.1.2-rc.1), and then make a fast-forward merge to master, essentially having master point to that tagged commit

Expected Behavior

  1. The resulting version should be 0.1.2-rc.1 (with the release configuration "tag: rc")
  2. The resulting version should be 0.1.2

Actual Behavior

  1. The resulting version is 0.1.2-snapshot.2 based on the tag
  2. The resulting version is 0.1.2-rc.1 based on the tag

Possible Fix

Multiple branches point to the same commit. This is confusing GitVersion, which takes tags from that commit, but it does not respect the branch configuration of the current branch when analyzing the tags, e.g. when I am working on a release branch, it should only look for previous version tags which are formatted like its own tag configuration in the release branch ("with "rc" in it, so tags 0.1.2-rc.1 should be considered, but not 0.1.2-snapshot.2, because of the configuration "tag: rc")

Steps to Reproduce

  1. assume or create config: "develop -> tag: snapshot", "release -> tag: rc"
  2. tag a commit in "develop" with a version tag, e.g. 0.1.2-snapshot.2
  3. branch that commit to release/0.1.2
  4. using release/0.1.2 as current branch, run GitVersion. Calculated version should be 0.1.2-rc.1 instead of 0.1.2-snapshot.2

Context

We have commit hooks checking every commit message. Therefor, it seems like an easy option to use fast-forward merges for master to avoid commits, but GitVersion is missing the mentioned configuration option to be able to handle fast-forward merges.
Also, I do not know how GitVersion is intended to be used when creating a release branch without adding an empty commit on that branch before building it, if the commit already has a tag. Deleting all tags locally would be a workaround, but it has a smell of nastiness.

Your Environment

  • Version Used: 5.3.3+Branch.master.Sha.08a43ede0b292c8ce2178b3d305587f151a2bdf4
  • Operating System and version (Windows 10, Ubuntu 18.04): Windows 10
  • Link to your project: -
  • Link to your CI build (if appropriate): -

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions