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.
Related
I have a gitlab repository with a protected branch "main" that is the current working version source, then at some point in time this branch is forked for the current version Release (say Version 2.0) and protected. Main is then used for the next version release (Version 3.0).
Each developer will create a unique branch for feature/bug changes that will get merged into the protected branch. Now a bug has been found in the Version 2.0 release that must be patched, therefore the bug also exists in the main as well. Developer creates a branch off the Version2.0 and fixes the bug.
How do I get the bug fix into both protected branches with a single merge?
Basic concept of a single merge is a "Merge Request" to Version2.0, that then automatically mirrors the change to main. However I cannot have changes to main merged to Version2.0.
/-B-\ /-F-\
----------\----/-----\--/-----\------------/--------Main
\ /
\----Version2.0-\------------/----
\ /
\-- Bug--/
Or am I going to have to merge to Version 2.0 then rebase the bug onto Main then merge again?
/-B-\ /-F-\ /-Bug-\
----------\----/-----\--/-----\-------/-------\--------Main
\
\----Version2.0-\---------/----
\ /
\-Bug-/
I am trying to avoid having to be the commit overseer to make sure that every commit to V2.0 is included in v3.0, otherwise we will find the same bug again and assign someone to dedicate time to fix (again).
I have a multi-module build with one "leading" module and one additional one. I have set things up so that the additional module is only built when either it or the build files have changed:
build:sbt:module-main:
extends: .build-sbt
build:sbt:module-a:
extends: .build-sbt
only:
changes:
- module-a/**/*
- project/**/*
- "*.yml"
- "*.sbt
The behaviour I observe is that in a pipeline resulting from pushing a new branch, both modules are always built, regardless of the actual changes. Then when new commits are pushed to the branch, the pipelines triggered off of those will behave according to my rule, i.e. module-a will only be built when there was a change that affects it.
I would expect the same behaviour from the start.
I assume that "change" means "what git thinks has changed between this branch and the branch it was based off of". Is that not what change means in this context?
While searching for another answer I discovered by accident that Gitlab is working as designed in this case.
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.
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.
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