"Git fatal: ref HEAD n'est pas une référence symbolique" lors de l'utilisation du plugin de publication maven

104

J'obtiens la sortie d'erreur suivante lors de l'exécution de l'étape de préparation du plugin Maven, c'est- mvn release:prepare --batch-mode -DreleaseVersion=1.1.2 -DdevelopmentVersion=1.2.0-SNAPSHOT -Dtag=v1.1.2 -Xà- dire à partir d'un plan Atlassian Bamboo. Cependant, faire la même chose dans la ligne de commande fonctionne très bien. La pile d'erreurs complète est ci-dessous.

Des idées comment résoudre ce problème?

[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

METTRE À JOUR:

Faire git ls-remote .sur un clone d'espace de travail local produit:

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

Faire git ls-remote .sur le clone Bamboo produit:

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

et c'est très étrange pourquoi la sortie du clone de développement local est-elle si différente de celle de Bamboo?

git maven release maven-release-plugin bamboo SkyWalker
la source
4
Ok, donc le problème ici est que la caisse sous Bamboo est dans un état "HEAD détaché". Il semble que Maven essaie d'analyser le nom de la branche actuelle et échoue car dans l'état HEAD détaché, la HEADréférence ne fait plus référence à un nom de branche, mais à un SHA1. Vous pouvez simuler ce local en exécutant git checkout SHA1ou en ajoutant ^{}au nom d'une ref: git checkout HEAD^{}. Il semble que le plugin Bamboo git tente d'extraire la branche, si possible. Il semble donc que vous ayez une course: avant l'exécution de la construction, de nouveaux éléments sont apparus. Je ne sais pas encore comment y remédier.
John Szakmeister
Le doublon possible de la branche Active Git est "(pas de branche)" sur hudson CI
Alberto

Réponses:

153

J'ai rencontré la même erreur sur Jenkins en combinaison avec le plugin de version maven, nous l'avons corrigée en allant à Comportements supplémentaires, Vérifiez dans une branche locale spécifique et entrez 'master'

Je me rends compte que ce n’est pas une solution, mais cela pourrait vous indiquer où chercher.

jvwilge
la source
3
Cela fonctionne lorsque vous construisez à partir de la branche principale. Si votre branche est différente, même après l'avoir modifiée en un nom de branche spécifique, cela ne fonctionne pas.
siddhusingh
29
Je suis sur une branche différente de celle du master et ça marche aussi. Je pense que le problème est que le plugin jenkins git vérifie normalement la branche dans l'état principal détaché. Donc, la git symbolic-refcommande échoue. En ajoutant, Check out to specific local branchnous corrigeons ce problème.
René Link
16
Utiliser **au lieu de masterfera correspondre le nom de la branche locale à celle distante.
neXus
1
Selon l'aide ( Git Plugin - Jenkins - Jenkins Wiki ), laisser le champ vide peut également fonctionner pour cela: "Si sélectionné, et sa valeur est une chaîne vide ou **, alors le nom de la branche est calculé à partir de la branche distante sans l'origine . "
evgeny9
@jvwilge Dans mon cas, c'est un pipeline partagé, donc tous les paramètres proviennent de pom.xml. comment écrire dans le code cette instruction: Comportements supplémentaires,
consultez
31

Pour Jenkins et GIT, ajoutez le comportement supplémentaire check out to specific local branchet utilisez le Workspace Cleanup Pluginpour nettoyer votre espace de travail au début de votre travail CI.

toschneck
la source
1
merci, cela a fonctionné pour moi. J'avais besoin d'ajouter -Darguments="-Dmaven.deploy.skip=true"aussi.
timbru31
@toschneck Salut, je rencontre ce problème avec Jenkins et Git. Pourriez-vous s'il vous plaît développer votre réponse ici pour inclure les commandes et la configuration du plugin que vous avez mentionné. Merci.
Jeremy
Quelle est la raison de nettoyer en plus l'espace de travail?
kap
Actuellement, je suis passé au plugin maven-jgitflow. Il prend en charge le branchement des fonctionnalités et des corrections de bogues et possède la meilleure fonctionnalité de publication que j'ai vue. bitbucket.org/atlassian/jgit-flow/wiki/Home
toschneck
L'ajout de "vérifier dans une branche locale spécifique" fonctionne aussi pour moi.
johnlinp
11

Le problème dans Atlassian Bamboo a été résolu en décochant le paramètre par défaut Use shallow clonesavec une descriptionFetches the shallowest commit history possible. Do not use if your build depends on full repository history . Cette case à cocher se trouve sous Configuration du plan -> onglet Référentiels -> Git -> Options avancées

Après cela, toutes les versions fonctionnent correctement.

SkyWalker
la source
5

Décocher le Use shallow clonesn'était pas suffisant dans mon cas (j'utilise Bamboo 5.7.2). J'avais besoin d'activer également Force Clean Builddans la tâche de vérification du code source. L'activation de Use shallow clonesfonctionnerait pour la prochaine exécution du travail, mais toutes les exécutions suivantes entraîneraient la même erreur.

Jean Marois
la source
4

J'ai vu ce problème sous Bamboo utilisé avec le plug-in Maven Release. Je l'ai corrigé en activant l'option 'Force Clean Build' dans la tâche 'Source Checkout'. Bamboo dit que cela pourrait ralentir la construction, mais cela fonctionne et je n'ai vu aucune augmentation de temps significative.

zakmck
la source
Quelle version de Bamboo avez-vous utilisée? J'ai essayé cela mais cela n'a pas fonctionné pour moi à l'époque.
SkyWalker
1
J'utilise le 5.3 build 4101 - 09 décembre 13
zakmck
3

J'utilise un projet d'équipe Jenkins avec une configuration de projet multibranch.

J'ai précédemment utilisé la checkout scmcommande.

J'utilise maintenant le code suivant:

checkout([
                 $class: 'GitSCM',
                 branches: scm.branches,
                 extensions: scm.extensions + [[$class: 'CleanCheckout'], [$class: 'LocalBranch', localBranch: 'new']],
                 userRemoteConfigs: scm.userRemoteConfigs
            ])
kevcodez
la source
1
Cela a donné un vote positif car il semblait faire l'affaire. Mais après un peu plus de bricolage, j'ai remarqué que cela créait en fait une nouvelle branche appelée "new" (lors de l'utilisation avec le plugin maven release). Une approche plus correcte serait de changer newavec **, ce qui rend le nom de la branche locale identique à celui de la télécommande.
Tobb
3

ce qui a fonctionné pour moi était d'appeler "git checkout -f master" avant d'appeler "mvn release"

Vincent F
la source
0

Pour nous, le problème était avec la version de maven spécifiée dans le fichier pom. Correction de la version maven spécifiée dans le fichier pom conformément à celle en bambou corrigé le problème

Manu
la source
0

Pour les actions GitHub, vous pouvez configurer actions/checkout@v2avecref: master

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