Build error when building from detached head should be downgraded to warning.

[distantcam]

When building from a detached head, GitVersion errors out the build and the only option is to disable GitVersion.

Instead a warning should be produced, and perhaps set the version to something like "HEAD-[SHA]" to show that this is not a normal build.

[pvandervelde]

@distantcam @JakeGinnivan Has this actually been fixed? I'm currently running into this with the 1.1.0 release version.

[distantcam]

@pvandervelde It has been fixed, but I believe only for GitHubFlow not GitFlow. Do you have a develop branch?

[pvandervelde]

Yeah I do now. I recently switched from GitHubFlow to GitFlow. I'm currently trying to build the release branch. I think the problem is caused because the build server only checkout the branches it needs. It's currently doing:

git clone -q --branch=release/0.3 https://github.com/pvandervelde/nBuildKit.git C:\projects\nbuildkit
git checkout -qf 04e111079475a9f31015ee7d44c293a254bc6643

Then when I run my build when I get to the GitVersion bit on my machine that fails with the aforementioned error.

[distantcam]

Appveyor? Ah, I thought I had fixed that. :(

I suspect other changes may have broken Appveyor support.

Does it build fine locally, with gitversion turned on?

[pvandervelde]

Actually in AppVeyor it seems to work. When I run the same build locally (because I'm trying to debug another issue) it fails horribly.

Also out of curiosity how did you know it was AppVeyor?

[distantcam]

Appveyor is the only build system I know of that only does a partial clone like that. As I've said I had issues with it in the past.

[pvandervelde]

Was any progress made on this? I'm running into this now with Jenkins. The git commands look like this:

Cloning the remote Git repository
Cloning repository http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools
 > git.exe init c:\builds\DevInfrastructure_BuildTools_CI_Release\workspace # timeout=10
Fetching upstream changes from http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools
 > git.exe --version # timeout=10
using .gitcredentials to set credentials
 > git.exe config --local credential.helper store --file=\"C:\Users\ZTFSBU~1\AppData\Local\Temp\git3031184903582276910.credentials\" # timeout=10
 > git.exe fetch --tags --progress http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools +refs/heads/*:refs/remotes/origin/*
 > git.exe config --local --remove-section credential # timeout=10
 > git.exe config remote.origin.url http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools # timeout=10
 > git.exe config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
 > git.exe config remote.origin.url http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools # timeout=10
Fetching upstream changes from http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools
using .gitcredentials to set credentials
 > git.exe config --local credential.helper store --file=\"C:\Users\ZTFSBU~1\AppData\Local\Temp\git4849626499386884143.credentials\" # timeout=10
 > git.exe fetch --tags --progress http://tfs:8080/tfs/vista/DevInfrastructure/_git/BuildTools +refs/heads/*:refs/remotes/origin/*
 > git.exe config --local --remove-section credential # timeout=10
Seen branch in repository origin/develop
Seen branch in repository origin/master
Seen branch in repository origin/release/0.1
Seen 3 remote branches
Checking out Revision 63814a8d9afde8ea533c479744d0aa1c1c5fd463 (origin/release/0.1)
 > git.exe config core.sparsecheckout # timeout=10
 > git.exe checkout -f 63814a8d9afde8ea533c479744d0aa1c1c5fd463
 > git.exe rev-list 63814a8d9afde8ea533c479744d0aa1c1c5fd463 # timeout=10

I end up with the following response to git branch

* (detached from 63814a8)

I'm not sure if GitVersion can go back to the repository and find out which branch this thing is on or that I need to fix up my git 'clone' in Jenkins. If the latter I'd appreciate it if somebody could tell me what to do.

[pvandervelde]

To add to the excitement I have something else that didn't go quite as expected.

My error from yesterday may be due to the fact that there was no merge commit because the builds were on a fresh repository, hence master had 2 files in it (the readme and the license) created in 2 commits by GitHub. I then cloned the repository locally and created a dev branch (used SourceTree to setup my GitFlow branches). After that I started developing on my first feature (created my feature branch) and that all went well (GitVersion gave me version 0.1 which makes sense). Then I merged the code into develop and started a release branch (releases/0.1) at which point it worked in my local workspace but no longer worked on the build server (see previous comment).

In order to get past it I did the building and merging from my own workspace (which works just fine) and now I have a repository with my first merge commit on master. I now have to create a hotfix to my current release (created the hotfix/0.1.1 branch). On my local workspace the version number becomes 0.1.1-beta.1+1 but on the build server it becomes 0.1.0.

I suspect this is once again because Jenkins only pulls in the change and not any of the other branches. So my question is: Am I doing something wrong here? Should I change my Jenkins setup or is there a config setting / command line parameter that I have to pass to GitVersion? @nulltoken @JakeGinnivan @SimonCropp

[JakeGinnivan]

Looks like #326 closes this issue.

Closing, lets create a new issue if this is still an issue.