<p>You need to narrow down your scope and deal with tooling for monorepos. There are various <em>awesome-monorepo</em> lists on Github (<a href="https://github.com/korfuri/awesome-monorepo" rel="nofollow noreferrer">this is a recent one</a>) to actually find out, what kind of tooling fits your use case best (what programming languages are you using?).</p>

<p>If you have completely isolated projects in your repository you can cobble up some bash scripting utilizing <code>git diff</code> output or better use one of the many available monorepo-aware built utilities (see above awesome list for examples). </p>

CC BY-SA 4.0
2018-11-26T22:34:50.010Z
2018-11-26T22:34:50.010Z
Christian Ulbrich
<blockquote>
  <p>If this is translated to a monorepo that means that 1 change results
  in 3 pipeline triggers, while in some cases only 1 pipeline should be
  triggered.</p>
</blockquote>

<p>I would definitely take this point into further consideration. One of the most compelling reasons for using a monorepo is that it does not create a technical separation of projects. There is only a logical separation, with the only technical distinction possibly being your versioning (unless you have a universal version number). This means, that you have no 100% guarantee that any one project does not depend on another project. Because of this, your final pipeline at some point should include <strong>all of the projects</strong> within your repository. By doing so, you are guaranteeing that a change to one project does not negatively impact any other projects in your repository (at the cost of the project with the longest time to build, publish, etc.). </p>

<p>That being said, if there are some steps in your pipeline that you would like to run separately (lint, syntax, compile, etc.), most CI's should have a way to filter your repo for a specific folder/project. If it doesn't, and you still don't want to run against all projects, you may need to consider refactoring your repository into <a href="https://puppet.com/blog/refactor-your-monolithic-code-repo-to-deploy-r10k" rel="nofollow noreferrer">separate repos</a> or changing CI tools to comply with your workflow. </p>

CC BY-SA 3.0
2017-09-25T15:20:58.970Z
2017-10-15T14:58:50.183Z
2017-10-15T14:58:50.183Z
Preston Martin
<p>According to <a href="https://developer.atlassian.com/blog/2015/10/monorepos-in-git/" rel="noreferrer">this article</a> a monorepo contains different projects. What are best practices for triggering different pipelines?</p>

<p>The current git repo contains the following projects:</p>

<pre><code>╔═════════════╗
║ projects    ║
╠═════════════╣
║ A           ║
║ B           ║
║ C           ║
║ D           ║
║ E           ║
╚═════════════╝
</code></pre>

<p>There are three different pipelines, i.e. <code>x</code>, <code>y</code> and <code>z</code></p>

<p>If a certain project inside the monorepo changes, different pipelines should be triggered, i.e.:</p>

<p>If a commit is done in folder <code>a</code> then pipeline <code>x</code> should be triggered (<code>a --&gt; x</code>).
If a change occurs in directory <code>b</code> or <code>c</code> then pipeline <code>y</code> should be run (<code>b || c &gt; y</code>) and if either <code>d</code> or dir <code>e</code> changes then pipeline should start running (<code>d || e &gt; z</code>).</p>

<p>How to achieve this? Most CI's are triggered by changes in a repository, e.g. one commits to a repo and a pipeline is triggered. There is a 1 on 1 relation. If this is translated to a monorepo that means that 1 change results in 3 pipeline triggers, while in some cases only 1 pipeline should be triggered.</p>

CC BY-SA 3.0
2017-09-25T12:00:55.393Z
Either add a filter on your pipeline trigger (highly dependent on your CI system) or do it the right way and split those repos, there's no reason project B get all history on projects A, C, D and E, that's just noise and makes following B's history more difficult as it keeps commits unrelated to it.
Tensibai
<continuous-integration><monorepo>
What are best practices for creating and triggering various pipelines regards monorepos?
030
# What are best practices for creating and triggering various pipelines regards monorepos?

(Asked by: username_0 on 2017-09-25)

According to this article a monorepo contains different projects. What are best practices for triggering different pipelines?
The current git repo contains the following projects:
╔═════════════╗
║ projects    ║
╠═════════════╣
║ A           ║
║ B           ║
║ C           ║
║ D           ║
║ E           ║
╚═════════════╝

There are three different pipelines, i.e. x, y and z
If a certain project inside the monorepo changes, different pipelines should be triggered, i.e.:
If a commit is done in folder a then pipeline x should be triggered (a --> x).
If a change occurs in directory b or c then pipeline y should be run (b || c > y) and if either d or dir e changes then pipeline should start running (d || e > z).
How to achieve this? Most CI's are triggered by changes in a repository, e.g. one commits to a repo and a pipeline is triggered. There is a 1 on 1 relation. If this is translated to a monorepo that means that 1 change results in 3 pipeline triggers, while in some cases only 1 pipeline should be triggered.

**Tags:** continuous-integration, monorepo

> **Comments:**
> **username_1**: Either add a filter on your pipeline trigger (highly dependent on your CI system) or do it the right way and split those repos, there's no reason project B get all history on projects A, C, D and E, that's just noise and makes following B's history more difficult as it keeps commits unrelated to it.  

---

## 2 answers

### Answer by username_3 on 2017-09-25. Score: 6 | Accepted answer

> If this is translated to a monorepo that means that 1 change results
> in 3 pipeline triggers, while in some cases only 1 pipeline should be
> triggered.

I would definitely take this point into further consideration. One of the most compelling reasons for using a monorepo is that it does not create a technical separation of projects. There is only a logical separation, with the only technical distinction possibly being your versioning (unless you have a universal version number). This means, that you have no 100% guarantee that any one project does not depend on another project. Because of this, your final pipeline at some point should include **all of the projects** within your repository. By doing so, you are guaranteeing that a change to one project does not negatively impact any other projects in your repository (at the cost of the project with the longest time to build, publish, etc.).

That being said, if there are some steps in your pipeline that you would like to run separately (lint, syntax, compile, etc.), most CI's should have a way to filter your repo for a specific folder/project. If it doesn't, and you still don't want to run against all projects, you may need to consider refactoring your repository into [separate repos](https://puppet.com/blog/refactor-your-monolithic-code-repo-to-deploy-r10k) or changing CI tools to comply with your workflow.


---

### Answer by username_2 on 2018-11-26. Score: 3

You need to narrow down your scope and deal with tooling for monorepos. There are various *awesome-monorepo* lists on Github ([this is a recent one](https://github.com/korfuri/awesome-monorepo)) to actually find out, what kind of tooling fits your use case best (what programming languages are you using?).

If you have completely isolated projects in your repository you can cobble up some bash scripting utilizing `git diff` output or better use one of the many available monorepo-aware built utilities (see above awesome list for examples).


---

