Repository navigation
[Bug] tag-prefix still seems to be optionally considered #3282
Description
Describe the bug
After the changes made in #3216 , I was expecting my issue with tag-prefix to be fixed but that doesn't seem to have happened. The scenario is that I am working in a repo which already has some semver tags which are used to version an API. The format of these tags are like so:
- 2.9.0
- 2.8.0
- 2.7.0
- etc
We want to create an SDK Nuget package which we want to version independently.
Expected Behavior / Actual Behavior
I thought #3216 would allow me to specify a tag-prefix in my GitVersion.yml for my SDK version, meaning the existing tags would be ignored and GitVersion would fall back to counting the commits on the main branch, resulting in an initial version of 0.1.X. However, after specifying a tag-prefix of [vV], it's still picking up the existing tags and determining the next version as 2.9.X.
Steps to Reproduce
gitversion.yml
mode: Mainline
tag-prefix: '[vV]'
branches:
main: {}
ignore:
sha: []
Create a bunch of semver tags with no prefix. Run GitVersion. Resulting version is not 0.1.X
Your Environment
Running in a GitHub workflow/action like so:
name: Publish SDK
on:
push:
branches: [ "main" ]
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Install GitVersion
uses: gittools/actions/gitversion/setup@v0.9.15
with:
versionSpec: '5.x'
- name: Determine Version
id: gitversion
uses: gittools/actions/gitversion/execute@v0.9.15
with:
useConfigFile: true
configFilePath: ./.github/gitversion.yml
- Version Used: 5.11.1
- Operating System and version: Ubuntu 20.04.5
Activity
[-][Bug] tag-prefix still seems to be optional[/-][+][Bug] tag-prefix still seems to be optionally considered[/+]arturcic commentedon Nov 10, 2022
Hi @andyfurniss4 - that PR was merged in version 5.11.0, but we have reverted it back in 5.11.1 as it was not working as intended
Hopefully @AlexPykavy will have time to rework it. You are using 5.11.1, meaning the PR is not part of the tool
andyfurniss4 commentedon Nov 10, 2022
Ah, I see. I had not noticed the reversion! Thank you for clarifying! Is there an existing issue to track the rework or shall we use this one for that purpose?
arturcic commentedon Nov 10, 2022
If @AlexPykavy does not mind we can use this one
andyfurniss4 commentedon Nov 10, 2022
Adding a link to rollback issue: #3273
AlexPykavy commentedon Nov 20, 2022
I've tried to reproduce the #3273 issue but didn't succeed. Then I asked users who encountered the issue for help, but silence... @arturcic, @asbjornu, may I just repeat the same PR but this time to the
mainbranch? I can also note this change somewhere in docs. If you have another thoughts how to reproduce that issue, please share.asbjornu commentedon Nov 21, 2022
As we are unable to get @cfauchere or @mglochsen to reply or assist us with testing, I suspect
mainis a better target for this functionality, yes.arturcic commentedon Dec 22, 2022
🎉 This issue has been resolved in version 6.0.0 🎉
The release is available on:
Your GitReleaseManager bot 📦🚀