«Git fatal: ref HEAD не является символической ссылкой» при использовании плагина выпуска maven

105

Я получаю следующий вывод ошибки при выполнении этапа подготовки плагина выпуска Maven, то есть mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -Xиз плана Atlassian Bamboo. Однако то же самое в командной строке работает нормально. Полный стек ошибок приведен ниже.

Есть идеи, как это можно решить?

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project hpcmom: An error is occurred in the checkin process: Exception while executing SCM command. Detecting the current branch failed: fatal: ref HEAD is not a symbolic ref -> [Help 1]
    org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.4.2:prepare (default-cli) on project hpcmom: An error is occurred in the checkin process: Exception while executing SCM command.
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
    at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
    at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException: An error is occurred in the checkin process: Exception while executing SCM command.
    at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:281)
    at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:232)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 19 more
Caused by: org.apache.maven.shared.release.ReleaseExecutionException: An error is occurred in the checkin process: Exception while executing SCM command.
    at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:160)
    at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.performCheckins(AbstractScmCommitPhase.java:145)
    at org.apache.maven.shared.release.phase.ScmCommitPreparationPhase.runLogic(ScmCommitPreparationPhase.java:76)
    at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.execute(AbstractScmCommitPhase.java:78)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:234)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:169)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:146)
    at org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:107)
    at org.apache.maven.plugins.release.PrepareReleaseMojo.prepareRelease(PrepareReleaseMojo.java:277)
    ... 22 more
Caused by: org.apache.maven.scm.ScmException: Exception while executing SCM command.
    at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:63)
    at org.apache.maven.scm.provider.git.AbstractGitScmProvider.executeCommand(AbstractGitScmProvider.java:291)
    at org.apache.maven.scm.provider.git.AbstractGitScmProvider.checkin(AbstractGitScmProvider.java:217)
    at org.apache.maven.scm.provider.AbstractScmProvider.checkIn(AbstractScmProvider.java:410)
    at org.apache.maven.shared.release.phase.AbstractScmCommitPhase.checkin(AbstractScmCommitPhase.java:156)
    ... 30 more
