Jenkins Git Plugin hat HEAD getrennt

74

Ich bin neu bei Git und auch bei Jenkins. Mein Problem ist, dass ich das Jenkins Maven Release Plugin nicht zum Laufen bringen kann.

Wenn ich einen gemeinsamen Maven-Build mit Jenkins erstelle, funktioniert das gut, aber wenn ich versuche, eine Version mit dem Maven-Release-Plugin durchzuführen, erhalte ich die folgende Stapelverfolgung:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.3.2:prepare (default-cli) on project parent: 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.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
    at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
    at hudson.maven.Maven3Builder.call(Maven3Builder.java:98)
    at hudson.maven.Maven3Builder.call(Maven3Builder.java:64)
    at hudson.remoting.UserRequest.perform(UserRequest.java:118)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:326)
    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
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:295)
    at org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:247)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
    ... 27 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:291)
    ... 30 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)
    ... 38 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)
    ... 42 more
channel stopped
Finished: FAILURE

Der fehlerhafte Befehl und die Fehlermeldung lauten:

[INFO] Executing: /bin/sh -c cd
/var/lib/jenkins/workspace/test_maven/parent && git symbolic-ref HEAD
[INFO]  Working directory:
/var/lib/jenkins/workspace/test_maven/parent  mojoFailed
org.apache.maven.plugins:maven-release-plugin:2.3.2(default-cli)
projectFailed ch.apkern.achilles:parent:1.0-SNAPSHOT  sessionEnded

Ich habe herausgefunden, dass das Jenkins Git-Plugin eine getrennte HEAD-Referenz "(kein Zweig)" erstellt, die das Problem verursacht, denke ich. Aber ich habe absolut keine Ahnung, warum dieser Ref erstellt wird oder wie ich dieses Problem lösen kann.

Ich wäre für jede Hilfe dankbar.

git jenkins Michel Werren
quelle
4
Wurde Ihr Problem gelöst? Wenn ja, wäre es schön, wenn Sie die Antwort akzeptieren könnten, wenn sie hilfreich wäre, oder Ihre eigene zur Verfügung stellen könnten, damit andere Menschen von dem Wissen profitieren könnten, danke!
Eugene Sajine
Mögliches Duplikat des Active Git-Zweigs ist "(kein Zweig)" auf Hudson CI
Alberto

Antworten:

80

Das Feld Auschecken / Zusammenführen zum lokalen Zweig (optional) ist in der aktuellen Version (2.2.1) des Git-Plugins nicht mehr vorhanden.

Es wurde zu Zusätzliches Verhalten → In einen bestimmten lokalen Zweig auschecken verschoben :

Jenkins Screenshot der Einstellungsoption "In bestimmten lokalen Zweigstellen auschecken"

Wenn ich diesen Wert auf Master setze, bekomme ich einen ausgecheckten Zweig anstelle eines abgetrennten Kopfes.

