Не могли бы вы взглянуть на "гуру GIT", пожалуйста, здесь?
Мы используем jenkins CI для простых развертываний. В большинстве вакансий используется «плагин GIT», и с этим есть некоторая проблема. Даже если мы настроим плагин на отслеживание «основной» ветки. В какой-то момент у нас появляется «отключенное состояние» в каталоге сборки.
как это.
root@jinx [...]/workspace/build # git branch -a
* (detached from 12dbf9b)
remotes/origin/dev
remotes/origin/master
Процесс сборки не сообщает об ошибке. Это журнал из плагина GIT.
> 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
Я вижу, что отдельный коммит 12dbf9b на самом деле является ГОЛОВКОЙ. Это ожидаемое состояние, в чем может быть преимущество этой формы с точки зрения плагина jenkins GIT?
Спасибо за новые знания GIT :-)
Трудно сказать, ожидается ли это, не увидев вашу конфигурацию Jenkins, но на самом деле все это означает, что Git проверил конкретную фиксацию напрямую, а не по имени ветки, поэтому нет ничего по своей сути хорошо или плохо об этой ситуации. В зависимости от того, какие плагины вы используете и как они настроены, это может быть нормальным, а может и нет.