-
Improvement
-
Resolution: Duplicate
-
Minor
-
None
Currently you can specify multiple github sources in the configuration of a multibranch workflow project.
However when it comes to resolving the headcommit for the triggering source, it defaults to looking in the repository for the first source. This is the result of that:
hudson.plugins.git.GitException: Failed to fetch from https://github.com/**************************.git
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:810)
at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1066)
at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1097)
at org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
at org.jenkinsci.plugins.workflow.cps.CpsScmFlowDefinition.create(CpsScmFlowDefinition.java:108)
at org.jenkinsci.plugins.workflow.multibranch.SCMBinder.create(SCMBinder.java:85)
at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:206)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:410)
Caused by: hudson.plugins.git.GitException: Command "C:\Program Files\Git\bin\git.exe -c core.askpass=true fetch --tags --progress https://github.com/*******************.git +refs/heads/:refs/remotes/origin/" returned status code -1:
stdout:
stderr:
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1719)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1463)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:63)
at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:314)
at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:808)
... 8 more
GitHub has been notified of this commit’s build result
ERROR: null
Finished: FAILURE
- duplicates
-
JENKINS-32018 Multibranch workflow project tracking multiple repositories
-
- Open
-
[JENKINS-35657] Support Multibranch Workflow from 2 different github repos
Not clear to me what the actual use case is here. Multiple forks of the same repository?
Bryden Oliver
added a comment - My particular use case is having 2 repositories, one a server and one a client, so disjoint but related.
We want to have one build that grabs source from both and then builds them together particularly for testing purposes.
The changes I proposed means that for any change in repo A or repo B, it kicks off a build and manages all the branches that are open in either repo.
All for a little bit of safety in the code, that covers the case that the config UI allows you to do, but currently just fails if you do use it.
Bryden Oliver
added a comment - My particular use case is having 2 repositories, one a server and one a client, so disjoint but related.
We want to have one build that grabs source from both and then builds them together particularly for testing purposes.
The changes I proposed means that for any change in repo A or repo B, it kicks off a build and manages all the branches that are open in either repo.
All for a little bit of safety in the code, that covers the case that the config UI allows you to do, but currently just fails if you do use it. Bryden Oliver
added a comment - The duplicate issue covers far more and seems to involve a far more complicated solution. Although the solution proposed here could probably cover the case mentioned in the other issue, or at least a significant subset of them.
Bryden Oliver
added a comment - The duplicate issue covers far more and seems to involve a far more complicated solution. Although the solution proposed here could probably cover the case mentioned in the other issue, or at least a significant subset of them. Your use case definitely sounds like JENKINS-32018. The current plugin design is not intended to handle this.
I've raised Pull Request: https://github.com/jenkinsci/github-branch-source-plugin/pull/59 to cover this.
Take a look and see what you think.