Support for multiple SCM plugin

[darkjh]

I need to use this pull-request plugin in a job where 2 repos need to be checked-out:

• one main project whose pull-request branch is the test target
• one auxiliary project used for provisioning reason

I'm using multiple SCM plugin with 2 git scm. And as usual, I set the Advanced/refspec of the main project to be +refs/pull/*:refs/remotes/origin/pr/* and leave the auxiliary project's configs intact (so jenkins should always checks out its default branch).

The pull request triggers correctly the job build but the problem is that when checking out the auxiliary project, instead of the default branch, jenkins tries to checks out a pull-request branch as if it's the main project.

# jenkins checks out the main project's pull request branch, OK!
GitHub pull request #439 of commit 8444c7344c4f4a20928b9d8021e387660928a002 automatically merged.
Building in workspace /var/lib/jenkins/jobs/main_project/workspace
 > git rev-parse --is-inside-work-tree
Fetching changes from the remote Git repository
 > git config remote.origin.url git@main_project.git
Fetching upstream changes from git@main_project.git
 > git --version
 > git fetch --tags --progress git@main_project.git +refs/pull/*:refs/remotes/origin/pr/*
 > git rev-parse origin/pr/439/merge^{commit}
Checking out Revision fdaf37ae7048a4c8999471a8dc6df0ea72dbce67 (detached)
 > git config core.sparsecheckout
 > git checkout -f fdaf37ae7048a4c8999471a8dc6df0ea72dbce67
 > git rev-list 6a561e06859de8177ac504cd8c3c05315cedc699
 > git rev-parse --is-inside-work-tree

# jenkins tries to checkout the same, pull-request branch, in the auxiliary project, why?
Fetching changes from the remote Git repository
 > git config remote.origin.url git@auxiliary.git
Fetching upstream changes from git@auxiliary.git
 > git --version
 > git fetch --tags --progress git@auxiliary.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse origin/pr/439/merge^{commit}
FATAL: Command "git rev-parse origin/pr/439/merge^{commit}" returned status code 128:
stdout: origin/pr/439/merge^{commit}

So from above log, jenkins tries to get origin/pr/439/merge^{commit} of the auxiliary project, but that doesn't exists, and I've never configures it to do that. It should always checks out the default branch of the auxiliary project.

So is it a bug? Or simply because multiple scm plugin is not supported? If the latter one is true can you guys gives me some pointers so that I can try to make a contribution?

Thanks.

[valdisrigdon]

I would suspect that it would be because we are explicitly setting the Git revision to build via RevisionParameterAction. I'm not sure how the multiple SCM plugin works. Perhaps there's a way to set the RevisionParameterAction to only be for a particular repo? Maybe the multiple SCM plugin folks know of a way.

[darkjh]

Thanks @valdisrigdon for your reply.

I don't have much knowledge about jenkins plugin architecture but I found that multiple scm plugin call each scm's checkout method in turn. https://github.com/jenkinsci/multiple-scms-plugin/blob/master/src/main/java/org/jenkinsci/plugins/multiplescms/MultiSCM.java#L118

[jimis]

I'm seeing exactly the same: using the MultipleSCMs plugin, and despite having set the branch to ${sha1} only in one of the repositories and in the other I set it to master, the plugin tries to checkout the pull-request head in both repositories, failing for the second with the following backtrace:

01:03:03  > git rev-parse origin/pr/870/merge^{commit} # timeout=10
01:03:03 FATAL: Command "git rev-parse origin/pr/870/merge^{commit}" returned status code 128:
01:03:03 stdout: origin/pr/870/merge^{commit}
01:03:03 
01:03:03 stderr: fatal: ambiguous argument 'origin/pr/870/merge^{commit}': unknown revision or path not in the working tree.
01:03:03 Use '--' to separate paths from revisions
01:03:03 
01:03:03 hudson.plugins.git.GitException: Command "git rev-parse origin/pr/870/merge^{commit}" returned status code 128:
01:03:03 stdout: origin/pr/870/merge^{commit}
01:03:03 
01:03:03 stderr: fatal: ambiguous argument 'origin/pr/870/merge^{commit}': unknown revision or path not in the working tree.
01:03:03 Use '--' to separate paths from revisions
01:03:03 
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1437)
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1413)
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1409)
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1112)
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1122)
01:03:03    at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.revParse(CliGitAPIImpl.java:518)
01:03:03    at hudson.plugins.git.GitAPI.revParse(GitAPI.java:257)
01:03:03    at sun.reflect.GeneratedMethodAccessor62.invoke(Unknown Source)
01:03:03    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
01:03:03    at java.lang.reflect.Method.invoke(Method.java:622)
01:03:03    at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:309)
01:03:03    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:290)
01:03:03    at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:249)
01:03:03    at hudson.remoting.UserRequest.perform(UserRequest.java:118)
01:03:03    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
01:03:03    at hudson.remoting.Request$2.run(Request.java:328)
01:03:03    at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
01:03:03    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
01:03:03    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
01:03:03    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146)
01:03:03    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
01:03:03    at java.lang.Thread.run(Thread.java:701)

[jimis]

Searching online, it seems that other people are seeing the same behaviour, and that it was introduced some time after 1.9. I have zero knowledge of the internals but looking at the diffs after 1.9 I've found a couple suspicious commits, that have to do with the rev-parse command with origin/pr/... tag. FWIW git.RevisionParameterAction() seems relevant to the rev-parse command.

Can you please have a look and see if some change could have introduced this?

[jimis]

I just verified that this works properly in version 1.9.

Which means that when using the MultipleSCMs plugin, the proper branch is checked out for each repository, and the ${sha1} pull-request branch is only checked out at the one which was specified in the configuration.

[aehlke]

Any workaround available for this?

[whirm]

I'm also interested on a fix/workaround for this.

[NikolausDemmel]

+1

[meekrosoft]

I think I have found a workaround on this. I create a "trigger job" that just listens for changes on the repo I want to trigger on, then create a downstream build job with multi SCM. It seems to work ok in this scenario, but I'm not really sure why.

[emmanuelmathot]

+1

[aehlke]

We simply stopped using multiple SCM plugin, and use the shell to clone any additional repos we may need. This doesn't scale to all use cases of course as you lose out on other SCM features of Jenkins.