Quicksort with Jenkins for Enjoyable and No Revenue

The following steps show how to run your first Jenkins pipeline:

1. Go to Dashboard > New Item. Enter an item
   name, say, hello, select Pipeline, and
   click OK.

2. On the next page, scroll down to the Pipeline section
   at the bottom and paste the following pipeline script and
   click Save.

   node {
       echo "hello, world"
   }
   

3. Now click Build Now. A new build number appears at the
   bottom half of the left sidebar. Click on the build number,
   then click Console Output to see the output of the
   pipeline. The hello, world message should be
   present in the output.

To edit the pipeline script anytime, go to Dashboard, click
on the pipeline, then go to Configure, scroll down to
the Pipeline section, edit the script, and
click Save.

In real world software development, Jenkins is typically configured
to automatically pull some source code from a project repository
maintained under a version control system and then build it using
the pipeline script found in the file named Jenkinsfile
present at the top-level directory of the project. But since we
only intend to perform fun experiments in this post, we will just
paste our pipeline script directly into the pipeline configuration
page on Jenkins as explained above in order to keep things simple.
Jenkins also supports another way of writing pipelines using a
declarative style. They are known as declarative
pipelines. In this post, however, we will be writing
only scripted pipelines so that we can write simple Groovy
code for our experiments without having to bother about too many
pipeline-specific notions like stages, steps, etc.

Now let us write a simple pipeline that calculates the factorial of
a nonnegative integer. This will help us to demonstrate how a build
job can recursively call itself. We are not going to write
something like the following:

properties([
    parameters([
        string(
            name: 'INPUT',
            defaultValue: '0',
            description: 'A nonnegative integer'
        )
    ])
])

def factorial(n) {
    return n == 0 ? 1 : n * factorial(n - 1)
}

node {
    echo "${factorial(params.INPUT as int)}"
}

The code above is an example of a function that calls itself
recursively. However, we want the build job (not the
function) to call itself recursively. So we write the following
instead:

properties([
    parameters([
        string(
            name: 'INPUT',
            defaultValue: '0',
            description: 'A nonnegative integer'
        )
    ])
])

def MAX_INPUT = 10

node {
    echo "INPUT: ${params.INPUT}"
    currentBuild.description = "${params.INPUT} -> ..."

    def n = params.INPUT as int
    if (n > MAX_INPUT) {
        echo "ERROR: Input must not be greater than ${MAX_INPUT}"
    }

    env.RESULT = n == 0 ? 1 : n * (
        build(
            job: env.JOB_NAME,
            parameters: [string(name: 'INPUT', value: "${n - 1}")]
        ).getBuildVariables().RESULT as int
    )

    echo "RESULT: ${env.RESULT}"
    currentBuild.description = "${params.INPUT} -> ${env.RESULT}"
}

This code example demonstrates a few things worth noting:

Now we will implement quicksort in Jenkins. Sorting numbers using
the standard library is quite straightforward in Groovy. Here is an
example in the form of Jenkins pipeline:

properties([
    parameters([
        string(
            name: 'INPUT',
            defaultValue: '4, 3, 5, 4, 5, 8, 7, 9, 1',
            description: 'Comma-separated list of integers'
        )
    ])
])

node {
    def numbers = params.INPUT.split('s*,s*').collect {it as int}
    echo "${numbers.sort()}"
}

It can’t get simpler than this. However, we are not here to
demonstrate the standard library methods. We are here to
demonstrate recursion in Jenkins! We write the following pipeline
script instead:

properties([
    parameters([
        string(
            name: 'INPUT',
            defaultValue: '4, 3, 5, 4, 5, 8, 7, 9, 1',
            description: 'Comma-separated list of integers'
        )
    ])
])

def MAX_INPUT_SIZE = 10

node {
    echo "INPUT: ${params.INPUT}"
    currentBuild.description = "${params.INPUT} -> ..."

    def numbers = params.INPUT.split('s*,s*').collect {it as int}
    if (numbers.size() > MAX_INPUT_SIZE) {
        echo "ERROR: Input must not contain more than ${MAX_INPUT_SIZE} integers"
    }

    def pivot = numbers[0]
    def others = numbers.drop(1)
    def lo = others.findAll { it <= pivot }
    def hi = others.findAll { it > pivot }
    def builds = [:]
    def results = [lo: [], hi: []]

    if (lo) {
        builds.lo = {
            results.lo = build(
                job: env.JOB_NAME,
                parameters: [string(name: 'INPUT', value: lo.join(', '))
            ]).getBuildVariables().RESULT.split('s*,s*') as List
        }
    }
    if (hi) {
        builds.hi = {
            results.hi = build(
                job: env.JOB_NAME,
                parameters: [string(name: 'INPUT', value: hi.join(', '))
            ]).getBuildVariables().RESULT.split('s*,s*') as List
        }
    }
    parallel builds

    env.RESULT = (results.lo + [pivot] + results.hi).join(', ')
    echo "RESULT: ${env.RESULT}"
    currentBuild.description = "${params.INPUT} -> ${env.RESULT}"
}

Some of the code is similar to the one in the previous section. For
example, the properties step to set up the build
parameter, the build() call, setting the result
in env.RESULT, etc. should look familiar. Let us pay
attention to what is different.

Firstly, we have two build() calls instead of just one.
In fact, we have two closures with one build() call in
each closure. Then we use the parallel step to execute
both these closures in parallel. In each build job, we pick the
first integer in the input as the pivot, then compare all the
remaining integers with this pivot and separate them
into lo (low numbers) and hi (high
numbers). Then we call the build job recursively to repeat this
algorithm twice: once on the low numbers and again on the high
numbers.

Unlike most textbook implementations of quicksort which lets the
recursion run all the way to the base case in which an empty list is
received and the recursive call returns without doing anything, the
above implementation is slightly optimised to avoid making recursive
builds when we find that the list of low numbers or the list of high
numbers is empty. We lose a little bit of simplicity by doing this
but it helps in avoiding wasteful build jobs that just receive an
empty list of numbers as input and exit without doing anything
meaningful.

I hope this was fun!