„Git fatal: ref HEAD nie jest symbolicznym odniesieniem” podczas korzystania z wtyczki Maven Release

104

Otrzymuję następujący komunikat o błędzie podczas uruchamiania wtyczki do wydania Maven, przygotowując krok, np. mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -XZ planu Atlassian Bamboo. Jednak zrobienie tego samego w wierszu poleceń działa dobrze. Pełny stos błędów znajduje się poniżej.

Jakieś pomysły, jak można to rozwiązać?

[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

AKTUALIZACJA:

Wykonanie git ls-remote .na klonie lokalnego obszaru roboczego daje:

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

Wykonanie git ls-remote .klonu Bamboo daje:

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

i to jest bardzo dziwne, dlaczego klon rozwoju lokalnego jest tak różny od klonu Bamboo?

git maven release maven-release-plugin bamboo SkyWalker
źródło
4
OK, problem polega na tym, że kasowanie pod Bamboo jest w stanie „odłączonej głowy”. Wygląda na to, że Maven próbuje przeanalizować nazwę bieżącej gałęzi i kończy się niepowodzeniem, ponieważ w odłączonym stanie HEAD HEADodwołanie nie odnosi się już do nazwy gałęzi, ale do SHA1. Można symulować to lokalnie poprzez uruchomienie git checkout SHA1lub dodanie ^{}do nazwy ref: git checkout HEAD^{}. Wygląda na to, że wtyczka Bamboo git próbuje pobrać gałąź, jeśli to w ogóle możliwe. Wygląda więc na to, że masz wyścig: przed uruchomieniem kompilacji pojawiły się nowe rzeczy. Nie jest jeszcze dla mnie jasne, jak to naprawić.
John Szakmeister
Możliwy duplikat gałęzi Active Git to „(no branch)” w hudson CI
Alberto

Odpowiedzi:

153

Napotkałem ten sam błąd na Jenkinsie w połączeniu z wtyczką do wydania maven, naprawiliśmy go, przechodząc do Dodatkowe zachowania, Sprawdź w konkretnym lokalnym oddziale i wpisz `` master ''

Zdaję sobie sprawę, że to nie jest rozwiązanie, ale może dać ci wskazówki, gdzie szukać.

jvwilge
źródło
3
Działa, gdy budujesz z gałęzi głównej. Jeśli twoja gałąź jest inna, nawet po zmianie jej na konkretną nazwę oddziału, to nie działa.
siddhusingh
29
Jestem na innej gałęzi niż master i to też działa. Myślę, że problem polega na tym, że wtyczka Jenkinsa normalnie sprawdza gałąź w stanie odłączonej głowy. Więc git symbolic-refpolecenie zawodzi. Dodając Check out to specific local branch, naprawiamy to.
René Link
16
Użycie **zamiast masterspowoduje dopasowanie nazwy lokalnego oddziału do zdalnego.
neXus
1
Zgodnie z help ( Git Plugin - Jenkins - Jenkins Wiki ), pozostawienie pustego pola również może zadziałać: "Jeśli zaznaczone, a jego wartością jest pusty ciąg lub **, wówczas nazwa gałęzi jest obliczana ze zdalnej gałęzi bez źródła . ”
evgeny9
@jvwilge W moim przypadku jest to wspólny potok, więc wszystkie ustawienia pochodzą z pom.xml. jak mam napisać w kodzie tę instrukcję: Dodatkowe zachowania, Sprawdź w konkretnym lokalnym oddziale i wpisz „master”
arielma
31

W przypadku Jenkins i GIT dodaj dodatkowe zachowanie check out to specific local branchi użyj Workspace Cleanup Plugindo wyczyszczenia obszaru roboczego na początku zadania CI.

toschneck
źródło
1
dzięki, to zadziałało dla mnie. Ja też musiałem to dodać -Darguments="-Dmaven.deploy.skip=true".
timbru31
@toschneck Cześć, mam dokładnie ten problem przy użyciu Jenkinsa i Gita. Czy mógłbyś rozszerzyć swoją odpowiedź tutaj, tak aby zawierała polecenia i konfigurację wspomnianej wtyczki. Dzięki.
Jeremy
Jaki jest powód dodatkowego czyszczenia obszaru roboczego?
kap
Obecnie przeszedłem dalej do wtyczki maven-jgitflow. Obsługuje rozgałęzianie funkcji i poprawek błędów i ma najlepszą funkcjonalność wydania, jaką widziałem. bitbucket.org/atlassian/jgit-flow/wiki/Home
toschneck
Dodanie „wyewidencjonuj do określonego lokalnego oddziału” też działa.
johnlinp
11

Problem w Atlassian Bamboo został rozwiązany poprzez odznaczenie domyślnego ustawienia Use shallow clonesz opisem Fetches the shallowest commit history possible. Do not use if your build depends on full repository history. To pole wyboru znajduje się w Konfiguracja planu -> zakładka Repozytoria -> Git -> Opcje zaawansowane

Po tym wszystkie wydania działają dobrze.

SkyWalker
źródło
5

Odznaczenie Use shallow clonesnie było wystarczające w moim przypadku (używam Bamboo 5.7.2). Musiałem również włączyć Force Clean Buildw zadaniu Checkout kodu źródłowego. Włączenie Use shallow clonesbędzie działało przy następnym wykonaniu zadania, ale wszystkie kolejne wykonania spowodują ten sam błąd.

Jean Marois
źródło
4

Widziałem ten problem pod Bamboo używanym z wtyczką Maven Release. Naprawiłem to, włączając opcję „Wymuś czystą kompilację” w zadaniu „Source Checkout”. Bamboo twierdzi, że może to spowolnić kompilację, ale działa i nie widziałem żadnego znaczącego wydłużenia czasu.

zakmck
źródło
Z której wersji Bamboo korzystałeś? Próbowałem tego, ale wtedy to nie działało.
SkyWalker,
1
Używam wersji 5.3
4101-09
3

Używam projektu zespołowego Jenkins z konfiguracją projektu wielobranżowego.

Wcześniej użyłem checkout scmpolecenia.

Teraz używam następującego kodu:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])
kevcodez
źródło
1
Głosował za tym, ponieważ wydawało się, że to załatwia sprawę. Ale po kilku dalszych próbach zauważyłem, że w rzeczywistości utworzono nową gałąź o nazwie „nowa” (w przypadku używania z wtyczką do wydania maven). Bardziej poprawnym podejściem byłaby zmiana za newpomocą **, co powoduje, że nazwa oddziału lokalnego jest taka sama jak nazwa zdalnego.
Tobb
3

zadziałało dla mnie wywołanie „git checkout -f master” przed wywołaniem „mvn release”

Vincent F.
źródło
0

U nas problem dotyczył wersji mavena określonej w pliku pom. Poprawiono wersję Mavena określoną w pliku pom zgodnie z wersją w bambusie. Naprawiono problem

Manu
źródło
0

W przypadku akcji GitHub, które możesz skonfigurować za actions/checkout@v2pomocąref: master

steps:
  - uses: actions/checkout@v2
    with:
      ref: master
RecuencoJones
źródło