Sign in
Log inSign up
David Herbert

74 likes

·

30.2K reads

5 comments

Ravin
Ravin
Aug 22, 2022

Nice write up 👍👍

1
·
·1 reply
David Herbert
David Herbert
Author
·Aug 23, 2022

Thanks Ravin :)

·
Franklin Okolie
Franklin Okolie
Aug 22, 2022

Amazing article, very detailed. Beautiful writing skills too. Thank you for this David.

·
·1 reply
David Herbert
David Herbert
Author
·Aug 23, 2022

Lol, Thanks for all the hype Franklin :)

·
David Cardona
David Cardona
Dec 15, 2022

Hello David. Thanks for this amazing article. I always have a big question about monorepo and its CICD workflow

The direct question is: Should I build and test all projects into the monorepo every time a merge on main/master/trunk occur? No matter if a projects doesn't change I will build and test, is it a good approach?

Why did this idea come to me? 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 misconfigure 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 (depends on the CI tool) 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/failed 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). IMO This is ugly.

So, an idea came up, what if I always build and test all projects on main . Somehow find the way to deploy those that was changed. Maybe a creating a docker-tag based on the digest-content and so avoid a rolling update, or use the changes/rules, or something else.

What do you think about this?

Thank you very much

·