Discussion on "How to set up monorepo build in GitLab CI"

Marcin Wosinek · 2021-07-25T08:14:43.330Z

If you migrate your multirepo to a monorepo, or if your project is getting big enough to consider running only part of continuous integration (CI) - then it can make sense to run only those parts of CI that could have been affected by the change. Thi...

지금 당장 필요한 설명이었습니다!

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

Hey!

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

CI that will definitively fail if anything is as wrong as broken YML files,
Rebasing 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.

Hi 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

I really like your approach. Just have one question:

How can I manually trigger an explicit sub-project with this? For example I want to run only backend-build from within the Gitlab Interface or just frontend-deploy without triggering lets say 100 other jobs.

I think you could achieve it by adding some variable/flag that introduces another level of control over what and when runs. It could complicate your set-up though, so I'm uncertain if it's a good idea.

I'm interested in learning more about GitLab CI cases that people try building—you can write a description of what you have now, and how would you like to change it, mail me at marcin.wosinek@gmail.com, and then we can meet at half-an-hour call.

I switched our microservice infrastructure to a monorepo and it contains a websocket server, api gateway, a bunch of backend services and two frontends for now. I asked because at some point you might want to build only specific jobs or pipelines. E.g. when creating a new version / tag. In that case I don’t want to run all the code quality stuff over and over again. Just the build jobs to tag a new Docker image version of all services and frontends. Marcin Wosinek

This is a very nice solution, much more elegant than something I've had on the go for the past year. Thanks for sharing!

Discussion

How to set up monorepo build in GitLab CI

Responses(4)

Recent in Forum

Search Hashnode

How to set up monorepo build in GitLab CI

Responses(4)

Recent in Forum