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 jenkinsci-users+unsubscr...@googlegroups.com. 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.
