Hi Stephen, thank you for detailed explanation!
Yes, we have one common upstream parent code base in that project. With the effort I described, we thought to create a few downstream forks, each one for a "variation" of functionality, but build each version of all variations with just one Jenkins project. Thanks for help! On Thursday, June 15, 2017 at 12:27:59 PM UTC-4, Stephen Connolly wrote: > > The answer is No. > > Multiple sources in the same multibranch project are expected to be common > repositories. For example you may have one repo used for deploying to > production and the second for developing changes... and you would deploy to > production by pushing from one repo to the other. > > As such, the list of sources is a priority ordered list of sources. The > first source to claim a "name" owns the name. > > You should either two different multibranch projects if the source > repositories are not related. > > On your laptop do you do > > $ git clone https://repo1.example.org/my-project.git > $ git remota add deploy https://repo2.example.org/my-project.git > $ git checkout -b feature/1 origin/master > $ ... # hack hack hack > $ git commit -m "feature/1 completed" > $ git push -u origin feature/1 > $ ... # wait for jenkins > $ git checkout master > $ git pull origin master > $ git merge feature/1 > $ git push origin/master > $ ... # wait for jenkins > $ git checkout -b staging deploy/staging > $ git merge master > $ git push -u deploy staging > > If "yes", then multiple sources in the same multibranch could be > appropriate depending on what you want to do. > > If "Oh my god no you cannot do that because they are totally different > code bases and do not share a common ancestor"... that is when you use > multiple multibranch projects with one source each > > HTH > > On 14 June 2017 at 20:06, D.D. <[email protected] <javascript:>> wrote: > >> Hi Jenkins Users, >> >> We have a Jenkins (2.9) multi-branch pipeline project. It has 2 git >> source repositories configured so that we pick up and list any branch named >> "release/3.*". Now each of 2 git repos has a branch named release/3.1.0. >> Jenkins detects both branches, but refuses to add the second one to the >> list of branches because there is already an item with the same name. In >> "scan multi-branch pipeline log" log, I see this message: >> >> Checking branch release/3.1.0 >> ‘Jenkinsfile’ found >> Met criteria >> Ignoring <2nd-repo-name> >> release/3.1.0 from source #2 as source #1 owns >> the branch name >> >> >> Is it possible to change this behavior? It could be done by instructing >> Jenkins to use "<repository-name>-<branch-name>" schema in list item names. >> >> Thanks for any help! >> >> D.D. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/b9c8327e-561e-4dc8-8c01-02ca567a47cd%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/b9c8327e-561e-4dc8-8c01-02ca567a47cd%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c47e14e2-622c-4ae4-9ba0-32716e203e15%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
