True, CI caches are only one way to look at slow pipelines. When you are in control of the infrastructure where jobs and runners consume resources, other strat

True, CI caches are only one way to look at slow pipelines. When you are in control of the infrastructure where jobs and runners consume resources, other strategies might also help. Package dependency installs taking some time? Move the runners into network segments with blazing fast connections, next to mirrors of package registries (if not already provided). Possibility to use a CDN in front of the runners? Make sure the application code is capable of doing so. C/C++ with ccache can consume a lot of disk space, and caching itself can slow down the pipelines. Calculate the cost of pipeline runs and employees waiting for builds to finish, and compare it to buying more compute resources with xyz cores, lots of memory and direct SSD disk access to speed up the builds. That said, many different environments and workflows make decisions harder. Better observability for CI/CD is needed, having better insights into pipelines and see if and how efficiency improvements can have an impact. I have shared more thoughts in https://news.ycombinator.com/item?id=29520577 https://news.ycombinator.com/item?id=29520577