checking out a detached head causes errors

[shillner]

As reported in the unleash-maven-plugin (issue 47)

releases are failing in jenkins and i believe the cause is related to jenkins checking things out in a detached state. i currently set the option to check out to a specific local branch (this is also required by the maven-release-plugin to work properly) but the plugin does not seem to notice this.

from the logs:

[DEBUG] 14:00:01,078 Git - Push info:

• WORKING_DIR: /var/lib/jenkins/jobs/hello-world-jenkins/workspace
• LOCAL_BRANCH: master
• REMOTE_BRANCH: null
• REMOTE: origin
• REMOTE_URL: git@github.com:condevops/hello-world-jenkins.git
• MERGE_STRATEGY: FULL_MERGE

this can be reproduced locally be executing the same steps jenkins does on a check out.

i am currently digging into this and will hopefully have a fix soon but there will be no complaints from me if you beat me to it.

[shillner]

If you plan to fix/implement some stuff, please be patient when sending a PR. I'm heading into vacation tomorrow and am away for the next two weeks.

[jgangemi]

cool - enjoy!

[shillner]

I did some investigation today and I saw that Jenkins checks out in detached HEAD since it does not checkout a branch but the HEAD commit of the remote branch, as we already know ;)

Ok, there is now the option to configure the checkout into a specific local branch which creates a local branch instead. But the repository config is still missing the branch section containing the remote and merge info of this specific branch. The config looks like this:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://github.com/shillner/test-repo.git
        fetch = +refs/heads/*:refs/remotes/origin/*

But it should look like this:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        url = https://github.com/shillner/test-repo.git
        fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
        remote = origin
        merge = refs/heads/master

I can surely do some weired magic to determine the remote branch name if I assume some things and use some fallback strategies but that is not satisfying! Are there other ideas how to resolve the remote branch name? I wonder how the release plugin is able to push here since I'm not able to push via command line in such a case without setting the upstream branch for the local one.

[jgangemi]

the maven-release-plugin does the same thing and requires you to use the check out to a local branch option in jenkins.

i think the same should be applied here and jenkins should pass the value down into the plugin in some fashion.

[shillner]

I'm not sure if the Jenkins plug-in of the release plug-in passes this value to the Maven plug-in but I will have a look at it. Another option could be to simply fix the config before starting the release build. I will try and report. Freitag, 23 September 2016, 03:38nachm. +02:00 von Jae Gangemi notifications@github.com :

the maven-release-plugin does the same thing and requires you to use the check out to a local branch option in jenkins. i think the same should be applied here and jenkins should pass the value down into the plugin in some fashion. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub , or mute the thread .

[jgangemi]

this is the output from the jenkins job i just ran re: the checkout

git rev-parse --is-inside-work-tree # timeout=104
Fetching changes from the remote Git repository
git config remote.origin.url git@github.com:condevops/hello-world-jenkins.git # timeout=10
Cleaning workspace
git rev-parse --verify HEAD # timeout=10
Resetting working tree
git reset --hard # timeout=10
git clean -fdx # timeout=10
Fetching upstream changes from git@github.com:condevops/hello-world-jenkins.git
git --version # timeout=10
git -c core.askpass=true fetch --tags --progress git@github.com:condevops/hello-world-jenkins.git refs/heads/master
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 7e96dbe3450cbf54edecb0e914ccc67fa1dfd271 (refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f 7e96dbe3450cbf54edecb0e914ccc67fa1dfd271
git branch -a -v --no-abbrev # timeout=10
git branch -D master # timeout=10
git checkout -b master 7e96dbe3450cbf54edecb0e914ccc67fa1dfd271
git rev-list 7e96dbe3450cbf54edecb0e914ccc67fa1dfd271 # timeout=10

can you detect that it's a detached head or does checking out to a local branch make that not work? if you can and see the remote is empty, use whatever the local is.

[shillner]

Can anyone reproduce this behavior when checking out locally? I tried to reproduce this on my machine by performing the above steps (as in my jenkins logs) but in contrast to the working directory on jenkins I was able to push from my local working directory.

It's weired because now there is not only the question how to solve it but also why am I able to push when checking out in exactly the same way.

[shillner]

Ok, finally I found the cause which was the push.default being set to matching on my local machine while this config option has still the default value (simple) on the jenkins machine. This causes git to automatically push to the remote branch with the same name on my local machine.

Now I am able to reproduce the error and fix it ;) I'll be back soon, hopefully with a solution!

[jgangemi]

i still think you should mimic how the release plugin works here by having the user check out to a local named branch and figure out how to map that name to the upstream

[shillner]

I know how it works there and this is no option for me. The release plugin doesn't work on the local working copy but checks out a fresh copy into the target folder. This way they don't have such a problem when pushing to the remote but this implies some other drawbacks such as a longer release build, ... I'm currently working on the solution and saw that my implementation was simply short-minded. I'm not sure when I can push it since some other projects currently require some more effort but I think until next week it should be ready.

[jgangemi]

but jenkins still checks out in a detached head state no matter what, so how is it ever going to know what branch it should push back to?

wouldn't checking out to a named local branch still solve this problem? you potentially just need to figure out what the local branch name is and tie that to the remote or is that just too simplistic and not how git will work?

[shillner]

Fixed this issue but it works only if a local branch is checked out which is named as the remote branch. Detached head mode is still not possible but I will try to fix this when refactoring the provider. Refactoring is absolutely necessary and scheduled for the near future (#3) (when there is a bit more time).

On Jenkins the new provider version (2.0.1) requires to setup the additional behavior Check out to specific local branch at the git connector setup. The local branch must be named as the remote one!

[jgangemi]

yeah - that works for me. it's the same setup that the release plugin uses which means i can seamlessly switch between the two for now.