Jenkins 2.9, multi-branch pipeline, 2 git source repositories, scanning problem.

568 views
Skip to first unread message

D.D.

unread,
Jun 15, 2017, 10:23:25 AM6/15/17
to Jenkins Users
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.

Stephen Connolly

unread,
Jun 15, 2017, 12:27:59 PM6/15/17
to jenkins...@googlegroups.com
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 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

--
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 jenkinsci-users+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/b9c8327e-561e-4dc8-8c01-02ca567a47cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

D.D.

unread,
Jun 18, 2017, 7:00:31 PM6/18/17
to Jenkins Users
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!


To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages