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.