Can some "GIT guru" please have a short look here?
We use jenkins CI for simple deployments. Most jobs make use of the "GIT plugin", and there is some issue with this. Even, if we set the plugin to track the "master" branch. At some point we end up to have a "detached state" in the build directory.
like this.
root@jinx [...]/workspace/build # git branch -a
* (detached from 12dbf9b)
remotes/origin/dev
remotes/origin/master
The build process does not report an error. This is the log from GIT plugin.
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url [email protected]:q3i/our-repo.git # timeout=10
Fetching upstream changes from [email protected]:q3i/our-repo.git
> git --version # timeout=10
> git fetch --tags --progress [email protected]:q3i/our-repo.git +refs/heads/master:refs/remotes/origin/master
> git rev-parse origin/master^{commit} # timeout=10
Checking out Revision 12dbf9b8eb8fd71580f874ae963162f72221e577 (origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 12dbf9b8eb8fd71580f874ae963162f72221e577
> git rev-list 58f1f1ae97628a0b5f2d5e3090a24416c7952f0e # timeout=10
I see that the detached commit 12dbf9b is in fact the HEAD. Is it an expected state, what might be the advantage of this form the perspective of jenkins GIT plugin?
Thank you for some new GIT knowledge :-)
It's hard to say if this is expected without seeing your Jenkins configuration, but all this really means is that Git checked out a specific commit directly rather than by a branch name, so there's nothing inherently good or bad about this situation. Depending on what plugins you're running and how they're configured, this may or may not be normal.