| You're really asking about CI patterns and practices, which are not specific to Docker. The question is the same if using VMs. You want to learn more about your CI system and then try things out until you hit the harder / edge cases. Some things to try or think about - Push two commits quickly, so the second starts while the first is running. - rebuild a a commit while the current build is executing. Which one writes the final image to the registry? How do you know? - How do you tag your images? If by branch name, how do you know which build produced an image? If by commit, how do you know which branch? - Do you want to run the entire system per commit, shutting it down at the end of a build? Do you want to run supporting systems for the life of a branch? How do you clean up resources and not blow up your cloud budget? Do you clean up old containers each build (from old commits on this branch)? How do you clean up containers after a branch is deleted? - Build a CI process that triggers subjobs, because eventually you may want to split things up. If you push a commit before the last build's subjob triggers, does it get the original commit or the latest commit? CI systems have nuances, Jenkins always fetches the latest commit when a job starts for a branch, so you may not be testing the code you think you are. - Do you use a polyrepo or monorepo setup? For poly, how do you gather the right version of components for your commit? For mono, how do you build only what is necessary while still running a full integration test? - Should you be doing integration testing inside or outside of the build system? One of the reasons content that addresses these questions is harder to find is that the answers are highly dependent on the situation and tools. My solutions to many are handled with a mix of CUE and Python. You'll be writing code in most solutions |