Caused by: org.apache.maven.scm.ScmException: Detecting the current branch failed: fatal: ref HEAD is not a symbolic ref

    at org.apache.maven.scm.provider.git.gitexe.command.branch.GitBranchCommand.getCurrentBranch(GitBranchCommand.java:147)
    at org.apache.maven.scm.provider.git.gitexe.command.checkin.GitCheckInCommand.createPushCommandLine(GitCheckInCommand.java:192)
    at org.apache.maven.scm.provider.git.gitexe.command.checkin.GitCheckInCommand.executeCheckInCommand(GitCheckInCommand.java:132)
    at org.apache.maven.scm.command.checkin.AbstractCheckInCommand.executeCommand(AbstractCheckInCommand.java:54)
    at org.apache.maven.scm.command.AbstractCommand.execute(AbstractCommand.java:59)
    ... 34 more
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
simple  02-Dec-2013 17:18:09    Failing task since return code of [/opt/dev/apache-maven/3.0.5//bin/mvn -Djava.io.tmpdir=/opt/atlassian/bamboo/5.2.1/temp/HPCMOM-RELEASE-JOB1 release:prepare --batch-mode -DignoreSnapshots=false -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -X] was 1 while expected 0

ОБНОВИТЬ:

Выполнение git ls-remote .клона локальной рабочей области дает:

azg@olympus:~/code/hpcmom$ git ls-remote .
7894eea08a0afecb99515d1339623be63a7539d4    HEAD
7894eea08a0afecb99515d1339623be63a7539d4    refs/heads/master
7894eea08a0afecb99515d1339623be63a7539d4    refs/remotes/origin/HEAD
7894eea08a0afecb99515d1339623be63a7539d4    refs/remotes/origin/master
6a7095b86cccdfd4b28e4dea633d0930809ae9ac    refs/tags/v1.0
1a53462b1ecf0abfea8245016304cda9c78b420d    refs/tags/v1.0^{}
5113a7cbcf35c47b680a9c36e15e5fa01ef1d2e6    refs/tags/v1.1
79a3073ecabe65d3c8051520f8007d9e49a65a06    refs/tags/v1.1^{}
a00249209597ea1214d80ee38f228c40db7022c2    refs/tags/v1.1.0
e892bce8d25d87368ab557fee0d30810bef7e31e    refs/tags/v1.1.0^{}
b491a312c39088533cb069e4ab1ae8a00d1f6bfe    refs/tags/v1.1.2
a3f7618dada7ed60d8190426152ffd90e0e40a86    refs/tags/v1.1.2^{}

Работа git ls-remote .с клоном Bamboo дает:

azg@olympus:/var/atlassian/application-data/bamboo/xml-data/build-dir/HPCMOM-RELEASE-JOB1$ git ls-remote .
2422ce066ac35dae3c54f1435ef8dae5008a9a14    HEAD
57c08d581c0fd9e788049733fbdc9c22b9a6ae00    refs/heads/master
57c08d581c0fd9e788049733fbdc9c22b9a6ae00    refs/remotes/origin/HEAD
57c08d581c0fd9e788049733fbdc9c22b9a6ae00    refs/remotes/origin/master
7539f9700d78a1b766fca7ed9f409914f1ea9d08    refs/tags/vnull
6bfa8c3fdb1f8f56a385035f01b1b77b6e88da8b    refs/tags/vnull^{}

и это очень странно, почему выходные данные клона локальной разработки так отличаются от клона Bamboo?

git maven release maven-release-plugin bamboo Ходящий по небу
источник
4
Итак, проблема в том, что оформление заказа в Bamboo находится в состоянии «отключенной HEAD». Похоже, что Maven пытается проанализировать текущее имя ветки и терпит неудачу, потому что в отключенном состоянии HEAD HEADссылка больше не ссылается на имя ветки, а на SHA1. Вы можете смоделировать это локально, запустив git checkout SHA1или добавление ^{}к имени исй: git checkout HEAD^{}. Похоже, плагин Bamboo git пытается проверить ветку, если это вообще возможно. Похоже, у вас гонка: перед запуском сборки появились новые вещи. Мне пока непонятно как исправить.
John Szakmeister
Возможный дубликат активной ветки Git - «(без ветки)» на Hudson CI
Альберто

Ответы:

156

Я столкнулся с той же ошибкой в ​​Jenkins в сочетании с плагином выпуска maven, мы исправили ее, перейдя в Дополнительные поведения, проверьте конкретную локальную ветвь и введите `` master ''

Я понимаю, что это не решение, но это может дать вам какое-то направление, где искать.

jvwilge
источник
4
Это работает, когда вы строите из основной ветки. Если ваша ветка отличается, даже после изменения ее на конкретное имя ветки, она не работает.
siddhusingh 05
29
Я нахожусь в другой ветке, чем мастер, и это тоже работает. Я думаю, проблема в том, что плагин jenkins git обычно проверяет ветку в состоянии отдельной головы. Итак, git symbolic-refкоманда не работает. Добавив Check out to specific local branchмы исправим это.
Рене Линк
16
Использование **вместо masterсопоставит имя локальной ветки с удаленным.
neXus
1
Согласно справке ( подключаемый модуль Git - Jenkins - Jenkins Wiki ), оставление поля пустым может работать и для этого: «Если выбрано, и его значение представляет собой пустую строку или **, то имя ветки вычисляется из удаленной ветки без источника. . "
evgeny9
@jvwilge В моем случае это общий конвейер, поэтому все настройки берутся из pom.xml. как мне написать в коде эту инструкцию: Дополнительное поведение, Отъезд в конкретную локальную ветвь и введите «master»
Ариэльма
31

Для Jenkins и GIT добавьте дополнительное поведение check out to specific local branchи используйте Workspace Cleanup Pluginдля очистки рабочего пространства в начале задания CI.

Toschneck
источник
1
спасибо, это сработало для меня. Мне тоже нужно было добавить -Darguments="-Dmaven.deploy.skip=true".
timbru31 08
@toschneck Привет, у меня именно такая проблема с Jenkins и Git. Не могли бы вы расширить свой ответ здесь, включив в него команды и конфигурацию для упомянутого плагина. Спасибо.
Джереми
Зачем дополнительно убирать рабочее место?
kap
В настоящее время я перешел к плагину maven-jgitflow. Он поддерживает ветвление функций и исправлений и обладает лучшими функциональными возможностями, которые я когда-либо видел. bitbucket.org/atlassian/jgit-flow/wiki/Home
toschneck
Добавление «выписки в конкретную локальную ветку» тоже работает для меня.
johnlinp
11

Проблема в Atlassian Bamboo была решена путем снятия флажка по умолчанию Use shallow clonesс описанием Fetches the shallowest commit history possible. Do not use if your build depends on full repository history. Этот флажок находится в разделе «Конфигурация плана» -> вкладка «Репозитории» -> «Git» -> «Дополнительные параметры».

После этого все релизы работают нормально.

Ходящий по небу
источник
5

В Use shallow clonesмоем случае снятия флажка было недостаточно (я использую Bamboo 5.7.2). Мне также нужно было включить Force Clean Buildзадачу проверки исходного кода. Включение Use shallow clonesсработает для следующего выполнения задания, но все последующее выполнение приведет к той же ошибке.

Жан Маруа
источник
4

Я видел эту проблему при использовании Bamboo с плагином Maven Release. Я исправил это, включив опцию «Force Clean Build» в задаче «Source Checkout». Bamboo говорит, что это может замедлить сборку, но это работает, и я не заметил значительного увеличения времени.

Закмц
источник
Какую версию Bamboo вы использовали? Я пробовал это, но тогда у меня это не сработало.
SkyWalker
1
Я использую 5.3 build 4101 - 09 декабря 13
zakmck
3

Я использую проект Jenkins Team с настройкой многоотраслевого проекта.

Я раньше использовал checkout scm команду.

Сейчас я использую следующий код:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])
kevcodez
источник
1
Проголосовал за это, поскольку, похоже, это помогло. Но, немного поработав, я заметил, что он фактически создал новую ветку под названием «новая» (при использовании с плагином выпуска maven). Более правильным подходом было бы изменение newс помощью **, при котором имя локальной ветки совпадает с именем удаленной.
Tobb
3

что сработало для меня, так это вызвать «git checkout -f master» перед вызовом «mvn release»

Винсент Ф
источник
1

Для действий GitHub вы можете настроить actions/checkout@v2с помощьюref: master

steps:
  - uses: actions/checkout@v2
    with:
      ref: master
РекуэнкоДжонс
источник
0

Для нас проблема была в версии maven, указанной в pom-файле. Исправлена ​​версия maven, указанная в файле pom, в соответствии с версией в bamboo, исправлена ​​проблема

Ману
источник