2

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 git@our.gitlab.server:q3i/our-repo.git # timeout=10
Fetching upstream changes from git@our.gitlab.server:q3i/our-repo.git
 > git --version # timeout=10
 > git fetch --tags --progress git@our.gitlab.server: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 :-)

Artur Cichosz
  • 165
  • 7
  • "detached head" is a state where you are at a commit without a branch name or tag attached to it. This means two things: you have no way to reach it if you do not remember its commit ID (which is not fun) and that it might gets garbage collected at some point, meaning you will loose this commit (and its ancestors back to a fork point). HEAD is always a symbolic link to your current commit ID. – Patrick Mevzek Feb 10 '18 at 17:27
  • Thx Patrick. My question is more: Is it intentionally a detached state (from the view of jenkins git plugin)? In other words - is ot OK like this and I do not need to bother, or is it because of some problems which may leed to inconsistent code state beeing deployed? – Artur Cichosz Feb 12 '18 at 08:44
  • @PatrickMevzek "detached head" does mean that the commit does not have a branch name or tag pointing to it, but it does *not* mean that there is no way to reach the commit without its hash nor that the commit is marked for garbage collection. I believe you are confusing detached heads with orphan commits. – jayhendren Feb 13 '18 at 22:03
  • @jayhendren how do you access it without knowing its id? but yes, depending which commit ID it is it might or might not get garbage collected (it will if it is not in a stream what is finally merged in some branch, it will not if it is any arbitrary commit id back in history in any branch) – Patrick Mevzek Feb 13 '18 at 22:09
  • @PatrickMevzek one way would be to use `^` syntax, for instance: `git checkout master^1` will check out the parent commit of the master branch. – jayhendren Feb 13 '18 at 22:12
  • @ArturCichosz I understand, it is just that I know Jenkins very little so I had the same opinion as jayhendren basically no idea if it has bad impact or not. See also https://stackoverflow.com/questions/11511390/jenkins-git-plugin-detached-head#15829994 and https://issues.jenkins-ci.org/browse/JENKINS-6856 – Patrick Mevzek Feb 13 '18 at 22:12
  • @jayhendren this means you know the commit position relative to any other references (relative position, so as soon as master advances by one commit, `master^1` does not point anymore to the same commit), which is as hard as memorizing its ID... so it is possible in theory, not really in practice. and I had more in fact in mind the case of a separate branch that gets deleted (its reference) – Patrick Mevzek Feb 13 '18 at 22:14
  • I was facing the exact same issue, resolved it by following this -> https://stackoverflow.com/a/44023516/8343888 – Tarun Chawla May 28 '19 at 10:23

1 Answers1

2

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.

jayhendren
  • 1,014
  • 5
  • 12