How do I make Jenkins pipeline run in (any) agent machine, but never master?

Question

My Jenkins pipeline randomly alternates between running on master and on agent (slave) machines.

The whole pipeline has only one agent statement, thus:

pipeline {
  agent any

How can I get the build to run in load-balanced agents, and never master?

• Maybe it could be done with agent { label 'some-label' }. Is there a predefined label that specifies agents and not master? Or do I have to label all agents myself?

• This and this show how to choose a specific agent, but I want random balancing between agent machines.

• This question discusses agent any vs agent none, but neither of those blocks the master from being used.
• This page recommends wrapping everything in a node stanza, but that seems to force the build to run on master or a specified node, which again does not allow balancing of agents.

Answer 1

You can use node('!master') {...} or agent { label '!master' } syntax. See more details there.

Also there is a solution from Jenkins Best Practices page for setting limitation on master node itself:

If you have a more complex security setup that allows some users to only configure jobs, but not administer Jenkins, you need to prevent them from running builds on the master node, otherwise they have unrestricted access into the JENKINS_HOME directory. You can do this by setting the executor count to zero. Instead, make sure all jobs run on agents. This ensures that the jenkins master can scale to support many more jobs, and it also protects builds from modifying potentially sensitive data on $JENKINS_HOME accidentally/maliciously. If you need some jobs to run on the master (e.g. backups of Jenkins itself), use the Job Restrictions Plugin to limit which jobs can be executed there.

Answer 2

When configuring node restrictions based on labels for freestyle jobs in the jenkins web interface, you can do this with the expression !master. The boolean operators || and && are also supported.

I'm not sure whether the pipeline configuration supports the same expression syntax, but it's worth a shot.