The Background:
I have a Git repository with random tags for various things however when our pipeline runs we execute GitVersion to calculate the version number for a nuget package in the solution. Tags such as '2023.02.28' and 'random-text'. I'd like GitVersion to only consider tags that start with V to simplify things with the nuget package.
The Problem:
GitVersion is not using the tag-prefix setting (or I'm using it wrong) and is instead taking a more recent tag, 2023.02.28, instead of the desired tag, v2.0.9.
I've tried setting tag-prefix to the following variations to no avail
as well as many other "throw **** at the wall and see what sticks" formats.
I'm really stuck here because even according to the documentation
A regex which is used to trim Git tags before processing (e.g., v1.0.0). Default is [vV], although this is just for illustrative purposes as we do a IgnoreCase match and could be v.
It appears this should just be out of the box this should be the way it works.
So this was a fundamental misunderstanding of how this setting should work. as Francisco pointed out in the comments this is a filter/pattern to remove from tag names before attempting to parse the version.
What this actually means is when you tag a commit as v2.0.1 the tag-prefix is removed prior to GitVersion attempting to parse the value. The default of [vV] in this instance will remove the v and GitVersion will then see 2.0.1.
In my instance I ended up implementing a convention of tag patterns. so for the core application we use rls/core/[version] and for the nuget package we use rls/package/[version]. So in the GitVersion.yml file set tag-prefix to rls/core/ and when the build script gets the version for the nuget package I use the overrideconfig argument /overrideconfig tag-prefix="rls/package/"
This seems to be working as desired now. Hopefully this will help some future person that shared the same misunderstanding as I did.