-
Improvement
-
Resolution: Unresolved
-
Major
-
None
This would support scenarios where different "configurations" of a pipeline cannot share the same Jenkinsfile.
If I had multiple Jenkinsfiles... repository github.com/apple/swift
/Package.jenkinsfile /Incremental.jenkinsfile /Incremental-RA.jenkinsfile /Assert.jenkinsfile /src/…
I would like to create multibranch Pipelines for each so I have the resulting structure:
/Apple /Apple/Swift - Package /Apple/Swift - Incremental /Apple/Swift - Incremental-RA /Apple/Swfit - Assert
Note that in this example I have an organization folder for github.com/apple and it is creating multiple multibranch pipelines for each Jenkinsfile discovered in each repository.
I have written up examples and use cases in this doc
- duplicates
-
JENKINS-35415 Multiple branch projects per repository with different recognizers
-
- Open
-
- is duplicated by
-
JENKINS-68717 Multibranch support for multiple Jenkinsfiles in a single repository
-
- Open
-
-
JENKINS-46251 Need to get Jenkinsfiles which can use more than 1 project in the same repo
-
- Resolved
-
-
JENKINS-45273 Pipeline Multibranch - Add the possibility to use a Jenkinsfile from other SCM
-
- Resolved
-
- relates to
-
JENKINS-37220 Job DSL analogue of multibranch projects & organization folders
-
- Open
-
- links to
- mentioned in
-
Wiki Page Loading...
I'm relatively new to Jenkins but for me the reason this feature can't just be straightforwardly implemented in Jenkins is that it lacks a concept of a first-citizen SCM resource, meaning that SCM repositories can be configured in jobs but they are not treated as shareable resources themselves. If repositories could be configured as shareable resources (with no build steps configurable in them) and job could be configured to source on these resources (instead of configuring a separate git/svn connection for each job) it would be easier to implement a single queue of jobs to trigger for SCM changes on a single repository and it would be easier to filter which pipeline to trigger in case Job1 is configured with Jenkinsfile1 and Job2 is configured with JenkinsFile2. The single queue and the filter can probably be implemented with scripting but to have UI support and more declarative approach in the upstream pipelines (as opposed to imperatively select which job to trigger in the downstream SCM projects) something like what I am suggesting could be needed.