Unable to use gitversion as part of AppVeyor build

[Kimserey]

Description

I am unable to use Gitversion as part of my build to version my application.
What are the recommendation to use gitversion as part of AppVeyor build to version .NET application?

Steps

At the beginning of the build, AppVeyor clones the repository and checkouts out the commit meant to be built:

git clone -q --branch=[my branch] https://[my repo].git C:\projects\[...]
git checkout -qf [commit to build]

But when Gitversion runs I see the following error:

INFO [09/17/18 9:35:55:42] Running against branch: (no branch) ([commit to build])
WARN [09/17/18 9:35:55:42] An error occurred:
It looks like the branch being examined is a detached Head pointing to commit '[commit]'. Without a proper branch name GitVersion cannot determine the build version.

I tried then using dynamic repository but it wouldn't checkout the branch on the right commit, for example:

gitversion /url [url] /b test-gitversion /c 68264bd15c7364c3f3e53c764260776d4706d288

---

* 317aab8 (origin/test-gitversion, test-gitversion) removed another comment
* 68264bd (HEAD) removed comment
* 1570202 (tag: 1.15.5-alpha.1) Try to resolve first variable from local repository before trying dynamic.
* f77f974 (origin/master, origin/HEAD, master) removed more

It would checkout test-branch on the same level as master branch f77f974 and not 68264bd.

[Kimserey]

I managed to use a workaround by checking out into a branch name alpha part of the before_build step.

before_build:
  - cmd: git checkout -b alpha
  - cmd: gitversion /l console /output buildserver

And naming my alpha tag 1.0.0-alpha.1, 1.0.0-alpha.2, 1.0.0-alpha.3,... works as expected.

[dazinator]

Odd. I have used gitversion with appveyor in various projects and not needed any additional git checkout commands.

For example, I use it here in DotNet.Glob: https://ci.appveyor.com/project/dazinator/dotnet-glob/branch/master

Here is my appveyor.yml: https://github.com/dazinator/DotNet.Glob/blob/develop/appveyor.yml

[Kimserey]

Thanks @dazinator, I can see from DotNet.Glob that even branches versions can be found.

Would you know in which scenario I would get the error It looks like the branch being examined is a detached Head pointing to commit '[commit]'. Without a proper branch name GitVersion cannot determine the build version.?

[dazinator]

@Kimserey afraid not but if I had to guess it sounds related to how the build server is checking out the repo - i.e in your case its in detached head mode. Perhaps its worth you asking the AppVeyor folks why your build would be different from my AppVeyor build in this regard..

[Kimserey]

Hi @dazinator ,

I had a look and it seems like the problem arise in the following circumstances:

1. Push commit to master
2. Build is triggered
3. Push quickly another commit to master before Build starts
4. When build starts, it is no longer triggered on latest master therefore checkout on detached head
5. Gitversion not able to deduce the version with the message It looks like the branch being examined is a detached Head pointing to commit '1d11d84'. Without a proper branch name GitVersion cannot determine the build version.

Is it intended to behave this way or have I got the scenario wrong?

Thanks!

PS: I appreciate that you left the comment open even though it's been 2 months! Thanks a lot for your patience.

---

On another note, I also can't get it to work on VSO (or also known as Azure Devops 😄).

The commit gets checkout as a detached branch, here's in the default command to checkout repository:

2018-12-07T09:23:41.9074804Z ##[command]git remote add origin https://github.com/Kimserey/dummy-api.git
2018-12-07T09:23:41.9099845Z ##[command]git fetch --tags --prune --progress --no-recurse-submodules origin
2018-12-07T09:23:43.2337154Z ##[command]git checkout --progress --force c506a20ba0ff0d6ab3d30b89919310ea056d3488

Commit c506a20ba0ff0d6ab3d30b89919310ea056d3488 is the latest commit on master branch.

Which then result in the detached Head error message.

---

It seems to be related to the fact that it is in a detached branch and that the current checkout commit is on two different branches. This is the few last lines of the warning:

