Setting Up Monorepo Was Hard… Until 2020

Monorepo refers to the strategy of having all subprojects located in a single repository. By contrast, with polyrepo, each subproject has its own repository.

Monorepo brings many benefits, including better collaboration and shared responsibilities. There are many interesting articles discussing the pros and cons of monorepo. One of my favorites is Monorepo: please do! by Adam Jacob.

Just a few years back, setting up a monorepo project was complicated due to the incompatibility of frameworks. For example, many package managers like NPM weren’t monorepo-friendly and infrastructures like Heroku make assumptions about the project’s root that do not hold true for monorepo projects.

Fortunately, tools and platforms have evolved so much that setting up monorepo projects has become much simpler.

CI for Monorepo Is Still Suboptimal

However, initiating an easy-to-use CI infrastructure for a monorepo project still requires a few tricks.

More specifically, unlike in a polyrepo project where the entire CI runs regardless of what the change is, in a monorepo project, always running the entire CI no matter which subproject is modified is time-consuming and hurts productivity.

For example, a monorepo project may contain a server and multiple clients (e.g. a mobile app, a website, and a CLI), and they all have their CI tasks. To maintain code health, projects often enforce CI checks to pass before merging changes, but it quickly becomes a burden when developers have to wait for all those tests to finish just to fix a typo in the documentation.

Note: It’s possible to approve trivial changes in a per-case manner, but that will require human attention.

It’s Possible to Fix It With a DIY Solution

For the example above, it would be great if we could dynamically define (based on the subprojects that are affected) a collection of CI tasks that are necessary to validate the code change and only run and check them for pull requests.

We can abstract the solution proposed above into two parts: running and checking CI tasks selectively.

Run CI tasks selectively

To selectively trigger CI tasks, we can use GitHub Actions’ path triggering (for more details, see Workflow Syntax for GitHub Actions).

GitHub Actions have a unique feature to let us specify triggering conditions, including file path.

#continuous-integration #software-development #programming #github #devops