0

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 :-)

  • "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 8: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
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.