Github Organization Plugin - Multiple Jenkins File

[dockertry]

Hi,
I am new to Github. I am trying to use the Github Organization Plugin to set
up my pipelines in Jenkins.
I am able to get the corresponding pipelines per branch in Jenkins. What I
do want to do is to set up multiple pipelines based off multiple JenkinsFile
in one branch.
For eg. I would have a JenkinsFile trigger a Develop Build..
I would have a QA-JenkinsFile trigger a QA Build..
I would have a Release-JenkinsFile trigger a Release Build..
Firstly, Is this doable? If not, is there an alternate solution that would
allow me to do something like this?
Thanks,




--
Sent from: http://jenkins-ci.361315.n4.nabble.com/Jenkins-users-f361316.html

[dandeliondodgeball]

I think you can have a "build" variable (https://jenkins.io/doc/pipeline/tour/environment/), or parameter (below), and use the value assigned to that.  

Using parameters in a Jenkinsfile.  When this runs you will get an interactive window.

pipeline {
    agent any
    parameters {
        string(name: 'Stack', defaultValue: 'Production', description: 'Which environment is this for?')
    }
    stages {
        stage('Build') {
            steps {
                echo "Running BuilId [${env.BUILD_ID}] on JenkinsUrl [${env.JENKINS_URL}] for Job [${env.JOB_NAME}]"
                //
                sh "<something> <something> ${params.Stack} buildIt"

[dandeliondodgeball]

I think the most common solution is to have one Jenkinsfile (per branch), and manage everything from that.  

[Robert Hales]

I agree with this answer. With a pipeline, it is so easy to make logic decisions and much easier to maintain a single Jenkinsfile that has all the logic. There is surely going to be some duplicated logic, so now only the special differences have to be handled, and you don't duplicate code across the Jenkinsfiles. I have taken several other peoples jobs and consolidated them exactly like this, with just a parameter. If you have 3 different pipeline files, but all in the same branch, then things get complicated when you try to decide which build should be triggered from polling or a hook, anyway. You might as well put it all in one place and handle the logic there.