INFO [12/07/18 10:02:58:52] Using latest commit on specified branch
INFO [12/07/18 10:02:58:52] Begin: Getting branches containing the commit 'c506a20ba0ff0d6ab3d30b89919310ea056d3488'.
  INFO [12/07/18 10:02:58:52] Trying to find direct branches.
  INFO [12/07/18 10:02:58:52] No direct branches found, searching through tracked branches.
  INFO [12/07/18 10:02:58:52] Searching for commits reachable from 'origin/gitversion-test-branch'.
  INFO [12/07/18 10:02:58:53] The branch 'origin/gitversion-test-branch' has a matching commit.
  INFO [12/07/18 10:02:58:53] Searching for commits reachable from 'origin/master'.
  INFO [12/07/18 10:02:58:53] The branch 'origin/master' has a matching commit.
INFO [12/07/18 10:02:58:53] End: Getting branches containing the commit 'c506a20ba0ff0d6ab3d30b89919310ea056d3488'. (Took: 7.97ms)
INFO [12/07/18 10:02:58:54] Running against branch: (no branch) (c506a20ba0ff0d6ab3d30b89919310ea056d3488)
WARN [12/07/18 10:02:58:54] An error occurred:
It looks like the branch being examined is a detached Head pointing to commit 'c506a20'. Without a proper branch name GitVersion cannot determine the build version.

[dazinator]

@JakeGinnivan @asbjornu @gep13 any ideas?
I wasn't aware appveyor checked out in detached head mode if the commit was non current.

[gep13]

@dazinator I wasn't aware of this, and I can't say that I have seen this happen on any of the repositories that I run in AppVeyor, where GitVersion is being used.

[asbjornu]

Weird. I've never encountered this either. Either way, I believe #1243 or #1244 might be a solution to problems like these.

[Kimserey]

Hi guys, thanks a lot for the follow up.

I guess my question now changes slightly toward how to deal with repository like my test repository Kimserey/dummy-api.git whereby the last commit is on two branches.

Is there a way to make GitVersion able to recognize the version even though the CI Server checks out on detached branch (talking about VSO here).

VSO is executing the following commands, which if reproduced locally would yield the error:

git init
git remote add origin https://github.com/Kimserey/dummy-api.git
git fetch --tags --prune --progress --no-recurse-submodules origin
git checkout --progress --force c506a20ba0ff0d6ab3d30b89919310ea056d3488

@asbjornu , thanks a lot for the pointers but I couldn't understand how it relates and how I can use it?

[asbjornu]

@Kimserey, there's nothing in those pull requests you can use yet, I was mostly referencing them to know which issues we might solve by finalizing them. 😃 To indicate which Git reference (branch or tag) a given commit is being built for, you provide GitVersion with the environment variable Git_Branch. I can see that information is missing from AppVeyor, but you can read about it in the TeamCity documentation.

[asbjornu]

I just had the same experience with a PR build on Travis, so this doesn't seem to be exclusive to AppVeyor. #1314, #1501 and #1523 all seem to be about the same issue, indicating that this is something we ought to fix in GitVersion. Even setting the environment variable Git_Branch seems to have no effect, which is odd.

[dennisdoomen]

I've experienced the same thing with GitVersion 4.0 on both TeamCity as well as AppVeyor. For TC, I managed to get it to work by using the teamcity.git.fetchAllHeads=true option. However, there does not seem to be a workaround for AppVeyor. I had to manually build the latest version of Fluent Assertions and push it to NuGet.

In all scenarios, it looks like it is indeed caused by building a tag from a branch that already has successive commits as explained by @Kimserey in #1477 (comment).

The same problem did not happen with GitVersion 3.x.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[asbjornu]

@dennisdoomen, are you sure this wouldn't happen with GitVersion 3.x, or have build servers just gotten a lot more aggressive wrt. reducing the amount of data they pull from a repository as of late?

[dennisdoomen]

I don't think so, because the branch that still uses GitVersion 3 had no issues.

[asbjornu]

Hm. I wonder what might be causing this that has changed since v3, then. Ideas?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.

[asbjornu]

Also, #1523 seems to indicate that the problem existed in GitVersion 3.6.5 as well.

[m-jepson]

I'm having issues all over the place with Gitlab CI, mainly the same issues. It complains about detached heads, and other issues like "Could not find a 'develop' or 'master' branch, neither locally nor remotely", while both exist.

[asbjornu]

@m-jepson, are you sure master and develop exists on GitLab at the moment of the build? Please do a git branch -vv in the build to list branches. As mentioned elsewhere, you have to ensure that the Git repository checked out is not a shallow clone and that the required branches exist locally. This is how I've modified a build for Travis CI to make GitVersion work:

