Jenkinsfile merge conflicts because difference between branches

[Sverre Moe]

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?

[Alan Clucas]

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.

[Sverre Moe]

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 ...

[Alan Clucas]

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.

[Sverre Moe]

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

[Alan Clucas]

So you are unwilling to provide a mapping between branch name and slave nodes.

You must therefore work it out by using your version control system to work out where you're derived from and use the mapping for that branch (if it has one, else iterate up again until you find it?)