I am using GitVersion (version 3.5.3 if it matters), and getting some unexpected results; specifically the produced version has an unexpected commit count portion. Looking at the log I can see the commit count is calculated correctly, but the base version used by GitVersion is wrong (or at least not what I thought it would be).
However the log file for GitVersion is less than helpful, it just lists a series of tags, then a long list of merge bases, and at the end it just says which base version it decided to use.
Can GitVersion let me know somehow why it chose that specific base version?
I am not sure, you already checked or not; but it is explained how they calculate base version and also new versions in their documentation
UPDATE: Added main information from documentation.
Architecture
GitVersion has three distict steps for calculating versions in v3.0.
If the current commit is tagged, the tag is used and build metadata (Excluding commit count) is added. The other two steps will not execute
A set of strategies are evaluated to decide on the base version and
some metadata about that version. These strategies include
HighestReachableTag, NextVersionInConfig, MergedBranchWithVersion,
VersionInBranchName etc
The highest base version is selected, using that base version the new
version is calculated.
Visually it looks something like this:
Base Version Strategies
HighestTagBaseVersionStrategy - Finds the highest reachable tag from
the current branch
VersionInBranchBaseVersionStrategy - Extracts version information
from the branch name. eg release/3.0.0 will find 3.0.0
ConfigNextVersionBaseVersionStrategy - Returns the version from the
GitVersion.yaml file
MergeMessageBaseVersionStrategy - Finds version numbers from merge
messages. eg.
Merge 'release/3.0.0' into 'master' will return 3.0.0
FallbackBaseVersionStrategy - Always returns 0.1.0 for new
repositories
Each strategy needs to return an instance of BaseVersion which has the following properties
Source - Description of the source. eg `Merge message 'Merge
'release/3.0.0' into 'master''
ShouldIncrement - Some strategies should have the version
incremented, others do not. eg ConfigNextVersionBaseVersionStrategy
returns false, HighestTagBaseVersionStrategy returns true
SemanticVersion - SemVer of the base version strategy
BaseVersionSource - Sha of the source. Commits will be counted from
this Sha. Can be null (eg ConfigNextVersionBaseVersionStrategy
returns null)
BranchNameOverride - When useBranchName or {BranchName} is used in
the tag configuration, this allows the branch name to be changed by a
base version. VersionInBranchBaseVersionStrategy uses this to strip
out anything before the first - or /. So foo ends up being evaluated
as foo. If in doubt, just use null
Related
In my release pipeline for a dotnet core project, I want to increment the assembly version automatically so I don't need to update it manually each time. This is so my Nuget version is increased every time.
At the moment I'm using the dotnet pack command and adding the build number at the end using the "Automated Package Versioning" set to "Use Environment Variable: Build.BuildNumber". Then I set the "Option > Build Number Format" to "1.0.$(BuildID)". First, I tried setting the attribute of the .csproj file to 1.0.$(BuildID), but the pipeline did not pick that up.
The problem is that I have to edit my build pipeline every time I want to adjust my major or minor semver version. Yet with the teams, we agreed not to put build pipeline config in source control (yaml files). Is there a way we can put a part of the build pipeline in a yaml file so that we can override parts of the configuration?
For example: I could set the "Build Number Format" to "$(Major).$(Minor).$(BuildID)" and then the partial yaml could override the Major and Minor variables.
How to set up automatic nuget version increments
If you want to automatic nuget version increments, you could use the BuildNumber $(Rev:r) instead of $(BuildID):
Run (build) number:
$(Rev:r)
2 (The third run on this day will be 3, and so on.)
Use $(Rev:r) to ensure that every completed build has a unique name.
When a build is completed, if nothing else in the build number has
changed, the Rev integer value is incremented by one.
If you want to show prefix zeros in the number, you can add additional
'r' characters. For example, specify $(Rev:rr) if you want the Rev
number to begin with 01, 02, and so on.
So, you could set the Build Number Format to $(Major).$(Minor)$(Rev:.r).
Hope this helps.
Is there a way to disable GitVersion using the branch name?
We had an inadvertent build number increment as the result of using a branch named: 3.16-changelist
The current build version was 3.16.0
After merging that branch it was: 3.16.1
That was unexpected. Wondering if that behavior can be disabled.
Thanks.
I have a ConcourseCI pipeline that automatically increments my version number using this resource type: https://github.com/concourse/semver-resource
My resource declaration looks like this:
- name: version
type: semver
source:
driver: git
initial_version: 0.0.1
uri: {{version-repo-uri}}
branch: {{version-repo-branch}}
file: {{version-file}}
private_key: {{git-key}}
And my job looks like this:
- name: increment-version
plan:
- get: {{git-repo-name}}
trigger: true
- get: version
params: {bump: patch}
- put: version
params: {file: version/version}
So as you can see, right now I'm always bumping PATCH version. However, I'd like an easy and preferably automated way for the pipeline to increment MAJOR, MINOR, PATCH, or RC version depending on the circumstances.
Is there a git hook or something similar that will know when to bump what? Any implementation best practices when automating semver into a pipeline? Any other Concourse resource-type I should be using instead? Or is this something we should definitely leave for a human to decide? And in that case, how to easily integrate that "manual" step into a CD pipeline?
The closest thing I can think of is having a version file in my project (committed to github) with the intended version, which will set MAJOR, MINOR, PATCH numbers. The pipeline picks ups that file, uses it as a base somehow, and only increments RC numbers, but this feels incredibly error prone.
To be clear, I'm not asking how to version releases in theory, and the meanings of what major, minor, or patch are. I'm asking in practice how to implement those recommendations listed on https://semver.org/.
My solution to this problem is to tag the commits, and a script which reads the Git commit message and steps the version based on the content:
If a version tag exist on the current commit: always step PATCH.
Else:
List all commits until the previous tag.
If any message contains "step: major" then step MAJOR
Else if all messages contain "step: patch" or "step: micro" then step PATCH
Else step MINOR
This means that if the committer does not state anything in the message, then the change is assumed to be a functional change.
Tag and push the commit before the built artifact is distributed. Otherwise the next build could produce an already existing version.
Just modify the logic as needed for your use cases.
Is There any Options to Clone a Word / Excel / Presentation Based on document version number
for Ex:
version - 4
version - 3
version - 2
version - 1
Here I need to clone Version 4 In Onlyoffice Document Integration Server
and without any mismatch of editor contents
here I uploaded the image in that 7 version are there, I need to clone a 4'th version (which means version 4,3,2,1 and I don't want 5,6,7) it's not like rollback, original document should not get change while cloning.
Please describe the case more detailed, we need more information about the whole process, i.e. are you going to just copy the file or start a new conversion process?
Could you please specify if the versioning already works in your environment.
If yes, how is it organized.
Im trying to automate deployment of perforce (p4 & p4v) using puppet. For this I have created a perforce resource
perforce { 'p4' :
version => '>= 15.1',
ensure => 'present',
}
The problem I have is how to determine installed version. Perforce sort all tar balls in release order .../R15.1/... but running p4 -V yields a version number that looks more like date and build no , e.g. 2016.2.345671
Is there a way that I can get the release installed?
I'm not really sure what you're asking since it sounds like you already know about p4 -V, but will try to answer the implied question of "what do all the pieces of the version string mean"...
"2016.2" is the same as "r16.2" -- releases are named according to the year of release, and there have historically been two major releases most years so the version numbers tend to be of the form YEAR.1 and YEAR.2.
The number at the end of the version string in the binary is basically the patch level (it correlates with changes in the release notes).
Here's an example of using a regex to deconstruct a Perforce version string:
https://swarm.workshop.perforce.com/files/guest/sam_stafford/scripts/itest.pl#401