- git fetch --unshallow || true # Travis might do a shallow clone, but GitVersion needs the full history including branches and tags
- git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
- git fetch origin
- git branch master origin/master || true # GitVersion seems to require a local "master" branch these days. That's a bug, but oh well.
- if [ "$TRAVIS_PULL_REQUEST" != "false" ]; then git checkout -b "$TRAVIS_PULL_REQUEST_BRANCH-pr"; fi # Create an explicit branch on pull requests as I'm unable to pass Git_Branch into the Docker container for some

[m-jepson]

Hi @asbjornu ,

I'll try your exact solution, rather than simplifying it. That's probably where I went wrong. I'll let you know how it works out.
BTW, will this repeatedly give the same version in CI, even if there's more new commits after it? The old way we did builds, was on a Windows server running gitversion and that always gave the same version for the same commit.

[m-jepson]

Well, this seems to work. Thanks for the help!
Still curious though, why the old version "just worked". Is this something you are going to fix, or is this just a change we'll have to learn to live with?

[asbjornu]

I believe the change here is mostly in build servers, not in GitVersion. There's a bug in GitVersion around not treating origin/master as master, but otherwise, build servers have gotten more efficient by doing shallow clones, detached HEAD builds and other tricks to speed up builds by effectively dropping Git history and metadata. With all of this history and metadata missing, builds are faster, but as GitVersion requires all of it to work, it predictably fails.

What we can do is improve documentation around this, so it's clearer what to do when GitVersion fails in a build server.

[m-jepson]

It seems to work, until I have it determine the version for the build of a specific tag:

The final message is:

It looks like the branch being examined is a detached Head pointing to commit 'ef8826e'. 
Without a proper branch name GitVersion cannot determine the build version.

This is the script I use now:

  script:
    - git status
    - git branch -vv
    - git fetch --unshallow || true
    - git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
    - git fetch origin
    - git branch master origin/master || true
    - printf "$GITVERSIONCONFIG" > GitVersion.yml
    - docker run --rm -v "$(pwd):/repo" gittools/gitversion:5.1.4-linux /repo /showvariable SemVer | tee version.txt

And for the sake of completeness, this is the content of GitVersion.yml:

mode: ContinuousDeployment
branches: {}
ignore:
  sha: []

[asbjornu]

Is the Git_Branch environment variable passed on to GitVersion in this case, @m-jepson, so GitVersion knows which branch is being built?

[m-jepson]

I tried adding it, it is now set to the branch name, using -e Git_Branch='branchname' (in the case of building a specific tag, it is set to the tag). Same error while building for tag "1.2.4".
I've also tried GIT_BRANCH with the same result.

[m-jepson]

New discovery, if I reset the master branch to the commit, using git branch -f master <commit> and then git checkout master it works. Of course this will only work if the tag was actually put on the master branch.

[m-jepson]

My Full script is now:

  script:
    - git status
    - git branch -vv
    - git fetch --unshallow || true
    - git config remote.origin.fetch "+refs/heads/*:refs/remotes/origin/*"
    - git fetch origin
    - git branch master origin/master || true
    - '[ -z "$CI_COMMIT_BRANCH" ] && { git branch -f master $CI_COMMIT_SHA; git checkout master; }'
# And now we can get the version
    - printf "$GITVERSIONCONFIG" > GitVersion.yml
    - docker run --rm -v "$(pwd):/repo" -e GIT_BRANCH="$GIT_BRANCH" gittools/gitversion:5.1.4-linux-ubuntu-18.04-netcoreapp3.1 /repo /showvariable SemVer | tee version.txt

If we're building for a tag, $CI_COMMIT_BRANCH is null. $CI_COMMIT_TAG is actually filled in that case.

[asbjornu]

If GIT_BRANCH is set, you can do git branch -f $GIT_BRANCH <commit> to always checkout the branch being built, no?

[bendoyon]

@m-jepson Did you manage to get this working? I'm experiencing the same issue.

[georghirn]

I had similar problems with the GitLab CI. I solved it by using the Dynamic Repository feature of GitVersion:

> docker run --rm -v"$(pwd):/repo" gittools/gitversion:5.1.3-linux-ubuntu-18.04-netcoreapp3.1
    /repo
    /url ${CI_REPOSITORY_URL}
    /b ${CI_COMMIT_REF_NAME}
    /c ${CI_COMMIT_SHA}

This works just fine for me.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.