Yes, one solution would be to store the branch names elsewhere which environment to build on. However that solution would deprive me of a great functionality to automatically build new branches. If I create a new branch origin/fixA from origin/featureA, then I would have to manually update a groovy file to indicate that fixA branch should build on slave nodes belonging to featureA branch, and I have to do it before I push the new branch up to remote
mandag 8. august 2016 12.45.47 UTC+2 skrev Alan Clucas følgende: > > Ok, so you're either in to doing this with git (I'm guessing you use git) > to work out what derived branch you're from, which is very hard in the > general case - or you need to store branch names elsewhere. > > You could perform a load(env.BRANCHNAME+'.groovy') to load a branch > specific groovy snippet (perhaps with a fallback to master if that file > doesn't exist) which defines buildEnvironment for that branch. > > > https://jenkins.io/doc/pipeline/steps/workflow-cps/#load-evaluate-a-groovy-source-file-into-the-pipeline-script > > That would never merge conflict, but would need a tidy-up from time to > time. > > On Wednesday, 3 August 2016 08:08:38 UTC+1, Sverre Moe wrote: >> >> Yes, I am using Multibranch pipeline. >> I already have the branch name with env.BRANCH_NAME, but only some >> designated branches have a list of slave nodes. >> If the branch is master, it should build on all slave nodes in the >> environment for master. >> If the branch is userName/work which is branched out from master it >> should also build in the environment for master. >> I am using the parameter buildEnvironment in the Jenkinsfile to determine >> which environment of slave nodes to build on. >> >> Environment: master >> Nodes: master-sles12-x86_64, master-centos7-x86_64 ... >> >> >> tirsdag 2. august 2016 12.01.10 UTC+2 skrev Alan Clucas følgende: >>> >>> How are you building all these branches? If you're using a multibranch >>> pipeline (or anything else where the branch name is part of the job name) >>> then env.JOB_NAME contains a string you can mangle to extract the branch >>> details. >>> >>> On Tuesday, 2 August 2016 07:19:22 UTC+1, Sverre Moe wrote: >>>> >>>> I am using the variable buildEnvironment to determine which set of >>>> nodes the branch should be built on. >>>> Each release branch (including git master) has their own list of slave >>>> nodes. >>>> >>>> Jenkinsfile: >>>> #!groovy >>>> >>>> def buildEnvironment = "master" >>>> def param2 = null >>>> String[] args = [buildEnvironment, param2] as String[] >>>> >>>> def build = new com.company.ci.Build() >>>> build.execute(args) >>>> >>>> There has been some concerns that the Jenkinsfile could cause forever >>>> merge conflicts because one parameter is different among different >>>> branches. >>>> origin/master -> def buildEnvironment = "master" >>>> origin/releaseA -> def buildEnvironment = "releaseA" >>>> >>>> I could use the branch name to determine which buildEnvironment to use, >>>> but that would not work when it is a feature or work branch created from >>>> either master or a release branch. The branch name master would work for >>>> branch master, but not myUser/work that is branched out of master. >>>> >>>> Anyone have any idea how this can be solved without keeping the >>>> parameter buildEnvironment in the Jenkinsfile? >>>> >>> -- 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/b975c0ce-a100-41d5-beb9-e54792517145%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
