Hi Alex Eagle I really appreciate your comments. So, can I say that If we don't have Bazel/Nx/etc implemented (which would be the optimal solution), but we have a good cache, good CI runners which can run all CI Jobs in a efficient way, would it be better to run all build/test/deploy jobs instead of trying to arrange the rules/change/chang_in of my CI tool? This in a monorepo with about 20-30 projects. Thank you very much

Hi Alex Eagle , thank you very much. We don't have Bazel nor incremental build/test. It's true that build everything on every merge is expensive and time consuming. What about this scenario: 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 /script? The code was already merged but none of the changes was deployed. So I fix the yml/script but none of the paths defined in change / rules (depends on the CI tool) where touched then nothing will be deployed… We can not just re-run the last failed pipeline because it always checked out agains the old / failed commit.. Can you think of something to handle this situation?

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

Hello Alex. 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

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

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