"Git fatal: ref HEAD no es una referencia simbólica" al usar el complemento de lanzamiento de maven

104

Obtengo el siguiente resultado de error mientras ejecuto el paso de preparación del complemento de lanzamiento de Maven, es decir, mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -Xdesde un plan de Atlassian Bamboo. Sin embargo, hacer lo mismo en la línea de comandos funciona bien. La pila de errores completa está a continuación.

¿Alguna idea de cómo se puede resolver esto?

[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

ACTUALIZAR:

Hacerlo git ls-remote .en un clon de espacio de trabajo local produce:

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

Hacer git ls-remote .en el clon de Bamboo produce:

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

y esto es muy extraño, ¿por qué la salida del clon de desarrollo local es tan diferente de la de Bamboo?

git maven release maven-release-plugin bamboo Andante del cielo
fuente
4
Bien, entonces el problema aquí es que la caja en Bamboo está en un estado de "CABEZA separada". Parece que Maven está tratando de analizar el nombre de la rama actual y falla porque en el estado HEAD separado, la HEADreferencia ya no se refiere a un nombre de rama, sino a SHA1. Puede simular este localmente mediante la ejecución git checkout SHA1o de agregar ^{}al nombre de un ref: git checkout HEAD^{}. Parece que el complemento Bamboo git intenta verificar la rama, si es posible. Entonces parece que tienes una carrera: antes de que se ejecute la compilación, han aparecido cosas nuevas. Aún no tengo claro cómo solucionarlo.
John Szakmeister
El posible duplicado de la rama Active Git es "(sin rama)" en hudson CI
Alberto

Respuestas:

153

Me encontré con el mismo error en Jenkins en combinación con el complemento de lanzamiento de maven, lo solucionamos yendo a Comportamientos adicionales, consulte la rama local específica e ingrese 'maestro'

Me doy cuenta de que esto no es una solución, pero podría darle alguna dirección sobre dónde buscar.

jvwilge
fuente
3
Funciona cuando está construyendo desde la rama maestra. Si su rama es diferente, incluso después de cambiarla a un nombre de rama específico, no funciona.
siddhusingh
29
Estoy en una rama diferente a la del maestro y también funciona. Creo que el problema es que el complemento jenkins git normalmente verifica la rama en el estado principal separado. Entonces el git symbolic-refcomando falla. Añadiendo Check out to specific local brancharreglamos esto.
René Link
16
Usar en **lugar de masterhará coincidir el nombre de la sucursal local con la remota.
neXus
1
Según la ayuda ( Git Plugin - Jenkins - Jenkins Wiki ), dejar el campo vacío también puede funcionar para esto: "Si se selecciona, y su valor es una cadena vacía o **, entonces el nombre de la rama se calcula desde la rama remota sin el origen . "
evgeny9
@jvwilge En mi caso, es una canalización compartida, por lo que todas las configuraciones provienen de pom.xml. ¿Cómo escribo en el código esta instrucción? Comportamientos adicionales,
consulte
31

Para Jenkins y GIT, agregue el comportamiento adicional check out to specific local branchy use Workspace Cleanup Pluginpara limpiar su espacio de trabajo al comienzo de su trabajo de CI.

toschneck
fuente
1
gracias, esto funcionó para mí. Yo también necesitaba agregar -Darguments="-Dmaven.deploy.skip=true".
timbru31
@toschneck Hola, tengo este problema exacto con Jenkins y Git. ¿Podría expandir su respuesta aquí para incluir los comandos y la configuración para el complemento que mencionó? Gracias.
Jeremy
¿Cuál es la razón para limpiar adicionalmente el espacio de trabajo?
kap
Actualmente me mudé más al complemento maven-jgitflow. Es compatible con la ramificación de funciones y corrección de errores y tiene la mejor funcionalidad de lanzamiento que he visto. bitbucket.org/atlassian/jgit-flow/wiki/Home
toschneck
Agregar "check out a una sucursal local específica" también funciona para mí.
johnlinp
11

El problema en Atlassian Bamboo se resolvió desmarcando la configuración predeterminada Use shallow clonescon descripciónFetches the shallowest commit history possible. Do not use if your build depends on full repository history . Esta casilla de verificación se encuentra en Configuración del plan -> pestaña Repositorios -> Git -> Opciones avanzadas

Después de esto, todos los lanzamientos funcionan bien.

Andante del cielo
fuente
5

Desmarcar Use shallow clonesno fue suficiente en mi caso (estoy usando Bamboo 5.7.2). Necesitaba habilitar también Force Clean Builden la tarea de verificación de código fuente. Habilitar Use shallow clonesfuncionaría para la siguiente ejecución del trabajo, pero todas las ejecuciones posteriores darían como resultado el mismo error.

Jean Marois
fuente
4

He visto este problema en Bamboo utilizado con el complemento Maven Release. Lo solucioné habilitando la opción 'Forzar construcción limpia' en la tarea 'Comprobación de origen'. Bamboo dice que esto podría hacer que la construcción sea más lenta, pero funciona y no vi ningún aumento de tiempo significativo.

zakmck
fuente
¿Qué versión de Bamboo usaste? Intenté esto pero no funcionó para mí en ese entonces.
SkyWalker
1
Estoy usando la compilación 5.3
4101-09
3

Estoy usando un proyecto de equipo de Jenkins con una configuración de proyecto de múltiples ramas.

Anteriormente usé el checkout scmcomando.

Ahora estoy usando el siguiente código:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])
kevcodez
fuente
1
Le di a esto un voto a favor, ya que parecía funcionar. Pero después de algunos retoques más, noté que en realidad creaba una nueva rama llamada "nueva" (cuando se usa con el complemento de lanzamiento de maven). Un enfoque más correcto sería cambiar newcon **, lo que hace que el nombre de la sucursal local sea el mismo que el de la remota.
Tobb
3

lo que funcionó para mí fue llamar "git checkout -f master" antes de llamar a "mvn release"

Vincent F
fuente
0

Para nosotros, el problema fue con la versión de maven especificada en el archivo pom. Se corrigió la versión de maven especificada en el archivo pom de acuerdo con la de bambú solucionó el problema

Manu
fuente
0

Para las acciones de GitHub que puede configurar actions/checkout@v2conref: master

steps:
  - uses: actions/checkout@v2
    with:
      ref: master
RecuencoJones
fuente