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 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