“Git fatal: ref HEAD não é um ref simbólico” ao usar o plugin de lançamento do maven


104

Recebo a seguinte saída de erro ao executar a etapa de preparação do plug-in de versão Maven, ou seja, mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -Xde um plano Atlassian Bamboo. No entanto, fazer o mesmo na linha de comando funciona bem. A pilha de erros completa está abaixo.

Alguma ideia de como isso pode ser resolvido?

[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

ATUALIZAR:

Fazer git ls-remote .em um clone de espaço de trabalho local produz:

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

Fazer git ls-remote .no clone Bamboo produz:

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

e isso é muito estranho, por que a saída do clone de desenvolvimento local é tão diferente da do Bamboo?


4
Ok, então o problema aqui é que o check-out no Bamboo está em um estado de "CABEÇA separada". Parece que o Maven está tentando analisar o nome do branch atual e falha porque no estado HEAD desanexado, o HEADref não se refere mais a um nome de branch, mas a um SHA1. Você pode simular este localmente, executando git checkout SHA1ou anexar ^{}ao nome de um ref: git checkout HEAD^{}. Parece que o plugin Bamboo git tenta fazer o checkout do branch, se possível. Portanto, parece que você tem uma corrida: antes que a construção seja executada, novas coisas apareceram. Ainda não está claro para mim como consertar.
John Szakmeister

Respostas:


153

Encontrei o mesmo erro no Jenkins em combinação com o plugin de lançamento do maven, nós o corrigimos indo para Comportamentos adicionais, Check-out para branch local específico e digite 'master'

Sei que não é uma solução, mas pode lhe dar alguma direção sobre onde procurar.


3
Funciona quando você está construindo a partir do branch master. Se o seu branch for diferente, mesmo depois de mudá-lo para um nome de branch específico, não funciona.
siddhusingh

29
Estou em um ramo diferente do master e funciona também. Acho que o problema é que o plugin jenkins git normalmente verifica o branch no estado principal separado. Portanto, o git symbolic-refcomando falha. Ao adicionar Check out to specific local branch, corrigimos isso.
René Link

16
Usar em **vez de masterirá combinar o nome do branch local com o remoto.
neXus

1
De acordo com help ( Git Plugin - Jenkins - Jenkins Wiki ), deixar o campo vazio também pode funcionar para isso: "Se selecionado, e seu valor é uma string vazia ou **, então o nome do branch é calculado a partir do branch remoto sem a origem . "
evgeny9 de

@jvwilge No meu caso, é um pipeline compartilhado, então todas as configurações vêm de pom.xml. como faço para escrever no código esta instrução: Comportamentos adicionais, verifique a ramificação local específica e digite 'master'
arielma

31

Para Jenkins e GIT, adicione o comportamento adicional check out to specific local branche use o Workspace Cleanup Pluginpara limpar seu espaço de trabalho até o início de seu trabalho de CI.


1
obrigado, isso funcionou para mim. Eu precisava adicionar -Darguments="-Dmaven.deploy.skip=true"também.
timbru31

@toschneck Oi, estou tendo exatamente esse problema ao usar Jenkins e Git. Você poderia expandir sua resposta aqui para incluir os comandos e configurações para o plugin que você mencionou. Obrigado.
Jeremy

Qual é a razão para limpar adicionalmente o espaço de trabalho?
kap

Atualmente, mudei para o plugin maven-jgitflow. Ele oferece suporte à ramificação de recursos e correções de bugs e tem a melhor funcionalidade de lançamento que já vi. bitbucket.org/atlassian/jgit-flow/wiki/Home
toschneck

Adicionar "check-out em filial local específica" também funciona para mim.
johnlinp

11

O problema no Atlassian Bamboo foi resolvido desmarcando a configuração padrão Use shallow clonescom a descrição Fetches the shallowest commit history possible. Do not use if your build depends on full repository history. Esta caixa de seleção está localizada em Plan Configuration -> guia Repositories -> Git -> Advanced options

Depois disso, todos os lançamentos funcionam bem.


5

Desmarcar Use shallow clonesnão foi suficiente no meu caso (estou usando o Bamboo 5.7.2). Também precisei habilitar Force Clean Buildna tarefa Check-out do código-fonte. A ativação de Use shallow clonesfuncionaria para a próxima execução da tarefa, mas todas as execuções subsequentes resultariam no mesmo erro.


4

Eu vi esse problema no Bamboo usado com o plug-in Maven Release. Eu corrigi isso habilitando a opção 'Forçar compilação limpa' na tarefa 'Verificação de código-fonte'. Bamboo diz que isso pode tornar a construção mais lenta, mas funciona e não vi nenhum aumento significativo no tempo.


Qual versão do Bamboo você usou? Eu tentei isso, mas não funcionou para mim naquela época.
SkyWalker

1
Estou usando o 5.3 build 4101 - 09, 13 de dezembro
zakmck

3

Estou usando um projeto de equipe Jenkins com uma configuração de projeto multibranch.

Eu usei o checkout scmcomando anteriormente .

Agora estou usando o seguinte código:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])

1
Deu um voto positivo, pois parecia funcionar. Mas depois de mais alguns ajustes, percebi que ele na verdade criou um novo branch chamado "novo" (ao usar o plugin de lançamento do maven). Uma abordagem mais correta seria mudar newcom **, o que torna o nome da filial local igual ao remoto.
Tobb

3

o que funcionou para mim foi chamar "git checkout -f master" antes de chamar "mvn release"


0

Para nós, o problema era com a versão do maven especificada no arquivo pom. Corrigida a versão do maven especificada no arquivo pom de acordo com a do bamboo corrigiu o problema


0

Para ações do GitHub, você pode configurar actions/checkout@v2comref: master

steps:
  - uses: actions/checkout@v2
    with:
      ref: master
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.