Totally agreed on this general pattern, even you're not using Bazel or Buck2. In my experience working in large organizations - if a developer can't easily rep

Totally agreed on this general pattern, even you're not using Bazel or Buck2. In my experience working in large organizations - if a developer can't easily reproduce what the CI/CD pipeline is doing, then many won't try. That leads to a lot of "push-and-pray" magical thinking, minimal local testing, and a lack of understanding about what the pipeline does and doesn't do. Across a large organization, this can also get expensive if you're using cloud-hosted build runners. Instead of putting a bunch of build logic in your pipeline, try to put it in a local script instead. Or better yet, wrap your actual build steps with a top-level Makefile (which can then call bazel, or cmake, or whatever). Design your pipeline to run this target, and keep the pipeline logic to an absolute minimum. Your pipelines will become small, and easy to reason about. Your CI/CD setup will be more portable between different products (Jenkins, Azure Pipelines, Buildkite, etc). And your developers will be able to use the same workflow as the pipeline, leading to fewer "but it works on my machine!"-type problems.