Just noticed [the issue I commented on](https://issues.jenkins.io/browse/JENKINS-43749?focusedCommentId=405518&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-405518) is marked a duplicate of this one, so cc'ing here:
As noted above there are actually LOTS of reasons why someone would want multiple Jenkins sub-projects nested inside a repo. For example, this issue creates problems for folks that try to avoid submodules and tend to favor monorepos. In one such case, we have a "configuration-management" repo that we use to contain all of our configuration management tools and projects, e.g. packer, ansible, vagrant, etc.. Workflows are A LOT simpler having a monorepo for this, but when it comes to standing these processes up in Jenkins CI, we crash into this core problem.
To support multiple Jenkinsfiles/multibranch projects in the same repo, we currently use jobdsl to explicitly and statically create a multibranch project for each known project location/subfolder. E.g. in this repo tree, we have 2 packer multibranch pipeline projects and 2 ansible multibranch pipeline projects:
configuration-management
- packer
- subproject1
- Jenkinsfile
- src
- subproject2
- Jenkinsfile
- src
- ansible
- subproject1
- Jenkinsfile
- src
- subproject2
- Jenkinsfile
- src
We use Folders to mirror the repo structure in Jenkins. The jobdsl to create the items in Jenkins looks like:
folder("Packer") {
packer_projects = ['subproject1', 'subproject2']
for (packer_project in packer_projects)
{
multibranchPipelineJob("Packer/${packer_project}") {
.
.
factory {
workflowBranchProjectFactory {
scriptPath("packer/${packer_project}/Jenkinsfile")
}
}
}
}
and
folder("Ansible") {
ansible_projects = ['subproject1', 'subproject2']
for (ansible_project in ansible_projects)
{
multibranchPipelineJob("Ansible/${ansible_project}") {
.
.
factory {
workflowBranchProjectFactory {
scriptPath("ansible/${ansible_project}/Jenkinsfile")
}
}
}
}
This approach works well, except that every time we want to add a new sub-project (ansible or packer subfolder with Jenkinsfile, in this case), we have to modify and push the jobdsl. It'd be great if workflow-multibranch could recursively scan for Jenkinsfiles and basically do what the jobdsl above is doing dynamically for me, as noted by my comments.
I was planning on making this dynamic by modifying my jobdsl to execute a script to perform this Jenkinsfile scanning for me. I assume this is possible - but it's not a complete solution since jobdsl is only updated during Jenkins infrastructure provisioning - infrequently - so this wouldn't detect most cases where someone adds, commits and pushes a subproject with a Jenkinsfile. We really need this scanning to be done by workflow-multibranch.
It would also be nice if the specific script name were configurable at the Github org level, just so we could use something like `.jenkinsfile` rather than `Jenkinsfile`. Talking about this: https://github.com/jenkinsci/workflow-multibranch-plugin/blob/34c7574b0cdcaeb03228422760d82e9d363f83cf/src/main/java/org/jenkinsci/plugins/workflow/multibranch/WorkflowBranchProjectFactory.java#L40