---
title: "Comment by David Cardona on \"How to set up monorepo build in GitLab CI\" | Hashnode"
description: "Hi. Tks for this article. I always have a big question about this Workflow. What happen if I merge into main a super feture which work and run perfectly on PR/M"
url: "https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6/comment/6397b64632e52b31f1387bac"
---

[Discussion](https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6)

Comment [How to set up monorepo build in GitLab CI](https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6)

[David Cardona](https://hashnode.com/@davidpccode)

[Dec 12, 2022](https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6/comment/6397b64632e52b31f1387bac)

Hi. Tks for this article. I always have a big question about this Workflow.

What happen if I merge into main a super feture which work and run perfectly on PR/MR but when run on main there was a small error in a yml file or some missconfiguring file? The code was already merged but no one of the changes was deployed. So I fix the yml but non of the paths defined in change/rules where touched then nothing will de deployed… We cann’t just re run the last failed pipeline because it always checked out agains the old commit..

There is no way to run the same projects that failed unless I touch some files (with empty spaces or enter or whatever change). This is ugly for me.

One idea came up, what if I always build all projects on main but when deploy the docker images that hasn’t changed won’t be deployed

Any ideas? Thanks

[Marcin Wosinek](https://hashnode.com/@marcin-wosinek)

[Dec 13, 2022](https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6/comment/6397b64632e52b31f1387bac#reply-63984df69c2b1a31cc3994cc)

Hey!

Yes, this sounds like a problem that could be very annoying. I think, I managed to avoid this kind of situation with:

1.  [CI](https://how-to.dev/continuous-integration-ci-and-how-it-can-help-you) that will definitively fail if anything is as wrong as broken YML files,
2.  [Rebasing](https://how-to.dev/rebases-in-git-and-why-you-shouldnt-be-afraid-of-them) feature branches all the time

> There is no way to run the same projects that failed unless I touch some files (with empty spaces or enter or whatever change). This is ugly for me.

Triggering jobs manually should do the trick. It's annoying, as you have to trigger them in the right order, but you can get everything build finally

> One idea came up, what if I always build all projects on main but when deploy the docker images that hasn’t changed won’t be deployed

Yes, I would always run everything on the main branch. It's already merged, if it takes very long it doesn't matter, and it verifies all the code—even the parts that are hardly every touched.

[David Cardona](https://hashnode.com/@davidpccode)

[Dec 13, 2022](https://hashnode.com/posts/how-to-set-up-monorepo-build-in-gitlab-ci/60fd1d7318fbbb77c94672d6/comment/6397b64632e52b31f1387bac#reply-6398e4aa452f4e3f4cb65f8d)

Hi [Marcin Wosinek](https://hashnode.com/@marcin-wosinek)

Yes I think build everything on main is the real continuos integration. It ensure that everything no matter if was changed or not is working.

Thank you very much