arturcic on 5.3.6
/home/runner/.nuget/packages/gitversiontask/5.1.3/build/GitVersionTask.targets(10,9): warning : 2020-01-16 19:19:16 WARN [01/16/20 19:19:16:29] Unable to read cache file /home/runner/work/event-sorcery/event-sorcery/.git/gitversion_cache/61BA4200E58C0052BC7002D1FE8C8D7E6C5D701C.yml, deleting it.
Hello there. I'm looking at the examples for GitFlow and at the same time reading the description for Git Branching Strategies for GitFlow. What I cant wrap around my head is the example for Minor Release Branches when combined with the description.
When the branch for release/1.3.0 is created, I figure that the version on branch develop is bumped to 1.4.0 (minor+1) by looking at the version given in the release branch name. A commit is done on the develop branch yielding
1.4.0-alpha.1 (1 = number of commits ahead of release/1.3.0), so far so good. Now to my confusion... Once the release is completed and release/1.3.0 is merged with master and develop I do not understand how the version for develop is determined as
1.4.0-alpha.4? How can develop be 4 commits in front of master at this point since all commits done in release/1.4.0 have been merged both to develop and master?
you can either put this in the root (named GitVersionConfig.yaml):
mode: ContinuousDeployment assembly-versioning-scheme: MajorMinorPatch next-version: 1.2.0
tag the branch with 1.2.0
using var fixture = new EmptyRepositoryFixture(); fixture.Repository.MakeACommit(); fixture.BranchTo("develop"); fixture.Repository.MakeCommits(3); fixture.AssertFullSemver("0.1.0-alpha.3"); fixture.BranchTo("release/0.2.0"); fixture.Repository.MakeACommit(); fixture.Checkout("develop"); fixture.Repository.MakeCommits(3); fixture.AssertFullSemver("0.3.0-alpha.3"); // Merge to master fixture.Checkout("master"); fixture.Repository.MergeNoFF("release/0.2.0"); // Merge to develop //first need to sync release with dev to avoid conflict in PR fixture.Checkout("release/0.2.0"); fixture.Repository.MergeNoFF("develop"); //than merge release to dev fixture.Checkout("develop"); fixture.Repository.MergeNoFF("release/0.2.0"); fixture.AssertFullSemver("0.3.0-alpha.5"); //but we get alpha.3 fixture.Repository.MakeACommit(); fixture.AssertFullSemver("0.3.0-alpha.6");
Hey guys. My team suddenly started having this issue yesterday where all of our pipelines that used gitversion failed to resolve to any variable.
- task: gittools.gitversion.gitversion-task.GitVersion@4 displayName: GitVersion inputs: preferBundledVersion: false
And the build number getting resolved was
$(GitVersion.NuGetVersion) instead of the actual formatted version like before yesterday noon PST.
I managed to get the build to populate the variable and build successfully by bumping the version to 5
So now we have
- task: gittools.gitversion.gitversion-task.GitVersion@5 displayName: GitVersion inputs: preferBundledVersion: false
Problem is. All of our versions got reset now.
We went from, with
@4, 1.5.7 to, with
Can anyone give me a hand in figuring out what to do?