1
votes

We are a .net shop. Our Jenkins environment has a master on Windows, one Windows slave server and one Linux slave server. Each slave server has many slaves (they are actually just multiple Jenkins slaves running on the same server) named after the line of business, and projects belong to that line of business are running on that particular slave.

For those slaves run on a special account, I understand it's necessary to have their own slave, but for those doesn't, I don't understand why separate them into different slaves and restrict projects to run only on these slaves. My concerns are:

  1. Some line of business has a lot more projects than the others and could cause longer wait time.
  2. If the slave is down, then all projects in this line of business can't run, will cause unnecessary downtime.

I am thinking about these rules for a separate slave:

  1. Need different OS/software,etc., builds can't be run on the same build server, require a separate server with a new slave on it.
  2. Need different account to run the build, require a separate slave to run on this account, can use the same slave server though.
  3. Create more public slaves, all projects have no special requirement can use any of them.
  4. Configure each slave to have multiple executors based on number of projects.

What do you think?

1

1 Answers

0
votes

The list is excellent. Sharing some of my notes here.

Our preference is to tag slaves on its "capabilities". For example a slave can be tagged as "linux", "clearcase", "win32","vc++" etc.

Typical job should not be bound directly to a slave. It must be bound to a label. Label expressions can have logical arithmetic in it so you can say this job must run on slave with clearcase on linux. Exceptions are cases where nodes needs special software like VC++ or Purify etc.

Item 4 needs more clarification. Yes, this must be function of the machine running the slaves.

Some related plugins you may find useful are Swarm Plugin, Throttle Plugin