Matthias Braun
quelle
5
Wenn Sie mehrere Zweige erstellen möchten, können Sie im GIT-Plugin 2.4.0 (und möglicherweise früher?) Den Namen des lokalen Zweigs festlegen $GIT_BRANCHund einen Zweig erhalten, der nach dem Remote-Zweig benannt ist. (
Christian Semrau
1
Ich möchte nur hinzufügen, dass es viel besser ist, den Wert auf "**" zu setzen oder ihn leer zu lassen. Der lokale Zweigstellenname wird berechnet. Herkunft / Test -> Test
Andrey Klochkov
61

Keine der Jenkins-Konfigurationen der anderen Antwort funktionierte für mich, ohne manuelle Schritte erstellen zu müssen. Was in der Tat funktioniert, ist ganz einfach:

Repository URL: <repo>
Branches to build: master
Checkout/merge to local branch (optional): master
Juraj Misur
quelle
25

UPDATE (November 2015): Bitte beachten Sie, dass diese Lösung für eine bestimmte Version des Git-Plugins (1.1.26) bereitgestellt wurde. In späteren Versionen wurde das Plugin aktualisiert, um die Konfiguration zu vereinfachen.

Für Jenkins Git Plugin Version 1.1.26 versuchen Sie Folgendes:

Gehen Sie zur Jobkonfiguration. Scrollen Sie zum Git-Bereich und klicken Sie unter "Repositories" auf die Schaltfläche "Erweitert ...". Dann setzen Sie:

Name: origin
Refspec: +refs/heads/branch-0.1:refs/remotes/origin/localbranchname

Klicken Sie dann auf eine andere Schaltfläche "Erweitert ..." und stellen Sie Folgendes ein:

Checkout/merge to local branch (optional): localbranchname

Sie können den lokalen Zweig nach Belieben benennen, aber das Ziel in Refspec muss mit dem Namen des lokalen Zweigs in diesem optionalen Feld übereinstimmen (in diesem Fall "Name der lokalen Branche"). Dadurch wird HEAD wie folgt an den lokalen Markennamen angehängt:

HEAD -> refs/heads/localbranchname -> 7a698457751bdc043cfda631b81e3812c5361790

Maven Release sollte jetzt in Jenkins vergehen.

Das funktioniert übrigens bei mir mit Jenkins 1.492 und Jenkins Git Plugin Version 1.1.26.

Konstantin
quelle
5
Die Einstellung für den lokalen Zweig (optional) war die einzige, die ich brauchte
Zac Thompson,
1
Ich auch. Die (optionale) Einstellung machte genug Unterschied. Außerdem verwende ich CloudBees und habe einen SSH-Schlüssel auf GitHub registriert. Die Angabe eines Benutzernamens / Passworts für das Maven Release Plugin verursachte Probleme. Ich habe endlich erfolgreich ohne Benutzername / Passwort veröffentlicht und SSH übernehmen lassen.
Jeff Fairley
4
Übrigens ist ab Jenkins 1.547 (zumindest läuft das so) die zweite erweiterte Schaltfläche weg. Sie können zu einem bestimmten lokalen Zweig auschecken, indem Sie unter "Zusätzliche Verhaltensweisen" ein zusätzliches Verhalten auswählen.
fbl
Ich konnte dies in Jenkins 1.627 beheben, indem ich einfach das Feld "In bestimmten lokalen Zweig auschecken" unter "Zusätzliche Verhaltensweisen" auf "Master" setzte.
Derk
Es funktioniert teilweise, mein Repo befindet sich jetzt in der Filiale, die ich möchte, aber wenn ich versuche zu pushen, bekomme ich fatal: The current branch master has no upstream branch. Ich habe es mit verschiedenen Parametern in der Jenkins Git-Konfiguration versucht, aber kein Glück, ich möchte den git push -u origin master
Filialnamen
9

Wenn Sie in Git einen Zweig wie master oder dev oder einen anderen lokalen Zweig auschecken lassen, enthält Ihr HEAD (Datei im Ordner .git) einen Verweis auf den entsprechenden Zweig. Daher ist es "angehängt".

Wenn Sie einige Vorgänge wie Rebase, Merges oder das Auschecken eines bestimmten Commits ausführen, dh wenn Sie "no branch" sehen, hat Ihr HEAD keinen Verweis auf einen lokalen Zweig, sondern verweist direkt auf das Commit, dh auf dieses hat die eigentliche SHA-1 im Inneren. Das heißt, es ist losgelöst - losgelöst von jedem Zweig. Es wurde keine neue Referenz "kein Zweig" erstellt.

Der Befehl git symbolic-ref HEADprüft, ob der HEAD-Inhalt eine Referenz oder ein SHA-1 ist, und druckt ihn aus.

Sie können dies sehen, indem Sie Folgendes tun:

git checkout master
git symbolic-ref HEAD
git checkout HEAD~2 # going two commits back
git symbolic-ref HEAD
git checkout master # coming back

Die meiste Zeit arbeitet das Git-Plugin in Jenkins mit dem Code im getrennten HEAD-Status. Ich bin nicht sicher, wie das Maven-Release-Plugin funktioniert, aber ich bin mir zu 99% sicher, dass Sie es von einem bestimmten Zweig freigeben müssen. Um dies zu beheben, würde ich empfehlen, Folgendes als vorgefertigten Schritt oder Shell-Befehl anzugeben:

git checkout master; git pull origin master

Das wird das Problem lösen, hoffe ich;)

Eugene Sajine
quelle
Danke für deine Hilfe! Auf diese Weise habe ich den Hauptzweig wieder ausgecheckt, den ich bereits gefunden habe. Das Maven-Release-Plugin verwendet jedoch auch das Git-Plugin, um die Quelle abzurufen. Dies bedeutet, dass das Maven-Release-Plugin die Release-Ziele nur mit Parametern aufruft. Es besteht keine Möglichkeit, einen vorgefertigten Schritt zwischen diesem und zwei Schritten aufzurufen.
Michel Werren
Soweit ich weiß, sind die Release-Ziele etwas, das Sie optimieren sollten. Sie wissen, dass der aktuelle Zweig nicht ermittelt werden kann, daher sollten Sie in der Lage sein, das Release-Ziel vorzubereiten, damit das Projekt im richtigen Zweig ausgecheckt werden kann. Ich denke, der beste Weg wäre, einen einzelnen Zweig zu definieren, von dem Sie immer freigeben, wie z. B. den Master, und Ihr "Vorbereitungs" -Ziel zu ändern, um das Plugin aufzunehmen, indem Sie den Hauptzweig explizit auschecken.
Eugene Sajine
7

Ich möchte mehrere Zweige bauen und jeden Zweig unter seinem Namen überprüfen. Ich benutze das GIT Plugin 2.4.0.

Die Antwort von Matthias Braun gibt Ihnen einen benannten Zweig, der jedoch nicht nach dem entfernten Zweig benannt ist.

Anstatt den lokalen Zweig festzulegen master, legen Sie den lokalen Zweig fest$GIT_BRANCH .

Ich habe diese Lösung in https://issues.jenkins-ci.org/browse/JENKINS-6856 gefunden

Christian Semrau
quelle
1
Durch Setzen des lokalen Zweigs auf $ GIT_BRANCH wurde für mich ein neuer Zweig auf der Fernbedienung erstellt: origin / origin / master. Den Parameter leer zu lassen schien korrekt zu funktionieren.
Apa64
5

(Gelöst)

Hallo, ich hatte das gleiche Problem, als ich versuchte, einen parametrisierten Release-Build aus einem Zweig mit dem Maven-Release-Plugin: 2.5.3 und dem Maven-SCM-Provider-JGIT: 1.9.5 zu erstellen.

Ich wollte in der Lage sein, den Zweig für den "parametrisierten Release-Build" auszuwählen. Dies funktionierte nicht und als ich "Auschecken / Zusammenführen zum lokalen Zweig (optional)" auswählte, funktionierte dies, endete jedoch mit einem Zweig "Ursprung / Ursprung / Zweig". in fern (wiederholter Ursprung).

Damit:

  • Fügen Sie "Git Parameter" zu "Dieses Projekt ist parametrisiert" hinzu.
    Name: branch
    Parametertyp: Branch
    Klicken Sie auf Erweitert:
    Branch Filter: origin /(.*)
    (das war der Trick!)

  • Git Repository:
    Zu erstellende Zweige: refs / remotes / origin / $ {branch}

  • Zusätzliche Verhaltensweisen: -> Zu einem bestimmten lokalen Zweig
    auschecken Zweigstellenname: $ {Zweig}

Habe Spaß :-)

RS
quelle
Dies erfordert die Installation des Plugins "Git-Parameter"
MatPag
1

Habe das gleiche Problem. @ Eugene Lösung hat nur einmal funktioniert. Beim zweiten Versuch ist ein Fehler aufgetreten - "HEAD kann nicht aus dem Repository gelöscht werden" oder ähnliches.

Ich habe dies gegründet ( Quelle ):

Und m2 zusätzliche Schritte (Pre-Build)

Git Checkout Master || Git Checkout -b Master

Git Reset - Hard Origin / Master

Und jetzt denke ich, dass es in Ordnung ist.

Pawel
quelle
1

Ich hatte das gleiche Problem. Ich habe die Lösung von Constantine ausprobiert, die perfekt funktioniert hat, aber das Tag und die Commits wurden in das Remote-Repository "localbranchname" übertragen.

Also habe ich das gleiche gemacht, aber manuell: Fügen Sie zuerst ein Shell-Skript vor den Schritten hinzu:

git branch -f localJenkins
git checkout localJenkins

Dann ein Post-Steps-Shell-Skript:

git checkout master
git rebase localJenkins
git branch -D localJenkins
git push origin master
git push --tag

Das funktioniert ! Auf diese Weise haben Sie keinen Jenkins-Remote-Zweig, Commits und Tags befinden sich im Master-Zweig (oder einem anderen Zweig).

hoffe das hilft !

Antoine
quelle
1

Zur Maven-Befehlszeile für die Release-Vorbereitung hinzufügen: -DpushChanges=false -DlocalCheckout=true

Dies bedeutet, dass Maven das verwenden würde, was Jenkins im Arbeitsverzeichnis gefunden hat .git, und weder die Fernbedienung klonen noch auf die Fernbedienung drücken würde.

Ich empfehle, voll qualifiziert zu konfigurieren refs/remotes/origin/develop als Git "Branch to Build" . Auf diese Weise erscheint es mir verständlicher.

In diesem Fall würde Ihr $ GIT_BRANCH von Jenkins auf magische Weise auf gesetzt origin/develop

Anstatt übermäßig komplizierten (aber portablen) GitPublisher zu verwenden, fügen Sie einfach einen Post-Build-Schritt "Shell ausführen" hinzu:

echo Remote branch is $GIT_BRANCH, replacing origin with refs/heads.
git push --follow-tags "$GIT_URL" "+HEAD:${GIT_BRANCH/#origin\//refs/heads/}"

Dadurch werden alle geänderten Maven wie pom.xml und Tags verschoben.

kubanczyk
quelle