Jenkins Configuration for a Monorepo

In the article "Monorepos - Pros and Cons", I compared the advantages and disadvantages of monorepos. Monorepo critics like to argue that monorepos make the build pipeline more complicated.

In this article, I show it doesn't have to be like that!

I'll show you, step by step, how to configure Jenkins to build a subproject of a Git monorepo.

Example Project

I'll limit this to a rudimentary Jenkins job that clones and compiles a simple Maven project from a subdirectory of the Monorepo's main branch.

You can find the sample project in this GitHub repository.

Additional features like selecting a branch or creating and tagging a release are not monorepo-specific and are beyond the scope of this article. Instead, I refer you to my Jenkins tutorial on build and release jobs.

In the next section, you'll read how to create a Monorepo Jenkins job via the user interface. The following section shows how to write the project as code using the Jenkins Job DSL.

Configuring the Monorepo Jenkins Job via the User Interface

First, create a new Maven job and give it a name, such as "Sparse Checkout Demo". In the "General" tab, you can enter a short description:

Under "Source Code Management", select "Git" and specify the repository, e.g., https://github.com/SvenWoltmann/sparse-checkout-demo.git (you are welcome to use this repo for testing). As Branch Specifier, enter "main".

Under "Additional Behaviours", click on "Add" and select "Sparse Checkout paths". The path is, for example, "project-a/", one of my two project directories in the demo monorepo.

Click "Add" a second time and select "Polling ignores commits in certain paths". Under "Included Regions", enter the project directory again, i.e., "project-a/" in the example. This setting causes Jenkins to execute the job only if files in the project directory were changed.

Finally, under "Build", enter the pom.xml file of the project directory (in the example: "project-a/pom.xml") as Root POM – and "clean install" as Maven goal:

The job configuration is now complete, and the job is ready to run.

Monorepo Jenkins Job as Code (Jenkins Job DSL)

This section shows how you can write the same job as code. I always recommend the code variant because it allows you to create uniform jobs for all your projects in an automated and reproducible way with little effort.

See my Jenkins job DSL tutorial for a more in-depth introduction to Jenkins jobs as code.

First, ensure that your Jenkins installation has the Job DSL plugin installed.

Then create a new "Freestyle project", create a build step "Process Job DSLs", and enter the following code:

mavenJob('Sparse Checkout Demo') {
  description 'This is a demo for building a project in a sub-directory of a Git Monorepo.'
  def sparseCheckoutPath = 'project-a'
  scm {
    git {
      remote {
        name 'origin'
        url 'https://github.com/SvenWoltmann/sparse-checkout-demo.git'
      }

      branch 'main'

      configure { git ->
        git / 'extensions' / 'hudson.plugins.git.extensions.impl.SparseCheckoutPaths' / 'sparseCheckoutPaths' {
          'hudson.plugins.git.extensions.impl.SparseCheckoutPath' {
            path "$sparseCheckoutPath/"
          }
        }
        git / 'extensions' / 'hudson.plugins.git.extensions.impl.PathRestriction' {
          includedRegions "$sparseCheckoutPath/.*"
        }
      }
    }
  }

  rootPOM "$sparseCheckoutPath/pom.xml"

  goals 'clean install'
}Code language: Groovy (groovy)

You must configure the sparse checkout path and the polling filter via so-called "extensions" because the Jenkins Job DSL does not natively support these features (the Git plugin adds them).

Summary

This article has shown how to configure a Jenkins job that builds a subproject of a monorepo. For more in-depth information about Jenkins, see my Jenkins tutorial.

If you liked this article, feel free to share it using one of the share buttons, and leave me a comment: What is your experience with monorepos? Do you share my assessment of the pros and cons?

Do you want to be informed when the next article is published on HappyCoders.eu? Then click here to sign up for the HappyCoders newsletter.