-
Bug
-
Resolution: Fixed
-
Major
-
Linux Ubuntu 3.2.0-58-generic x86_64
Jenkins ver. 1.546
Git Plugin 2.0 (also with 2.0.1 not working)
Git server plugin 1.3
Jenkins GIT client plugin 1.6.2
I wanted to use the "automatic merging" functionality as described here: "Using Git, Jenkins and pre-build branch merging" ( https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-AdvancedFeatures ). I configured my job a described with the integration branch (Branch to merge to) configured to "developAutoMerge" and leaved the 'branch' field in the Git SCM blank.
When I "Build now" I get following exception:
Fetching changes from the remote Git repository
Fetching upstream changes from git@REPOSITORY.git
Seen branch in repository origin/develop
Seen branch in repository origin/developAutoMerge
Seen branch in repository origin/feature/blabla
[...]
Seen branch in repository origin/master
Seen branch in repository origin/release/2.6.1
Seen branch in repository origin/release/2.6.2
Seen 13 remote branches
Multiple candidate revisions
Scheduling another build to catch up with blaServerBuild_developAutoMerge
Merging Revision 6474f8ef91822e58edc55aad707d2725ff5a8431 (origin/feature/blabla) onto /developAutoMerge using resolve strategy
FATAL: Command "git rev-parse /developAutoMerge^
stdout: /developAutoMerge^{commit}
stderr: fatal: ambiguous argument '/developAutoMerge^
{commit}': unknown revision or path not in the working tree.Use '--' to separate paths from revisions
hudson.plugins.git.GitException: Command "git rev-parse /developAutoMerge^{commit}
" returned status code 128:
stdout: /developAutoMerge^
stderr: fatal: ambiguous argument '/developAutoMerge^{commit}
': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1148)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1125)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1121)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:937)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:947)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:401)
at hudson.plugins.git.GitAPI.revParse(GitAPI.java:257)
at hudson.plugins.git.extensions.impl.PreBuildMerge.decorateRevisionToBuild(PreBuildMerge.java:62)
at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:795)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:862)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1415)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561)
at hudson.model.Run.execute(Run.java:1678)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:231)
I found a similar problem by googling: https://groups.google.com/forum/#!topic/jenkinsci-dev/ek4hYR-z08k
The proposed solution there was downgrading the Jenkins Git plugin from 2.0 to 1.4.0.
- duplicates
-
-
- Closed
-
- is related to
-
-
- Closed
-
[JENKINS-21845] Command "git rev-parse /develop^{commit}" returned status code 128
m r
created issue -
m r
added a comment - Thanks! Your hints have helped me solve the problem!
One more question for understanding only: Your naming ("upstream" and "downstream") makes sense only when I have more then one Git repository. Am I right?
m r
added a comment - Thanks! Your hints have helped me solve the problem!
One more question for understanding only: Your naming ("upstream" and "downstream") makes sense only when I have more then one Git repository. Am I right? Yes, you're right. Unless you're using multiple repositories in a single job, it is probably best to name the repository "origin" so that it will have the typical name provided by git as a default.
It would be better if we could find a way to provide a much better error message than a failure from git rev-parse when the origin field is left empty, but I'm not sure if that failure message would be enough either.
| Resolution | New: Not A Defect [ 7 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
Andrei Neculau
made changes -
| Link |
New:
This issue is related to |
rlagoue
added a comment - Hello
I started facing this issue after an upgrade from 2.5.0 to 2.5.1. Downgrading to 2.5.0 solved the issue. The problem is still present in 2.5.2 I just tested it.
rlagoue
added a comment - Hello
I started facing this issue after an upgrade from 2.5.0 to 2.5.1. Downgrading to 2.5.0 solved the issue. The problem is still present in 2.5.2 I just tested it. rlagoue
made changes -
| Resolution | Original: Not A Defect [ 7 ] | |
| Status | Original: Closed [ 6 ] | New: Reopened [ 4 ] |
I think you may have a different issue than is described in that posting on the mailing list. The "ambiguous argument" may be due to the absence of a remote name in the call to "git rev-parse". The failing seems to be "git rev-parse /developAutoMerge^
{commit}", but I think it should be something like "git rev-parse origin/developAutoMerge^{commit}".
In the "Advanced" section of the git repository portion of the job definition, you'll find a field labeled "Name". That field needs a value for the merge use case you're attempting. I set mine to "upstream" and "downstream" to remind myself which one should be the destination of the push.