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

Improve this question
8
  • "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, 2018 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, 2018 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, 2018 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, 2018 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, 2018 at 22:12

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .