3 ms·
It's so surprising to me that this is such a poorly supported paradigm in commodity CI systems. Caching artifacts and identifying slow stages is like... super i
by packetlost 4y ago
It's so surprising to me that this is such a poorly supported paradigm in commodity CI systems. Caching artifacts and identifying slow stages is like... super important for scaling CI for large enough orgs. We need better tools!
- duped 4y agoThe more time you spend debugging this and the worse job you do at it, the more money they make.
- sleepychu 4y agoThat feels counterintuitive to me. I would probably use even more CI minutes if they had higher value.
- mgkimsal 4y agoWhile it sounds cynical... it doesn't strike me as 'wrong' entirely. It's a non-trivial problem, but until some service provides great tools to handle this, and makes the experience 10x better (to encourage more use/experimentation/etc), everyone will keep offering the same experience all around. If a service could automatically cut build times by, say, 70%, that's a lot of revenue they may lose from charging for the build time. They could raise the price, or hope that enough new people get onboard to make up the loss... ?
- nerdponx 4y agoMaybe it's because CI service providers don't want to be responsible for a lot cache storage. Given how lacking this feature is, maybe a CI vendor could offer it as a premium paid feature.
- danpalmer 4y agoCircleCI sort of do! They have something called Docker Layer Caching, which basically puts all the Docker layers from your previous build on the execution machine. The problem is that it's a) very slow to download those layers from their cache storage, and b) very expensive. It works out to costing ~20 minutes of build time.