4

I have been working on an android OS build automation through Jenkins and the repository is massive and the build itself takes a fair amount of time. Therefore, I need to to run on my slave that has much more power and threads available for the build and not fill the masters disk space up to the point where the other devs can't use it.

When I had my first build generated it deployed to the master, I checked the configuration and reviewed the best practices from Jenkins.

https://wiki.jenkins.io/display/JENKINS/Jenkins+Best+Practices

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

I noticed that we had two executors available on the master and as per the best practices this should be set to zero if you never want to build on the master. I set this down to zero and retried my build.

Master Server Executors

To my surprise it's still building on the master. Below is my Jenkins file that implicitly says to build on my slave.

pipeline {
    agent {label 'van-droid'}

    stages {
        stage('Build') {
            steps {
        echo 'Building..'
        sh 'make clean'
        sh 'export USE_CCACHE=1'
        sh 'export CCACHE_DIR=/nvme/.ccache'
        sh './FFTools/make.sh'
             }
        }
    }
}

Anyone have any idea what's going on?

Husk Rekoms
  • 217
  • 1
  • 4
  • 15
  • 1
    To be clear, was it doing the actual build on the master? Pipeline jobs run a 'flyweight executor' on the master for the top-level script, and anything not inside a `node` block (in the Scripted syntax). See https://support.cloudbees.com/hc/en-us/articles/360012808951-Pipeline-Difference-between-flyweight-and-heavyweight-Executors – TBBle Mar 29 '19 at 10:13

3 Answers3

2

Ok, so the only way I have been able to force the build to the slave was to install the Node/Label plugin and add a parameter saying that the project could only be built on the specific slave I requested. This seems to be a better way of doing it as some devs were actually using the master to build certain projects and their builds were pending when I put the executors to zero.

Husk Rekoms
  • 217
  • 1
  • 4
  • 15
2

Also you can try

agent {label '!master'}

That is supposed to avoid the excution of the job in the master node (change master by the label you assigned to your master node).

2

"To my surprise it's still building on the master."

ALL pipeline builds run in the master as "Flyweight" executors. Pipeline builds actually start the minute they are dequeued.

Both Actual executions on the master and Flyweight Executors

Notice the subtle difference in the display.

In the example shown here, the Master has 4 executors which are numbered and two jobs are actually running on the Master. The other two (highlighted in yellow for clarity) are "Flyweights" - also called OneOffExecutors which appear for a time until they are dispatched elsewhere, but they indeed are running for the duration of the job. You can see what is running on your master as OneOff's using a query like this:

https://YOUR.JENKINS.URL/computer/(master)/api/python?pretty=true&tree=oneOffExecutors[currentExecutable[fullDisplayName,result,id,url]]&depth=1

You don't have to use the python rendering, but it is easier to read than say, XML.

The Flyweight or "OneOffExecutors" are how the master keeps track of and coordinates pipeline jobs. You can read more about them in the link shared above.