Use convention to derive a SemVer product version from a GitFlow based repository
arturcic on 5.3.6
Hey again everyone, more detail on my problem from a few days ago:
mode: Mainline
increment: Patch
branches:
develop:
mode: ContinuousDeployment
When I'm running the above configuration, when I go to generate a version off of master
following a merge of develop
into it, I get the following error: Mainline development mode doesn't yet support pre-release tags on master
What's weird is that I've never tagged master
with any pre-release tags. Only my develop commits have been the target of pre-release tags... I basically want pre-release behaviour on my develop
branch, but any time I merge to master
, I want it to cause a minor version increment.
Is anyone using GitVersionTask in a GitHub workflow action? I've just tried to set it up and got a rather confusing error message:
GitVersionTask.targets(46,9): error : GitVersionException: Cannot find commit 2108544aed45614f96f35440d4fadfa70773b8e0. Please ensure that the repository is an unshallow clone with
git fetch --unshallow
eek! What do I do?
Hoping somebody can point out what I'm doing wrong here...
I'm using ContinuousDeployment mode for this flow
Commit to master and run gitversion, it outputs 1.1.0-ci.0
Create a release branch (release/v1.1) from master and run gitversion, it outputs v1.1.0-beta.0
Tag the HEAD commit of release/v1.1 and run gitversion on the tag, ERROR
It looks like the branch being examined is a detached Head pointing to commit '88e98c4'. Without a proper branch name GitVersion cannot determine the build version.
But, I joined gitter to ask specifically about monorepos.
I have a large monorepo that I would like to try and tackle if possible. I see some mention of using tag prefixes.
Lets say I have the following
SuperSolution\
\SuperLibraryThing (NuGet package)
\AnotherLibraryThing (NuGet package)
\SuperApp (ASP.NET Core web app)
I assume I would potentially have a different GitVersion.yml in each of those folders, and I would perhaps set tag-prefix: superlibrarything for the first GitConfig.yml, tag-prefix: anotherlibrarything, for the second, etc
@PatrickBig you should had the following to your YAML:
variables:
GitVersion.SemVer: ''
GitVersion.AssemblySemVer: ''
GitVersion.MajorMinorPatch: ''
GitVersion.InformationalVersion: ''
steps:
task: gitversion/setup@0
inputs:
versionSpec: '5.x'
displayName: 'GitVersion setup'
task: gitversion/execute@0
displayName: 'GitVersion execute'
task: DotNetCoreCLI@2
displayName: 'dotnet build'
inputs:
command: 'build'
projects: '$(project)'
arguments: '/p:Version=$(GitVersion.SemVer)
/p:AssemblyVersion=$(GitVersion.AssemblySemVer)
/p:FileVersion=$(GitVersion.MajorMinorPatch)
/p:InformationalVersion=$(GitVersion.InformationalVersion)
--configuration $(buildConfiguration)'
mode: ContinuousDelivery
continuous-delivery-fallback-tag: ''
branches: {}
ignore:
sha: []
merge-message-formats: {}
0.1.0
on master. Created hotfixes/0.1.1
from master
.
hotfixes/0.1.1
, which GitVersion asserted as 0.1.1-beta.1+71. Perfect.
0.1.1-beta.1
(I'm following the GitFlow example here https://gitversion.net/docs/git-branching-strategies/gitflow-examples#hotfix-branches)
refs/heads/pull/943/merge
is not going to be providing GitVersion with an accurate history to work off of.