Build Servers

Depending on the Build Server being used, i.e. TeamCity, Jenkins, etc, GitVersion might need to extra repository information in order to work correctly. In has knowledge of most of the main CI Providers, and when instructed to do so, it will fetch the necessary information in order to correctly assert the semantic version number.

In addition, most build servers allow the setting of the build number within the system, GitVersion knows how to do this automatically. GitVersion has support for quite a few build servers out of the box. Currently we support:

AppVeyor Details on the AppVeyor support in GitVersion
Azure DevOps Details on the Azure DevOps or Team Foundation Server Build Pipeline support in GitVersion
Bamboo Details on the Bamboo support in GitVersion
Continua CI Details on the Continua CI support in GitVersion
GitLab CI Details on the GitLab CI support in GitVersion
Jenkins Details on the Jenkins support in GitVersion
MyGet Details on the MyGet support in GitVersion
Octopus Deploy Details on the Octopus Deploy support in GitVersion
TeamCity Details on the TeamCity support in GitVersion

When the gitVersion executable is run with the /output buildserver flag instead of outputting JSON it will export variables to the current build server.

For instance if you are running in TeamCity after you run gitversion /output buildserver you will have the %system.GitVersion.SemVer% variable available for you to use in the rest of the build configuration.

When running in MSBuild either from the MSBuild Task or by using the /proj myproject.sln parameter, GitVersion will make the MSBuild variables available in the format $(GitVersion_SemVer)`

The standard gitversion executable normalize the branches if there is a build server detected. This behavior can be disabled with the /nonormalize option.

GitHub