"Git fatal: ref HEAD - це не символічна спроба", використовуючи плагін Maven release

104

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

Будь-які ідеї, як це можна вирішити?

[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 .на клоні Бамбук:

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^{}

і це дуже дивно, чому вихід клонів для місцевого розвитку настільки відрізняється від бамбукового?

git  maven  release  maven-release-plugin  bamboo 
— SkyWalker
джерело
4
Гаразд, проблема тут полягає в тому, що каси під Бамбуком знаходяться в стані "відокремленої ГЛАВИ". Здається, що Maven намагається проаналізувати поточну назву гілки та не вдається, оскільки у відірваному стані HEAD HEADпосилання більше не стосується назви гілки, а SHA1. Ви можете змоделювати це локально, запустивши git checkout SHA1або додавання ^{}до імені ісй: git checkout HEAD^{}. Схоже, плагін Bamboo git намагається оформити відділення, якщо це можливо. Тож, здається, у вас гонка: перед тим, як збірка запущена, з'явилися нові речі. Мені поки не зрозуміло, як це виправити.
— Джон Сакмайстер
Можливий дублікат відділення Active Git - це "(без гілки)" на hudson CI
— Альберто,

Відповіді:

153

Я зіткнувся з такою ж помилкою на Jenkins у поєднанні з плагіном Maven release, ми виправили це, перейшовши на Додаткові форми поведінки, Перевірте конкретну локальну гілку та введіть "master"

Я усвідомлюю, що це не рішення, але це може дати вам певний напрямок, де шукати.

— jvwilge
джерело
3
Це працює, коли ви будуєте з головного відділення. Якщо ваша філія відрізняється, навіть після зміни її на конкретну назву гілки, вона не працює.
— siddhusingh
29
Я на іншій гілці, ніж майстер, і це теж працює. Я думаю, що проблема полягає в тому, що плагін jenkins git зазвичай перевіряє відділення у відокремленому стані. Отже git symbolic-refкоманда не вдається. Додавши Check out to specific local branchми це виправляємо.
— René Link
16
Використання **замість masterбуде відповідати назві локальної філії віддаленій.
— neXus
1
Відповідно до довідки ( Git Plugin - Jenkins - Jenkins Wiki ), якщо поле порожнє також може працювати для цього: "Якщо вибрано, а його значення - порожній рядок або **, тоді назва гілки обчислюється з віддаленої гілки без походження . "
— evgeny9
@jvwilge У моєму випадку це спільний конвеєр, тому всі налаштування надходять від pom.xml. як написати в коді цю інструкцію: Додаткові форми поведінки, Перевірте певну локальну гілку та введіть 'господар'
— арієльма
31

Для Дженкінса та GIT додайте додаткову поведінку check out to specific local branchта використовуйте Workspace Cleanup Pluginдля очищення робочої області на початку вашої роботи з ІС.

— toschneck
джерело
1
дякую, це працювало для мене. Мені теж потрібно було додати -Darguments="-Dmaven.deploy.skip=true".
— timbru31
@toschneck Привіт: У мене є ця проблема з використанням Jenkins та Git. Чи можете ви, будь ласка, розширити свою відповідь тут, щоб включити команди та конфігурацію для згаданого вами плагіна. Дякую.
— Джеремі
Що є причиною додаткового очищення робочої області?
— кап
В даний час я перейшов далі до плагіна maven-jgitflow. Він підтримує розгалуження функцій та помилок та має найкращу функціональність випуску, яку я бачив. bitbucket.org/atlassian/jgit-flow/wiki/Home
— toschneck
Додавання "перевірки до конкретного місцевого відділення" працює і для мене.
— Джонлінп
11

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

Після цього всі випуски працюють чудово.

— SkyWalker
джерело
5

Зніміть прапорець Use shallow clonesу моєму випадку недостатньо (я використовую Bamboo 5.7.2). Мені потрібно було також увімкнути Force Clean Buildзавдання завдання з вихідного коду. Увімкнення знаряддя Use shallow clonesбуде працювати для наступного виконання завдання, але все подальше виконання призведе до тієї ж помилки.

— Жан Маруа
джерело
4

Я бачив цю проблему під Bamboo, який використовується із плагіном Maven Release. Я виправив це, включивши опцію "Формувати чисту збірку" у завданні "Оплата замовлення". Бамбук каже, що це може зробити збір повільніше, але він працює, і я не бачив значного збільшення часу.

— закмк
джерело
Яку версію Bamboo ви використовували? Я спробував це, але тоді мені це не вийшло.
— SkyWalker
1
Я використовую 5.3 build 4101 - 09 грудня 13
— zakmck
3

Я використовую команду проекту Дженкінса з установкою багатогалузевого проекту.

Я раніше використовував checkout scmкоманду.

Зараз я використовую такий код:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])
— кевкодез
джерело
1
Дав цю нагоду, оскільки, здавалося, зробив свою справу. Але після ще декількох роздумів я помітив, що він фактично створив нову гілку під назвою "нова" (при використанні з плагіном Maven release). Більш правильний підхід був би зміна newз **, що робить місцева назва філії такими ж , як і пульт дистанційного керування.
— Тобб
3

що для мене працювало - зателефонувати "git checkout -f master" перед тим, як викликати "mvn release"

— Вінсент F
джерело
0

Для нас проблема була з версією Maven, вказаною у файлі pom. Виправлена ​​версія Maven, зазначена у файлі пом, відповідно до версії з бамбука, виправлена ​​проблема

— Ману
джерело
0

Для дій GitHub ви можете встановити actions/checkout@v2зref: master

steps:
  - uses: actions/checkout@v2
    with:
      ref: master
— RecuencoJones
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.